Displaying 16 results from an estimated 16 matches for "fan_mode".
2014 Mar 24
4
[PATCH 1/4] pm/fan: drop the fan lock in fan_update() before rescheduling
From: Martin Peres <martin.peres at labri.fr>
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update(), leading to a deadlock.
We should Cc: <stable at vger.kernel.org> # 3.9+
Reported-by:
2015 Nov 29
2
[PATCH] bios/fan: hardcode the fan mode to linear
....c b/drm/nouveau/nvkm/subdev/bios/fan.c
index 43006db..80fed7e 100644
--- a/drm/nouveau/nvkm/subdev/bios/fan.c
+++ b/drm/nouveau/nvkm/subdev/bios/fan.c
@@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan)
fan->type = NVBIOS_THERM_FAN_UNK;
}
+ fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
fan->min_duty = nvbios_rd08(bios, data + 0x02);
fan->max_duty = nvbios_rd08(bios, data + 0x03);
--
2.6.2
2016 Jan 04
2
[PATCH] bios/fan: hardcode the fan mode to linear
...au/nvkm/subdev/bios/fan.c
>> +++ b/drm/nouveau/nvkm/subdev/bios/fan.c
>> @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct
>> nvbios_therm_fan *fan)
>> fan->type = NVBIOS_THERM_FAN_UNK;
>> }
>>
>> + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
>> fan->min_duty = nvbios_rd08(bios, data + 0x02);
>> fan->max_duty = nvbios_rd08(bios, data + 0x03);
>>
>>
>
> Ben, can you merge this patch? It is kind of critical :s And it should
> be CCed to stable too, with...
2016 Jan 05
2
[PATCH] bios/fan: hardcode the fan mode to linear
...eau/nvkm/subdev/bios/fan.c
>>>> @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct
>>>> nvbios_therm_fan *fan)
>>>> fan->type = NVBIOS_THERM_FAN_UNK;
>>>> }
>>>>
>>>> + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
>>>> fan->min_duty = nvbios_rd08(bios, data + 0x02);
>>>> fan->max_duty = nvbios_rd08(bios, data + 0x03);
>>>>
>>>>
>>> Ben, can you merge this patch? It is kind of critical :s And it sho...
2015 Jan 29
0
[Bug 84721] [NVC1] Nvidia Geforce GT 630 using nouveau on 3.16 kernel. dangerous Fan speed
...bios decide on the automatic fan management
> mode
Following to this there was a conversation on #nouveau:
Reverting a part of the above noted patch:
- /* starting from fermi, fan management is always linear */
- if (nv_device(bios)->card_type >= NV_C0 &&
- fan->fan_mode == NVBIOS_THERM_FAN_OTHER) {
- fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
- }
hides the bug away again.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedeskto...
2013 Jun 25
10
[Bug 66177] New: pwm1 value not restored during hibernate/restore cycle in the event of manual fan management mode
...h proposed by Emil
Velikov in Bug 66022, but that doesn't restore the pwm1 value in case of manual
fan management. I am attaching 2 patches to this report:
1. which fixes this bug and restores everything ("pwm1_enable", as well as
"pwm1"); and
2. a separate patch, allowing fan_mode and fan duty (percentage) to be
specified at the command line, allowing me to set my fan speed immediately and
not waiting for OS scripts to do that for me as was the case up until now.
Since the automatic fan management is, well, lets just say incomplete, that's
currently the best option to n...
2015 Dec 17
0
[PATCH] bios/fan: hardcode the fan mode to linear
...> index 43006db..80fed7e 100644
> --- a/drm/nouveau/nvkm/subdev/bios/fan.c
> +++ b/drm/nouveau/nvkm/subdev/bios/fan.c
> @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct nvbios_therm_fan *fan)
> fan->type = NVBIOS_THERM_FAN_UNK;
> }
>
> + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
> fan->min_duty = nvbios_rd08(bios, data + 0x02);
> fan->max_duty = nvbios_rd08(bios, data + 0x03);
>
>
Ben, can you merge this patch? It is kind of critical :s And it should
be CCed to stable too, without it, some kepler/maxwell get 0% fan pow...
2016 Jan 04
0
[PATCH] bios/fan: hardcode the fan mode to linear
...gt;>> +++ b/drm/nouveau/nvkm/subdev/bios/fan.c
>>> @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct
>>> nvbios_therm_fan *fan)
>>> fan->type = NVBIOS_THERM_FAN_UNK;
>>> }
>>>
>>> + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
>>> fan->min_duty = nvbios_rd08(bios, data + 0x02);
>>> fan->max_duty = nvbios_rd08(bios, data + 0x03);
>>>
>>>
>>
>> Ben, can you merge this patch? It is kind of critical :s And it should be
>&g...
2016 Jan 05
0
[PATCH] bios/fan: hardcode the fan mode to linear
....c
>>>>> @@ -83,6 +83,7 @@ nvbios_fan_parse(struct nvkm_bios *bios, struct
>>>>> nvbios_therm_fan *fan)
>>>>> fan->type = NVBIOS_THERM_FAN_UNK;
>>>>> }
>>>>>
>>>>> + fan->fan_mode = NVBIOS_THERM_FAN_LINEAR;
>>>>> fan->min_duty = nvbios_rd08(bios, data + 0x02);
>>>>> fan->max_duty = nvbios_rd08(bios, data + 0x03);
>>>>>
>>>>>
>>>> Ben, can you merge this patch? It is kind of cr...
2016 Apr 18
0
[PATCH v4 26/37] therm: don't cancel the timer
...ct nvkm_therm *therm, int mode)
switch (mode) {
case NVKM_THERM_CTRL_MANUAL:
- nvkm_timer_alarm_cancel(tmr, &therm->alarm);
duty = nvkm_therm_fan_get(therm);
if (duty < 0)
duty = 100;
- poll = false;
break;
case NVKM_THERM_CTRL_AUTO:
switch(therm->fan->bios.fan_mode) {
@@ -119,18 +116,16 @@ nvkm_therm_update(struct nvkm_therm *therm, int mode)
case NVBIOS_THERM_FAN_OTHER:
if (therm->cstate)
duty = therm->cstate;
- poll = false;
break;
}
immd = false;
break;
case NVKM_THERM_CTRL_NONE:
default:
- nvkm_timer_alarm_cancel(tmr,...
2014 Apr 30
26
[Bug 78116] New: Auto fan speed management doesn't do anything in non critical temperature range (NVC0)
https://bugs.freedesktop.org/show_bug.cgi?id=78116
Priority: medium
Bug ID: 78116
Assignee: nouveau at lists.freedesktop.org
Summary: Auto fan speed management doesn't do anything in non
critical temperature range (NVC0)
QA Contact: xorg-team at lists.x.org
Severity: enhancement
Classification: Unclassified
2017 Jul 21
15
[RFC PATCH 00/13] Thermal throttling
Adds Nouveau controlled thermal throttling for Kepler+ GPUs. With this I feel
safe enough to add support for Maxwell2 reclocking later on (still hidden
behind a switch, but we can be fairly sure to not overheat hardware if a user
isn't carefull enough)
Contains all patches from my clk update series, but I thought it makes sense
to include those in this series as well for completness.
Please
2017 Nov 17
35
[PATCH 00/32] Updated State of my clk patches
Last update here: https://lists.freedesktop.org/archives/nouveau/2017-September/028848.html
Basically big cleanup, reordering, simplifications and some renaming to make
the code easier to read and to review. I also moved some bugfixes to the front
so they can be merged prior the other patches.
There was also a bug related to the therm daemon triggering a pstate change
leading to PMU lockups,
2017 Sep 15
42
[RFC PATCH 00/29] Current State of my clk patches
Just wanted to post updated versions of my last series/patches. Reviews
welcomed.
It would be also nice if we agree on features I should focus upstreaming, so
that this work can be better splitted or reordered.
Sadly most of my patches depend on the rather big clk subdev rework and I think
those patches shows best, why I think this rework is actually needed and makes
things much easier to add
2016 Apr 07
29
[PATCH v3 00/29] Volting/Clocking improvements for Fermi and newer
This is an updated series for the old clocking improvement one.
I think I got everything needed in place and also a simple update mechanism for
updating the cstates/voltage on temperature changes.
If anything is unclear how I REed or got the information, please leave a note
so that I can provide additional information in the commits.
Besides that I think we are pretty close now and only some
2016 Apr 18
63
[PATCH v4 00/37] Volting/Clocking improvements for Fermi and newer
We are slowly getting there!
v4 of the series with some realy good improvements, so I am sure this is like
95% done and only needs some proper polishing and proper Reviews!
I also added the NvVoltOffsetmV module parameter, so that a user is able to
over and !under!-volt the GPU. Overvolting makes sense, when there are still
some reclocking issues left, which might be solved by a higher voltage.