search for: max_duti

Displaying 9 results from an estimated 9 matches for "max_duti".

Did you mean: max_duty
2015 Nov 29
2
[PATCH] bios/fan: hardcode the fan mode to linear
This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund <tomenglund26 at gmail.com> Tested-by: Tom Englund <tomenglund26 at gmail.com> Signed-off-by: Martin Peres <martin.peres at
2016 Jan 04
2
[PATCH] bios/fan: hardcode the fan mode to linear
On 17/12/15 19:18, Martin Peres wrote: > > > On 29/11/15 16:10, Martin Peres wrote: >> This is an oversight that made use of the trip-point-based fan >> managenent on >> cards that never expose those. This led the fan to stay at fan_min. >> >> Fortunately, the emergency code would kick when the temperature would >> reach >> 90°C. >>
2016 Jan 05
2
[PATCH] bios/fan: hardcode the fan mode to linear
On 04/01/16 18:42, Emil Velikov wrote: > On 4 January 2016 at 14:56, Martin Peres <martin.peres at free.fr> wrote: >> On 17/12/15 19:18, Martin Peres wrote: >>> On 29/11/15 16:10, Martin Peres wrote: >>>> This is an oversight that made use of the trip-point-based fan managenent >>>> on >>>> cards that never expose those. This led the fan
2015 Dec 17
0
[PATCH] bios/fan: hardcode the fan mode to linear
On 29/11/15 16:10, Martin Peres wrote: > This is an oversight that made use of the trip-point-based fan managenent on > cards that never expose those. This led the fan to stay at fan_min. > > Fortunately, the emergency code would kick when the temperature would reach > 90°C. > > Reported-by: Tom Englund <tomenglund26 at gmail.com> > Tested-by: Tom Englund
2016 Jan 04
0
[PATCH] bios/fan: hardcode the fan mode to linear
On 4 January 2016 at 14:56, Martin Peres <martin.peres at free.fr> wrote: > On 17/12/15 19:18, Martin Peres wrote: >> On 29/11/15 16:10, Martin Peres wrote: >>> >>> This is an oversight that made use of the trip-point-based fan managenent >>> on >>> cards that never expose those. This led the fan to stay at fan_min. >>> >>>
2016 Jan 05
0
[PATCH] bios/fan: hardcode the fan mode to linear
On 01/05/2016 06:35 PM, Martin Peres wrote: > On 04/01/16 18:42, Emil Velikov wrote: >> On 4 January 2016 at 14:56, Martin Peres <martin.peres at free.fr> wrote: >>> On 17/12/15 19:18, Martin Peres wrote: >>>> On 29/11/15 16:10, Martin Peres wrote: >>>>> This is an oversight that made use of the trip-point-based fan >>>>> managenent
2014 Aug 16
3
[PATCH 1/3] bios/fan: add support for maxwell's fan management table
From: Martin Peres <martin.peres at labri.fr> Re-use the therm-exported fan structure with only two minor modifications: - pwm_freq: u16 -> u32; - add fan_type (toggle or PWM) Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/include/subdev/bios/fan.h | 1 + drm/core/subdev/bios/fan.c | 1 +
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:
2014 Aug 17
9
[PATCH 01/10] bios/fan: add support for maxwell's fan management table v2
Re-use the therm-exported fan structure with only two minor modifications: - pwm_freq: u16 -> u32; - add fan_type (toggle or PWM) v2: - Do not memset the table to 0 as it erases the pre-set default values Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/include/subdev/bios/fan.h | 1 + drm/core/subdev/bios/fan.c | 1