similar to: [PATCH] drm/nouveau/falcon: avoid touching registers if engine is off

From: Ilia Mirkin <imirkin at alum.mit.edu> [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7

From: Ilia Mirkin <imirkin at alum.mit.edu> [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7

From: Ilia Mirkin <imirkin at alum.mit.edu> [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7

GF117 appears to use the same register as GK104 (but still with the general Fermi readout mechanism). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: split out different regid into separate file. .../drm/nouveau/include/nvkm/subdev/volt.h | 1 + .../gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-

https://bugs.freedesktop.org/show_bug.cgi?id=108980 Bug ID: 108980 Summary: GF117: MMIO write of 0000001f FAULT at 6013d4 [ IBUS ] Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/subdev/volt.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 17 +++++----- drm/nouveau/nvkm/subdev/volt/Kbuild | 1 + drm/nouveau/nvkm/subdev/volt/gf100.c | 59 ++++++++++++++++++++++++++++++++++ 4 files changed, 70 insertions(+), 8 deletions(-) create mode 100644

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,

Falcon processors are used in various places of GPU chips. Although there exist different versions of the falcon, and some variants exist, the base set of actions performed on them is the same, which results in lots of duplicated code. This patch consolidates the current nvkm_falcon structure and extends it with the following features: * Ability for an engine to obtain and later release a given

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

I've splitted my big series between the part which actually fixes the engine reclocking bits and the part handling voltage/clock updates on temperature change, so that the more reviewed parts can be merged in faster. This series fixes a lot of Engine reclocking issues found on Fermi, Kepler and all Maxwell generation GPUs. It does _not_ fix memory reclocking on Fermi. It mostly contains of

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

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

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

Some firmware images may be large (64K), so using kmalloc memory is inappropriate for them. Use vmalloc instead, to avoid high-order allocation failures. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org --- Couldn't get video decoding started on a long-running system due to high-order allocation failures. This seems like a fine use-case for vmalloc.

Hi all, I'd like to add Falcon, the Java JIT compiler we've been working on at Azul Systems for the last few years, to Users.html. I've attached a patch, please take a look. Thanks! -- Sanjoy -------------- next part -------------- A non-text attachment was scrubbed... Name: falcon.patch Type: application/octet-stream Size: 681 bytes Desc: not available URL:

I have been experimenting with getting various (usually older) D3D games running under wine and have so far been very impressed with the results - a big thank you is due to all the wine developers who have got things to this stage. With Falcon 4.0 (1.08us), however, I am stuck. The game interface works apparently perfectly, along with the background sound/music, but when I go to fly, I get black

The IRQ mask of the PMU falcon was left - replace it with the proper irq_mask variable. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/secboot/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/secboot/base.c b/drm/nouveau/nvkm/subdev/secboot/base.c index b718ba79177c..05c62549c39b 100644 ---

Make sure we are not disturbed by spurious interrupts, as we poll the halt bit anyway. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/secboot/gm200.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/secboot/gm200.c b/drm/nouveau/nvkm/subdev/secboot/gm200.c index 4932757ab1a2..5801babdf959 100644 ---