similar to: [PATCH] drm/nouveau: POST the card before GPIO initialization

nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau Cc: stable

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 Martin, I'm not very familiar with the function naming scheme but shouldn't nouveau_fuse_rd32 use the same prefix as xxxx_fuse_ctor instead of nouveau? Christian Le 24/08/2014 23:15, Martin Peres a ?crit : > 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

On 01/01/14 00:55, Ilia Mirkin wrote: > On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: >> On 31/12/13 10:36, Ilia Mirkin wrote: >>> On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce <sboyce at blueyonder.co.uk> >>> wrote: >>>> System x86_64 with openSUSE 13.1. >>>> X.Org version: 1.14.99.905 >>>>

On 01/01/14 18:46, Ilia Mirkin wrote: > On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: >> On 01/01/14 00:55, Ilia Mirkin wrote: >>> On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce <sboyce at blueyonder.co.uk> >>> wrote: >>>> On 31/12/13 10:36, Ilia Mirkin wrote: >>>>> Having a dmesg would be nice. One thing

On 31/12/13 10:36, Ilia Mirkin wrote: > On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: >> System x86_64 with openSUSE 13.1. >> X.Org version: 1.14.99.905 >> >> openSUSE 12.2 kernels boot successfully into a graphical screen, login to >> KDE4, etc. all normal. >> >> 3.13-rc kernels boot fully with X running but no

--- drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 33 +++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c index b1b2e48..975cfab 100644 --- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c +++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c @@ -248,6 +248,39 @@

Signed-off-by: John Rowley <john.rowley08 at gmail.com> --- nvkm/engine/device/nve0.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/nvkm/engine/device/nve0.c b/nvkm/engine/device/nve0.c index 964c183..6e72f9c 100644 --- a/nvkm/engine/device/nve0.c +++ b/nvkm/engine/device/nve0.c @@ -208,6 +208,41 @@ nve0_identify(struct nouveau_device *device)

On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: > On 01/01/14 00:55, Ilia Mirkin wrote: >> >> On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce <sboyce at blueyonder.co.uk> >> wrote: >>> >>> On 31/12/13 10:36, Ilia Mirkin wrote: >>>> Having a dmesg would be nice. One thing I can think of off-hand is

Enough to get VGA monitor on DVI-I output have output. HDMI output not yet working --- drm/nouveau/nvkm/engine/device/gm100.c | 43 ++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/drm/nouveau/nvkm/engine/device/gm100.c b/drm/nouveau/nvkm/engine/device/gm100.c index 539561e..108d048 100644 --- a/drm/nouveau/nvkm/engine/device/gm100.c +++

On Wed, Jan 1, 2014 at 9:36 PM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: > On 01/01/14 18:46, Ilia Mirkin wrote: >> >> On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: >>> >>> On 01/01/14 00:55, Ilia Mirkin wrote: >>>> >>>> On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce <sboyce at

v2: Check for PFIFO, don't pause if it's not yet running. This should fix reclocking on boot Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv50.c | 4 +- .../gpu/drm/nouveau/core/include/subdev/clock.h | 4 + drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c | 439

v2: Check for PFIFO, don't pause if it's not yet running. This should fix reclocking on boot v3: Tiny clean up Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/engine/device/nv50.c | 4 +- .../gpu/drm/nouveau/core/include/subdev/clock.h | 4 +

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 +

Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to

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

Please add a config override to skip this, since we'll invariably get it wrong for some setup, and should be able to provide users with workarounds while the issue is being worked out. On Mon, Jul 15, 2019 at 5:43 AM Mark Menzynski <mmenzyns at redhat.com> wrote: > > Currently, nouveau doesn't check if GPU is missing power. This > patch makes nouveau fail when this happens

Hi! I have CyberPower CyberShield CSN27U12V UPS. This device don't have usual for UPS interface, just open collector pins. I connected these pins to GPIO interface on Orange Pi Zero and wrote NUT driver for this case. Any interest from NUT community to add this driver to regular build tree? See driver code in attachment. Code is fully functional, needs cleanup to match coding guidelines

Great, thanks! Also just for context, this sounded reminiscent of one of the first NUT drivers, `genericups` (for simple contact-closure support, with IIRC serial-port connections rather than GPIO). Nearby there's also a `generic_modbus" name. Wondering if the new driver should be (similar to) `generic_gpio`. @Community verdict: Then there was also an effort some years ago to name

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > Nearby there's also a `generic_modbus" name. Wondering if the new driver > should be (similar to) `generic_gpio`. sound good. It would be nice if there were an abstraction layer for various GPIO access methods, rather than hard-coding linux, even if there is only one implementation of the