similar to: [PATCH] drm/nouveau/therm/gp100: Do not report temperature when subdev is shadowed

Not sure if i understand completely what you intend to say here, with this we prevent hwmon from reporting utterly wrong temperature values returning an error (we could return -EBUSY or somehting instead, granted), yet if the device is shadowed, getting a sane temp value out of is seems unlikely to me! Greetings, Tobias On 1/26/18 12:40 PM, Karol Herbst wrote: > no, we can't do that.

Signed-off-by: Rhys Kidd <rhyskidd at gmail.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +++ drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 3 +- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 57 ++++++++++++++++++++++ 5 files changed, 67

no, we can't do that. We actually have to prevent this from hwom. The issue here is, that the reg read returns 0xffffffff and parsing that is the first step in the first place. On Thu, Jan 25, 2018 at 7:16 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > This fixes wrong temperature outputs e.g. 511°C if the card is asleep. > > Signed-off-by: Tobias

well I just tried to say, that you are not fixing the issue you think were fixing. In your case the GPU is powered off and you get garbage values from any mmio read, so parsing those values is just wrong and we need to prevent doing anything on the hw whenever it is powered off directly in hwmon. On Fri, Jan 26, 2018 at 2:40 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de>

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

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

v2: - add nv138 and drop nv13b chipsets (Ilia Mirkin) - refactor out status variable and instead mask tsensor (Ilia Mirkin) - switch SHADOWed state message away from nvkm_error() (Ilia Mirkin) - rename internal temperature variable (Karol Herbst) Signed-off-by: Rhys Kidd <rhyskidd at gmail.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h | 1 +

On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs <skeggsb at gmail.com> wrote: > > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline <jcline at redhat.com> wrote: > > > > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of > > new gp1xx temperature sensor") added support for reading finer-grain > > temperatures, but continued to report

On Thu, 13 Aug 2020 at 06:50, Jeremy Cline <jcline at redhat.com> wrote: > > 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

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

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, 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

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,

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

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

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