similar to: [PATCH] drm/nouveau/therm: fix spelling mistake on array thresolds

+ 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

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c index b9703c0..adb1deb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs, struct work_struct *work; work =

The temp_get() function currently returns negative error numbers or a temperature. However, the thermal sensors can (in theory) measure negative temperatures. Some implementations of temp_get() correctly clamp negative temperature readings to 0 so that users do not mistake them for errors, but some, like gp100_temp_get(), do not. Rather than relying on implementations remembering to clamp values,

On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > > > The temp_get() function currently returns negative error numbers or a > > temperature. However, the thermal sensors can (in theory) measure > > negative temperatures. Some implementations of

On 17/11/17 02:04, Karol Herbst wrote: > The current hwmon code doesn't check if the returned value was actually an > error. > > Since Kepler temperature sensors are able to report negative values. Those > negative values are not for error reporting, but rather when you buried > your GPU in snow somewhere in Antarctica and still want a valid > temperature to be reported

As you changed the return value of `temp_get()` to solely be the error code, or absence of an error, I would change all those tests that checked whether the returned value was strictly less, or greater than, 0 to now only compare against 0 (no error). For example, if (therm && therm->attr_get && nvkm_therm_temp_get(therm, &val) < 0) if

On 22/11/17 03:42, Karol Herbst wrote: > On Wed, Nov 22, 2017 at 1:32 AM, Martin Peres <martin.peres at free.fr> wrote: >> On 17/11/17 02:04, Karol Herbst wrote: >>> The current hwmon code doesn't check if the returned value was actually an >>> error. >>> >>> Since Kepler temperature sensors are able to report negative values. Those

The current hwmon code doesn't check if the returned value was actually an error. Since Kepler temperature sensors are able to report negative values. Since Pascal (and maybe earlier) we have sensors with improved precision. Adjust the nvkm_get_temp method to be able to deal with those changes and let hwmon return an error properly. Signed-off-by: Karol Herbst <karolherbst at

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have needed like the same amount of time to actual fix the problem. Anyway, for adding a printk:

Hi! Not only it is unneccessarily complex, it is also broken; GFP_ATOMIC allocation can fail.. and then you fail to shut down the machine. Someone please fix this. Thanks, Pavel --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs,

On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > The temp_get() function currently returns negative error numbers or a > temperature. However, the thermal sensors can (in theory) measure > negative temperatures. Some implementations of temp_get() correctly > clamp negative temperature readings to 0 so that users do not mistake > them for

The current hwmon code doesn't check if the returned value was actually an error. Since Kepler temperature sensors are able to report negative values. Those negative values are not for error reporting, but rather when you buried your GPU in snow somewhere in Antarctica and still want a valid temperature to be reported (unverified). Since Pascal (and maybe earlier) we have sensors with

On Wed, Sep 16, 2020 at 10:03:22PM +0200, Karol Herbst wrote: > On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > > > > > The temp_get() function currently returns negative error numbers or a > > > temperature. However, the thermal

On Wed, Nov 22, 2017 at 1:32 AM, Martin Peres <martin.peres at free.fr> wrote: > On 17/11/17 02:04, Karol Herbst wrote: >> The current hwmon code doesn't check if the returned value was actually an >> error. >> >> Since Kepler temperature sensors are able to report negative values. Those >> negative values are not for error reporting, but rather when you

We should simply return errors while the GPU is turned off, because the sensors aren't accessable and setting any kind of value doesn't make any sense. Fixes sensors values reported by "sensors" Before: nouveau-pci-0100 Adapter: PCI adapter GPU core: +0.60 V (min = +0.60 V, max = +1.20 V) temp1: -0.0°C (high = +95.0°C, hyst = +3.0°C) (crit

Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of new gp1xx temperature sensor") added support for reading finer-grain temperatures, but continued to report temperatures in 1 degree Celsius increments via nvkm_therm_temp_get(). Rather than altering nvkm_therm_temp_get() to report finer-grain temperatures, which would be inconvenient for other users of the

Rusers: I am trying to apply a quadratic discriminant function to find the best classification outcomes. 1 is assigned to the values greater than a threshold value; and 0 otherwise. I would like to see how the apparent error rates and the optimal error rate change with increasing threshold values. I have a 1000*10 data matrix: n=1000 and p=10. Here is what I wrote so far, but seems to be

Hi Version 0.7 of package tsDyn presented at useR! 2009 is now on CRAN, extended with several new features. The package tsDyn is aimed at estimating nonlinear time series models which exhibit regime specific properties. The regime switching dynamics can either be described by smooth transition (STAR and LSTAR) or threshold effects (SETAR). The package furthermore offers nonlinear models

Hi Version 0.7 of package tsDyn presented at useR! 2009 is now on CRAN, extended with several new features. The package tsDyn is aimed at estimating nonlinear time series models which exhibit regime specific properties. The regime switching dynamics can either be described by smooth transition (STAR and LSTAR) or threshold effects (SETAR). The package furthermore offers nonlinear models

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,