similar to: [PATCH v2] drm/nouveau: add a LED driver for the NVIDIA logo

On 23/08/16 11:31, Karol Herbst wrote: > maybe it makes sense to expose the SLI LED, too. > > Regardless of my comments this patch is reviewed-by me. You reviewed the wrong patch, I should have named the re-send v3. I accidentally sent the v1 patch as a v2 :s > > 2016-08-23 1:39 GMT+02:00 Martin Peres <martin.peres at free.fr>: >> We received a donation of a Titan

From: Karol Herbst <karolherbst at gmail.com> Fixes a kernel crash on suspend/resume. --- drm/nouveau/nouveau_led.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c index 9eed5a6..5e28b5f 100644 --- a/drm/nouveau/nouveau_led.c +++ b/drm/nouveau/nouveau_led.c @@ -107,7 +107,8 @@ nouveau_led_suspend(struct

On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: > > The underlying problem is that we already have a number of other > > symbols that either have "depends on LEDS_CLASS" or > > "select LEDS_CLASS". To clean that up properly, we should either > > make the symbol itself

On Tuesday, November 8, 2016 10:46:07 AM CET Ilia Mirkin wrote: > > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > > index 78631fb61adf..715cd6f4dc31 100644 > > --- a/drivers/gpu/drm/nouveau/Kconfig > > +++ b/drivers/gpu/drm/nouveau/Kconfig > > @@ -46,6 +46,14 @@ config NOUVEAU_DEBUG > > The paranoia and spam levels

The newly introduced LED handling for nouveau fails to link when the driver is built-in but the LED subsystem is a loadable module: drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to `nouveau_led_suspend' drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_resume':

This fixes the auto-magic detection of LEDS_CLASS by fixing the case where nouveau would be built-in and the LEDS_CLASS would be built as as module. Cc: <stable at vger.kernel.org> # 4.9.x- Reported-by: Intel's 0-DAY Signed-off-by: Martin Peres <martin.peres at free.fr> --- drivers/gpu/drm/nouveau/Kbuild | 2 +- drivers/gpu/drm/nouveau/Kconfig | 9 +++++++++ 2 files changed, 10

On 23 August 2016 at 00:42, Martin Peres <martin.peres at free.fr> wrote: > v2: > - guard LED framework calls with ifdef CONFIG_LEDS_CLASS > IIRC kernel has the tendency of using static inlines in the headers when CONFIG_foo is not set. Worth using that and removing the ifdef from the source file ? -Emil

v2: - guard LED framework calls with ifdef CONFIG_LEDS_CLASS Signed-off-by: Martin Peres <martin.peres at free.fr> --- For real this time! Sorry for the noise drm/nouveau/Kbuild | 1 + drm/nouveau/include/nvkm/subdev/bios/gpio.h | 1 + drm/nouveau/nouveau_drm.c | 7 ++ drm/nouveau/nouveau_drv.h | 3 +

On Tue, May 3, 2016 at 7:51 PM, Martin Peres <martin.peres at free.fr> wrote: > We received a donation of a Titan which has this useless feature > allowing users to control the brightness of the LED behind the > logo of NVIDIA. In the true spirit of open source, let's expose > that to the users of very expensive cards! > > This patch hooks up this LED/PWM to the LED

maybe it makes sense to expose the SLI LED, too. Regardless of my comments this patch is reviewed-by me. 2016-08-23 1:39 GMT+02:00 Martin Peres <martin.peres at free.fr>: > We received a donation of a Titan which has this useless feature > allowing users to control the brightness of the LED behind the > logo of NVIDIA. In the true spirit of open source, let's expose > that

looks good, just a minor thing: You need to check for CONFIG_LEDS_CLASS, otherwise the compile throws out "warnings": WARNING: "led_classdev_register" [/home/karol/Dokumente/repos/nouveau/drm/nouveau/nouveau.ko] undefined! WARNING: "led_classdev_resume" [/home/karol/Dokumente/repos/nouveau/drm/nouveau/nouveau.ko] undefined! WARNING:

2016-11-08 17:12 GMT+01:00 Arnd Bergmann <arnd at arndb.de>: > On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: >> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: >> > The underlying problem is that we already have a number of other >> > symbols that either have "depends on LEDS_CLASS" or >> > "select

Reviewed-by: Karol Herbst <karolherbst at gmail.com> 2016-09-16 9:34 GMT+02:00 Martin Peres <martin.peres at free.fr>: > Signed-off-by: Martin Peres <martin.peres at free.fr> > --- > drm/nouveau/nouveau_led.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c > index

On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann <arnd at arndb.de> wrote: > The newly introduced LED handling for nouveau fails to link when the > driver is built-in but the LED subsystem is a loadable module: > > drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': > tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to `nouveau_led_suspend'

The proper fix would have been to select LEDS_CLASS but this can lead to a circular dependency, as found out by Arnd. This patch implements Arnd's suggestion instead, at the cost of some auto-magic for a fringe feature. Cc: <stable at vger.kernel.org> # 4.9.x- Reported-by: Arnd Bergmann <arnd at arndb.de> Reported-by: Intel's 0-DAY Fixes: 8d021d71b324

If CONFIG_DRM_NOUVEAU=y and CONFIG_LEDS_CLASS=m, then nouveau_led.o is neither stubbed out nor compiled in and the compile fails with undefined symbols in nouveau_drm.c. I'm guessing it's commit 8d021d71b324. (Thanks for the cool hack, BTW, even if I don't have such a card and am complaining about the patch.) Worked around by setting CONFIG_NEW_LEDS=n (it had been forced on by

Just some runtime PM fixes for some much less noticeable runtime PM ref tracking issues that I got reminded of when fixing some unrelated issues with nouveau. Changes since v1: * Don't fix CRTC RPM code in dispnv04, because it's not actually doing anything in the first place. Just get rid of it. - imirkin Lyude Paul (2): drm/nouveau/dispnv04: Remove runtime PM drm/nouveau/dispnv50:

Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nouveau_led.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c index 5e28b5f..1f731da 100644 --- a/drm/nouveau/nouveau_led.c +++ b/drm/nouveau/nouveau_led.c @@ -44,7 +44,10 @@ nouveau_led_get_brightness(struct led_classdev *led) div =

On 16/09/16 10:42, Karol Herbst wrote: > Reviewed-by: Karol Herbst <karolherbst at gmail.com> > > 2016-09-16 9:34 GMT+02:00 Martin Peres <martin.peres at free.fr>: >> Signed-off-by: Martin Peres <martin.peres at free.fr> >> --- >> drm/nouveau/nouveau_led.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git

Just some runtime PM fixes for some much less noticeable runtime PM ref tracking issues that I got reminded of when fixing some unrelated issues with nouveau. Lyude Paul (2): drm/nouveau/dispnv04: Grab/put runtime PM refs on DPMS on/off drm/nouveau/dispnv50: Fix runtime PM ref tracking for non-blocking modesets drivers/gpu/drm/nouveau/dispnv04/crtc.c | 18 +++---------