similar to: [PATCH 0/5] Thermal management fixes

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:

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs

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 +

+ the same for shutdown threshold - seems impossible, but shutdown can fail. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c index bf9b3ce..8f27b44

From: Martin Peres <martin.peres at labri.fr> Some vbioses have extra useless entries after "the end" of the table. This is problematic since all of the vbios I found with this issue redefine the pwm freq divider to insane levels (52750 Hz instead of 2500), thus breaking fan management. The first solution to solve this mess would be to change the length of the table. The solution

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

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ Signed-off-by: Martin Peres <martin.peres at labri.fr> ---

https://bugs.freedesktop.org/show_bug.cgi?id=65554 Priority: medium Bug ID: 65554 Assignee: nouveau at lists.freedesktop.org Summary: CPU lock with nouveau_fan_update QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: ddamienn at gmail.com

Current uninitialized sensor detection does not work for me on nv4b and sensor returns crazy values (>190?C). It stabilises later, but it's too late - therm code shutdowns the machine... Let's just reset it on init. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 12 +++++++++++- 1 file changed, 11

Hello all, this series includes a wide range of fixes - from a few month's old one-liners from Andreas Heider regarding vga_switcheroo, via a null pointer dereference and double memory allocation, to a buffer overflow. Please review and comment --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_device.c | 26 +++++++++++++++-----------

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. Reported-by: Marcin Slusarz <marcin.slusarz at gmail.com>

We will use this subdev to disable temperature reading on cards that did not get a sensor calibration in the factory. Signed-off-by: Martin Peres <martin.peres at free.fr> --- configure.ac | 1 + drm/Kbuild | 4 ++ drm/core/include/subdev/fuse.h | 1 + drm/core/subdev/fuse/base.c | 1 + drm/core/subdev/fuse/g80.c | 1 +

Hi, This is a try to have some simple DVFS (Dynamic Voltage and Frequency Scaling) support for GK20A. Instead of relying on other existing frequency scaling framework, we create a simple subdev in Nouveau for the same purpose. That's because we don't want to make the DVFS implementation for GK20A far more than enough in the beginning and hinder the implementation for dGPU in the future.

On 14/09/2018 10:28, Ben Skeggs wrote: > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai <tiwai at suse.de> wrote: >> >> When a fan is controlled via linear fallback without cstate, we >> shouldn't stop polling. Otherwise it won't be adjusted again and >> keeps running at an initial crazy pace. > Martin, > > Any thoughts on this? > > Ben. Wow,

On Thu, Dec 18, 2014 at 8:13 PM, Vince Hsu <vinceh at nvidia.com> wrote: > Hello Ben, > > On 12/18/2014 05:34 PM, Ben Skeggs wrote: >> >> On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: >>> >>> This patch creates a subdev for DVFS (Dynamic Voltage and Frequency >>> Scaling) >>> support in Nouveau. This

On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: > This patch creates a subdev for DVFS (Dynamic Voltage and Frequency Scaling) > support in Nouveau. This subdev refers to the status information provided by > the NVIDIA hardware and tries to adjust the performance level based on the > calculated target. Only the GK20A is supported right now. Hey Vince,

Signed-off-by: Martin Peres <martin.peres at free.fr> Tested-by: Stefan Ringel <mail at stefanringel.de> --- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c index cfde9eb..6212537 100644 ---

From: Martin Peres <martin.peres at labri.fr> Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/subdev/therm/gm107.c | 1 + nvkm/engine/device/gm100.c | 4 +- nvkm/include/subdev/therm.h | 1 + nvkm/subdev/therm/Makefile.am | 3 +- nvkm/subdev/therm/fan.c | 9 ++++- nvkm/subdev/therm/gm107.c | 93

When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios") Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356 Bugzilla:

From: Martin Peres <martin.peres at labri.fr> This should enable automatic fan management for all cards by default, at boot time. However, this commit actually affects only nv40-c0 as nvc0+ cards already have vbios's PDAEMON fw already taking care of fan management. Signed-off-by: Martin Peres <martin.peres at labri.fr> --- drivers/gpu/drm/nouveau/core/subdev/therm/base.c | 2 +-