search for: therms

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

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

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

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

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

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

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

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

This seems to be absolutely necessary for a lot of NV40. Reported-by: gsgf on IRC/freenode Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nvkm/subdev/therm/base.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/therm/base.c b/drm/nouveau/nvkm/subdev/therm/base.c index 8894fee..df949fa 100644 ---

On Fri, Jan 26, 2018 at 4:35 AM, Lyude Paul <lyude at redhat.com> wrote: > This adds support for enabling automatic clockgating on nvidia GPUs for > Kepler1. While this is not technically a clockgating level, it does > enable clockgating using the clockgating values initially set by the > vbios (which should be safe to use). > > This introduces two therm helpers for

From: Thierry Reding <treding at nvidia.com> The recently introduced clock gate support breaks on Tegra chips because no thermal support is enabled for those devices. Conditionalize the code on the existence of thermal support to fix this. Fixes: b138eca661cc ("drm/nouveau: Add support for basic clockgating on Kepler1") Cc: Martin Peres <martin.peres at free.fr> Cc: Lyude

This adds support for enabling automatic clockgating on nvidia GPUs for Fermi and later generations. This saves a little bit of power, bringing my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my kepler's idle power consumption from ~23.6W to ~21.65W. Similar to how the nvidia driver seems to handle this, we enable clockgating for each engine that supports it after

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

On Wed, 2017-04-26 at 00:49 +0200, Karol Herbst wrote: > Hi Lyude, > > thanks for the great work. Just a view comments inline. > > 2017-04-25 20:38 GMT+02:00 Lyude <lyude at redhat.com>: > > This adds support for enabling automatic clockgating on nvidia GPUs > > for > > Fermi and later generations. This saves a little bit of power, > > bringing >

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after