Bug 39550 - [NV96] Brightness stuck to low value after suspend/resume on HP Elitebook 8530w
Summary: [NV96] Brightness stuck to low value after suspend/resume on HP Elitebook 8530w
Status: NEEDINFO
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Roy
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-26 04:35 UTC by Auke Booij
Modified: 2016-11-15 17:45 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
vbios (64.00 KB, application/octet-stream)
2011-07-26 04:35 UTC, Auke Booij
no flags Details
dmesg|grep nouveau (5.84 KB, text/plain)
2011-07-26 05:19 UTC, Auke Booij
no flags Details
Dmesg output for the various testcases (3.20 KB, application/x-gzip)
2011-09-25 05:22 UTC, rick
no flags Details
rick's vbios (63.00 KB, application/octet-stream)
2011-09-28 08:02 UTC, rick
no flags Details
Enable the PANEL_BACKLIGHT_LEVEL GPIO (1.07 KB, patch)
2012-10-18 19:48 UTC, Emil Velikov
no flags Details | Splinter Review
DMESG kernel 3.10.10 (71.20 KB, text/plain)
2013-08-31 16:11 UTC, rick
no flags Details
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (2.81 KB, patch)
2013-09-01 14:42 UTC, Roy
no flags Details | Splinter Review
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v2) (2.98 KB, patch)
2013-09-01 15:28 UTC, Roy
no flags Details | Splinter Review
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v3) (2.70 KB, patch)
2014-06-08 07:07 UTC, Anonymous Helper
no flags Details | Splinter Review
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v4) (2.14 KB, patch)
2015-02-23 14:01 UTC, Erik Karlsson
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Auke Booij 2011-07-26 04:35:11 UTC
Created attachment 49565 [details]
vbios 

After a suspend/resume cycle, my brightness is stuck to some low value which can't be changed with the brightness buttons or nvapoke 0x61c084 0x80000200. Both of these do work before suspend.

Output of "nvapeek 0x61c084" (both before and after suspend/resume):
0061c084: 00000401

Attached is /sys/kernel/debug/dri/0/vbios.rom.
Comment 1 Auke Booij 2011-07-26 05:19:43 UTC
Created attachment 49572 [details]
dmesg|grep nouveau

dmesg|nouveau after said suspend/resume cycle
Comment 2 Emil Velikov 2011-07-26 11:13:31 UTC
Hi Auke

Would you consider this as a regression ?

Looking at your stripped log I can see "ACPI backlight interface available, not registering our own", thus I would say that the issue is not related to nouveau

Although can you please try the following

1 Boot into runlevel 3
   Append " 3" to your kernel command line

2 Make sure that nouveau is not loaded - "lsmod" will tell you if it is
2.1 Possible solution - blacklist nouveau

3 Try to adjust the brightness via acpi
3.1 Look for *brightness* in /sys/devices/ 
   find /sys/devices -name "*bright*" 2>/dev/null

4 Suspend
   pm-suspend

5 Resume

6 Try to adjust the brightness again

7 Confirm/dismiss if it is a nouveau related issue

I hope it helps

Cheers,
Emil
Comment 3 guido 2011-07-26 11:24:37 UTC
Please note that when I compared the openSUSE/jobermayr tree with mine from upstream, I found that the drm kernel module shipped by jobermayr and tagged as 20110721.2009-2.3 on openSUSE does ship separate and different ACPI bits (at least there should be differences in the include files).

I do not know if that helps... Here it does not even specify the version or whether it something that suddenly stopped working or otherwise something that never worked.
Comment 4 Emil Velikov 2011-07-26 12:06:17 UTC
Correction

3.1 Look for brightness and/or backlight in /sys
   find /sys -name "*brightness*" -o -name "*backlight*"

Most likely you will have files similar to

ls /sys/devices/pci0000:00/0000:00:0c.0/0000:02:00.0/backlight/acpi_video0/

  brightness   actual_brightness  max_brightness

You will have /sys/class/backlight, as well
Note that the /sys/class/backlight/acpi_video0 (or similar) should point to the above entry


Cheers
Emil
Comment 5 Auke Booij 2011-07-26 13:00:34 UTC
Emil:
As you suggested, I booted without nouveau into a terminal. Indeed I have these interfaces in /sys, and before suspend/resume I could control brightness as usual. After suspend/resume, the screen stayed black (supposedly the backlight was completely off). Blindly starting X, which loaded nouveau, turned the screen on and gave me the fixed low brightness as described earlier. Seems like it's not a nouveau issue after all, so what do I do now?

Guido:
This is an Arch Linux install, with linux 2.6.39, nouveau-dri 7.10.3 and an xf86-video-nouveau driver that's said to be version 0.0.16_git20110531.
Comment 6 Ben Skeggs 2011-08-09 23:14:08 UTC
Can I get the output of the following, both before and after suspend/resume

nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe100 8; nvapeek 0xe280 8
Comment 7 Ben Skeggs 2011-08-09 23:14:48 UTC
Correction:

nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
Comment 8 Auke Booij 2011-08-10 04:19:14 UTC
Can't really say if it's a regression, but it hasn't worked for me in a while and I never bothered fixing it.

# ./nvapeek 0xe100; ./nvapeek 0xe28c; ./nvapeek 0xe104 8; ./nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000180
0000e104: 72266640 0441474b
0000e280: 24444747 00000000

UPower suspend...

# ./nvapeek 0xe100; ./nvapeek 0xe28c; ./nvapeek 0xe104 8; ./nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000180
0000e104: 72266240 0441474b
0000e280: 24444747 00000000
Comment 9 Ben Skeggs 2011-08-10 15:53:47 UTC
Heh. Okay.. Well, everything I know of on the GPU side that's relevant to the backlight level appears to be in order.. So, I'm out of ideas for the moment.
Comment 10 Emil Velikov 2011-09-22 14:16:00 UTC
Auke

Can you try the following

1. Boot with "nouveau.force_post=1" appended to your kernel command like
2. Do not suspend, but simply try to change the brightness

If it is stuck then the issue may be nouveau related, if not ...

Btw have you tried the blob ? Does it have the same issue


Cheers
Emil
Comment 11 rick 2011-09-25 03:13:15 UTC
I have the exact same problem as Auke, for as long as I have the laptop (about 2 years). This problem used to occur with the blob as well (if I remember correctly) but it does work now.
I am using an HP Elitebook 8530w (nVidia Corporation G96M [Quadro FX 770M] (rev a1)) on fedora 15.
dmesg says: nouveau 0.0.16 20090420
yum says: xorg-x11-drv-nouveau.x86_64 1:0.0.16-24.20110324git8378443.fc15
mesa-dri-drivers: 7.11-1

(In reply to comment #10)
> Auke
> 
> Can you try the following
> 
> 1. Boot with "nouveau.force_post=1" appended to your kernel command like
> 2. Do not suspend, but simply try to change the brightness
> 
> If it is stuck then the issue may be nouveau related, if not ...
> 
> Btw have you tried the blob ? Does it have the same issue
> 
> 
> Cheers
> Emil

Brightness control does not work with this option for me.
Comment 12 Emil Velikov 2011-09-25 04:21:32 UTC
Rik

Can you please indicate what exactly do you mean with

"Brightness control does not work with this option for me."

Does it work before suspending the system?

Can you please attach your dmesg log, as it is the one relevant in this case (whereas xf86-video-nouveau, mesa and libdrm are not)


Auke, Rik

AFAIK brightness/backlight is(can be) controlled via
1. ACPI
2. platform specific - (asus-laptop, samsung-laptop, thinkpad ...)
3. the gpu/card itself

On various system different ones work correctly

By default nouveau does not register it's device if an ACPI one exists
Note that the blob has similar behaviour but they have an option to override it.

If you suspect that the ACPI backlight control is buggy you can disable it by appending "acpi_backlight=vendor" to your kernel command line

This will fall back to either 2. or 3. - dmesg will tell you which one

Feel free to give it a try

Cheers
Emil
Comment 13 rick 2011-09-25 05:08:35 UTC
(In reply to comment #12)
> Rik
> 
> Can you please indicate what exactly do you mean with
> 
> "Brightness control does not work with this option for me."
>
> Does it work before suspending the system?
Brightness control does not work before suspend, I did not try suspending. So no.
> Can you please attach your dmesg log, as it is the one relevant in this case
> (whereas xf86-video-nouveau, mesa and libdrm are not)

will post in a few minutes (need to get laptop)

> 
> Auke, Rik
> 
> AFAIK brightness/backlight is(can be) controlled via
> 1. ACPI
> 2. platform specific - (asus-laptop, samsung-laptop, thinkpad ...)
> 3. the gpu/card itself
> 
> On various system different ones work correctly
> 
> By default nouveau does not register it's device if an ACPI one exists
> Note that the blob has similar behaviour but they have an option to override
> it.
> 
> If you suspect that the ACPI backlight control is buggy you can disable it by
> appending "acpi_backlight=vendor" to your kernel command line

I tried that. It works exactly the same as without this option. Brightness control works fine before suspend, fails after.

> This will fall back to either 2. or 3. - dmesg will tell you which one
> 
> Feel free to give it a try
> 
> Cheers
> Emil
Comment 14 rick 2011-09-25 05:22:14 UTC
Created attachment 51586 [details]
Dmesg output for the various testcases

dmesgbacklightisvendor.txt : using acpi_backlight=vendor
dmesgforcepost.txt : using nouveau.force_post=1
dmesgnormal.txt : default
Comment 15 Emil Velikov 2011-09-26 12:16:29 UTC
(In reply to comment #13)
[snip]
> Brightness control does not work before suspend, I did not try suspending. So
> no.
[snip]
> I tried that. It works exactly the same as without this option. Brightness
> control works fine before suspend, fails after.

I see a bit of contradiction in here

Firstly can you try nouveau kernel git tree [1], as it includes some patches regarding backlight/brightness

Note: Fedora may have precompiled package that is up-to date (search for koji)

If it still fails please record the following 

example
"with option "xxxxx" (acpi_backlight=vendor, nouveau.force_post=1)
before suspend - works, after - stuck"

it may be worth checking the registers (see comment 7) in each case as well

Cheers
Emil

[1] http://cgit.freedesktop.org/nouveau/linux-2.6/
Comment 16 rick 2011-09-27 07:05:55 UTC
(In reply to comment #15)
> (In reply to comment #13)
> [snip]
> > Brightness control does not work before suspend, I did not try suspending. So
> > no.
> [snip]
> > I tried that. It works exactly the same as without this option. Brightness
> > control works fine before suspend, fails after.
> 
> I see a bit of contradiction in here
> 
> Firstly can you try nouveau kernel git tree [1], as it includes some patches
> regarding backlight/brightness
> 
> Note: Fedora may have precompiled package that is up-to date (search for koji)

I cloned the git repo you linked, and compiled my kernel (which works), but it has the exact same issues as before.
$ uname -r
3.1.0-rc7+

> If it still fails please record the following 
> 
> example
> "with option "xxxxx" (acpi_backlight=vendor, nouveau.force_post=1)
> before suspend - works, after - stuck"
> 
with option: none
before suspend: works, after: stuck to low value
with option: nouveau.force_post=1
before suspend: stuck to low value, after: stuck to low value
with option: acpi_backlight=vendor
before suspend: works, after: stuck to low value
with option: acpi_backlight=vendor nouveau.force_post=1
before suspend: stuck to low value, after: stuck to low value

> it may be worth checking the registers (see comment 7) in each case as well

Maybe tomorrow, it took me long enough to get that kernel working. (I need envytools right?)

> Cheers
> Emil
> 
> [1] http://cgit.freedesktop.org/nouveau/linux-2.6/
Comment 17 Emil Velikov 2011-09-27 11:52:06 UTC
(In reply to comment #16)
> with option: none
> before suspend: works, after: stuck to low value
> with option: nouveau.force_post=1
> before suspend: stuck to low value, after: stuck to low value
> with option: acpi_backlight=vendor
> before suspend: works, after: stuck to low value
> with option: acpi_backlight=vendor nouveau.force_post=1
> before suspend: stuck to low value, after: stuck to low value

Thanks this is great

> 
> > it may be worth checking the registers (see comment 7) in each case as well
> 
> Maybe tomorrow, it took me long enough to get that kernel working. (I need
> envytools right?)
Yes you would need envytools

Peeks for "none" and "nouveau.force_post=1" would be enough - before and after suspend
Can you attach your vbios as well please [2]

[2] $ nvagetvbios > vbios.rom

Cheers
Emil

> 
> > Cheers
> > Emil
> > 
> > [1] http://cgit.freedesktop.org/nouveau/linux-2.6/
Comment 18 rick 2011-09-28 08:01:55 UTC
(In reply to comment #17)
> Peeks for "none" and "nouveau.force_post=1" would be enough - before and after
> suspend
normal boot:

# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000
# pm-suspend
# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000
 


using option: nouveau.force_post=1

# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000
# pm-suspend
# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000

> Can you attach your vbios as well please [2]
> 
> [2] $ nvagetvbios > vbios.rom

nvagetvbios didnt exist, so I used nvagetbios (I assume you made a typo)
> 
> Cheers
> Emil
>
Comment 19 rick 2011-09-28 08:02:40 UTC
Created attachment 51716 [details]
rick's vbios
Comment 20 Auke Booij 2011-12-12 01:56:46 UTC
Any updates regarding this bug?
Comment 21 Jesse Brandeburg 2012-01-30 13:00:11 UTC
I am experiencing this bug as well, HP 8530W, brightness controls don't work after resume.
Comment 22 Jesse Brandeburg 2012-01-30 17:57:33 UTC
I tried force_post=1, screen is dark even before suspend (even before going into X, just loading frame buffer) - this is a clue the driver is forcing the brightness into this mode, right?

Of course, the tip of tree nouveau won't even load now due to the MXM changes, so I haven't been able to test *it* yet, but that is another bug that I'm trying to help narrow down.
Comment 23 Walther 2012-02-14 07:13:42 UTC
There should be a solution to this dilemma, considering that nvidia's binary blob does it correctly.

I got the nvapeek results for using the binary blob, and the results I got are:

Before
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000

After
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000

Notice that unlike nouveau, register 0xe104's content is unaltered after resuming. What is this particular register for?

The vbios before suspending is identical between nouveau and nvidia, and it is also identical to the one after resuming with nvidia. However, nvgetbios fails with nouveau after resuming:

./nvagetbios > vbios.txt
No extraction method specified (using -s extraction_method). Defaulting to PRAMIN.
Attempt to extract the vbios from card 0 (nv96) using PRAMIN
Invalid signature(0x55aa). You may want to try another retrieval method.

Is this a sign that the vbios is somehow wrong/corrupted after resume?

Note that I am also using a Elitebook 8530W, with an nVidia Corporation G96M [Quadro FX 770M] card, using Linux 3.1.10.
Comment 24 Emil Velikov 2012-02-14 14:29:23 UTC
Did you have the chance to test a kernel that includes the following commit

"drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues"


It does rework the gpio handling and initialization (among other things), that should have positive effect on your issue 

It is part of linux 3.3rc1 [1] as well as nouveau linux tree [2]


Cheers
Emil


[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=a0b25635515ef5049f93b032a1e37f18b16e0f6f

[2] http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a0b25635515ef5049f93b032a1e37f18b16e0f6f
Comment 25 Jesse Brandeburg 2012-02-14 15:48:35 UTC
Hi Emil, thanks. Behavior is unchanged with new kernels. I've tested through nouveau commit:

commit 9a0a03b43176ee676693232f2afe92b83b15233e
Author: Roy Spliet <r.spliet@student.tudelft.nl>
Date:   Tue Feb 7 00:29:06 2012 +0100

    drm/nouveau/pm: several fixes for nvc0 memory timings

and 3.3.0-rc2 (actually the above is on top of)
which contains a0b2563

commit 62aa2b537c6f5957afd98e29f96897419ed5ebab
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Jan 31 13:31:54 2012 -0800

    Linux 3.3-rc2

with no change, from that patch or any other.

in fact nvapeek (nouveau git with 3.3.0-rc2) shows:
before suspend:
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000

after:
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000

the only difference I see is e104 bit 10 being set before, and not after.

NOTE: I have the exact same laptop as Walther.
Comment 26 Walther 2012-02-20 06:16:42 UTC
I repeated testing using kernel 3.3.0 RC4, and results are similar:

nvapeek (before):
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72267640 0441474b
0000e280: 44444747 00000000

After:
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72267240 0441474b
0000e280: 44444747 00000000

Compared to the previous version, the only change is that 0x1000 was added to 0xe104 (and 0x400 is still unset on resume). And, of course, brightness controls ceased to response after resuming.

PS: What still worries me is that after resuming nvagetbios still fails, that is a definite vbios bug/corruption somewhere, isn't it...
Comment 27 Jesse Brandeburg 2012-04-04 09:55:25 UTC
Is there anything I can do to help fix this?  Willing to provide any data and debug, including remote access if that would help.
Comment 28 bugs.30.kappa 2012-04-05 18:19:30 UTC
Experiencing a similar issue on a Lenovo W510 (FX880m), Fedora 17 Beta RC3, with the difference that after suspend the brightness is set to max, after that brightness controls do not work (nor do echos to /sys/..). Things are fine with the NVIDIA driver.
Comment 29 bugs.30.kappa 2012-04-11 04:01:10 UTC
Is there a way I can help by providing more information or trying a new version?
Comment 30 xvalentinex 2012-04-13 23:38:14 UTC
Congratulations on going stable!  I am experiencing this issue as well, and this is the one bug keeping me from using Nouveau.  I would really like to have xrandr 1.2 support, so please let me know if there is anything I could provide to help troubleshoot this.

Notes:
Thinkpad W510

01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [Quadro FX 880M] (rev a2)

When using the nvidia driver, the following option needs to be added to the X config file.
Option "RegistryDwords" "EnableBrightnessControl=1"

When using the nouveau driver, brightness controls works fine.  After suspend and resume, brightness stuck on max.
Comment 31 cl.relay 2012-05-28 06:43:43 UTC
Applies to me as well on a W510 


Linux w510 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Comment 32 Emil Velikov 2012-06-24 15:31:19 UTC
It appears that even the blob was experiencing the same issue [1]

Affected blob 180.44, fixed in 180.60. I would expect that a specific quirk was added to handle the issue

[1] http://www.bartromgens.org/wordpress/?p=274
Comment 33 ChriS 2012-10-06 18:16:02 UTC
(In reply to comment #32)

I confirm that this issue is present on the Thinkpad W510 with the driver from kernel 3.6.0.
Comment 34 ChriS 2012-10-06 20:03:55 UTC
The problem is still present in the git version of the driver.
Comment 35 ChriS 2012-10-15 07:08:36 UTC
Still present in kernel 3.6.2, even with acpi_backlight=vendor nouveau.force_post=1 and "Support for backlight control" disabled in the kernel configuration.

The funny thing is that the display seem to come back at the right brightness initially and then is changed to max brightness a second after.

Like many people, this bug unfortunately prevents me to switch to the free driver.  It would be really nice if it was fixed.
Comment 36 Emil Velikov 2012-10-18 19:48:45 UTC
Created attachment 68764 [details] [review]
Enable the PANEL_BACKLIGHT_LEVEL GPIO

Guys can you try the patch. It should apply against the latest nouveau tree
Comment 37 Walther 2012-10-29 12:07:38 UTC
I couldn't get the git kernel, so I tried that patch against linux-3.7-rc3. Unfortunately, it didn't change anything in my set up (Elitebook 8530w, NVIDIA Corporation G96M [Quadro FX 770M] card).
Comment 38 Ben Skeggs 2013-01-13 08:10:30 UTC
This bug is likely fixed in current nouveau kernel git.
Comment 39 Ilia Mirkin 2013-08-31 04:28:37 UTC
Can someone confirm that this is fixed in newer kernels as Ben said it should be?
Comment 40 rick 2013-08-31 12:22:23 UTC
This bug is still present.


[root@s094648 rick]# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000
[root@s094648 rick]# systemctl suspend
[root@s094648 rick]# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444444 00000000
[root@s094648 rick]# uname -a
Linux s094648 3.10.10-1-ARCH #1 SMP PREEMPT Fri Aug 30 11:30:06 CEST 2013 x86_64 GNU/Linux
Comment 41 Ilia Mirkin 2013-08-31 15:45:28 UTC
What backlight driver is being used? Please post your dmesg. Are you booting with acpi_backlight=vendor ?
Comment 42 rick 2013-08-31 16:11:29 UTC
Created attachment 84974 [details]
DMESG kernel 3.10.10
Comment 43 rick 2013-08-31 16:13:36 UTC
(In reply to comment #41)
> What backlight driver is being used? Please post your dmesg. Are you booting
> with acpi_backlight=vendor ?

No, I am booting with the following command line:
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=d30907c8-9c00-4b4f-9dfb-b01990328a7a rw loglevel=3

Also, is there an IRC channel or something I could join to speed up communication regarding this bug?
Comment 44 Roy 2013-09-01 12:28:25 UTC
(In reply to comment #36)
> Created attachment 68764 [details] [review] [review]
> Enable the PANEL_BACKLIGHT_LEVEL GPIO
> 
> Guys can you try the patch. It should apply against the latest nouveau tree

NACK on this patch: this particular pin should be driven by a PWM in SOR, as indicated in 0xe100. Rather look if routing from PWM to GPIO pin is correct...
Comment 45 Roy 2013-09-01 14:42:26 UTC
Created attachment 85010 [details] [review]
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised

Auke, Rick, Jesse: please test the attached patch. It should initialise PWM_DIV on both boot and resume, solving your problems _if_ this routine is called after running the initscripts. Please test to verify this is the case.
Comment 46 Roy 2013-09-01 15:28:20 UTC
Created attachment 85012 [details] [review]
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v2)

V2 fixes the reach of this patch.
From what I can tell the PWM_DIV is simply a divider for the initial PWM clock or something, it does not affect the scope of the duty cycle. I therefore assume 0x5e is always a good value to set. Traces from NV50:NVA0 would help verify whether NVIDIA always sets this value or not.
This patch requires acpi_backlight=vendor to be set because it tests for the presence of a backlight by testing drm->backlight. An alternative to this test would be checking for the GPIO to be present and routed to SOR, but I wouldn't be surprised if there is at least one device that expects our driver to route it manually. How should we go about this?
Comment 47 Erik Karlsson 2014-02-16 16:15:01 UTC
I can confirm that the patch "drm/nv50: Fix backlight[...](v2)" works for a HP 8530w. Any chance of getting this included upstream?
Comment 48 Anonymous Helper 2014-06-08 07:07:22 UTC
Created attachment 100635 [details] [review]
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v3)

Applying Roy's 0001-drm-nv50-Fix-backlight-not-working-when-PWM_DIV-is-u.patch (v2) to linux-3.15-rc8 results in a compilation error.

...
  CC      drivers/gpu/drm/nouveau/nouveau_display.o
drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_display_init’:
drivers/gpu/drm/nouveau/nouveau_display.c:400:5: error: ‘drm’ undeclared (first use in this function)
  if(drm->backlight)
     ^
drivers/gpu/drm/nouveau/nouveau_display.c:400:5: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:318: recipe for target 'drivers/gpu/drm/nouveau/nouveau_display.o' failed
make[4]: *** [drivers/gpu/drm/nouveau/nouveau_display.o] Error 1
scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm/nouveau' failed
make[3]: *** [drivers/gpu/drm/nouveau] Error 2
scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:465: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:878: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Resolved by adding the following line to the beginning of the nouveau_display_init function in nouveau_display.c:

        struct nouveau_drm *drm = nouveau_drm(dev);

I tried to make a patch and attach it - not sure if I did it right.

This patch successfully resolved the "backlight brightness stuck at minimum after waking up from suspend" issue on my HP Elitebook 8530w.

Thank you, Roy! Your code has improved my life significantly.
Comment 49 Erik Karlsson 2014-11-14 15:12:35 UTC
Not to be a nag, but multiple people have confirmed that the patch fixes the problem. What are the prerequisites for merging this?
Comment 50 Erik Karlsson 2015-02-23 14:01:48 UTC
Created attachment 113754 [details] [review]
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v4)

I redid the patch for 3.18.6. Not sure what the use of removed nvif_rd32() chunk was, but it doesn't seem to be necessary anymore.

Could this fix be predicated on the specific PCI ID if the effects are uncertain?
Comment 51 Roy 2015-02-23 22:44:00 UTC
(In reply to Erik Karlsson from comment #50)
> Created attachment 113754 [details] [review] [review]
> drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v4)
> 
> I redid the patch for 3.18.6. Not sure what the use of removed nvif_rd32()
> chunk was, but it doesn't seem to be necessary anymore.
> 
> Could this fix be predicated on the specific PCI ID if the effects are
> uncertain?

No, the value of NV50_PDISP_SOR_PWM_DIVis not derived from the PCI ID. Judging by some other traces I've seen, we can't just unconditionally set 0x5e to NV50_PDISP_SOR_PWM_DIV. Rather, someone needs to step up and figure out how this parameter is correctly determined, which requires some RE'ing work on a laptop that actually has it's brightness controlled by the NVIDIA GPU rather than ACPI or some other backlight component. Only then a patch like this can be merged.
Comment 52 Erik Karlsson 2015-02-25 15:25:21 UTC
Is this reverse engineering something I could do myself using software, or does it require active fiddling with the registers?
Comment 53 Jeffery Miller 2016-11-15 17:45:51 UTC
I have an NVAC (MCP79) in an iMac9,1 for which the backlight controls do not work if NV50_PDISP_SOR_PWM_DIV(0x61c080) is set to 0x5e. If it is useful at all I have attached an mmiotrace dump with from various backlight control setting changes using the nvidia blob in another bug report (#98677).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.