Nouveau - Nov 2016 - [Bug 98677] New: [NVAC] iMac9, 1 effective backlight brightness range changes after S3

https://bugs.freedesktop.org/show_bug.cgi?id=98677

            Bug ID: 98677
           Summary: [NVAC] iMac9,1 effective backlight brightness range
                    changes after S3
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: jefferym at gmail.com
        QA Contact: xorg-team at lists.x.org

Created attachment 127900
  --> https://bugs.freedesktop.org/attachment.cgi?id=127900&action=edit
dmesg output after the resume with some nouveau trace options

I have an iMac 9,1 where the behaviour of the backlight of the built in screen
works differently between the first boot and after a suspend to ram.
It appears to be darker at lower values before a suspend than after.

kernel: 4.8.6-300.fc25.x86_64
lspci adapter: VGA adapter NVIDIA Corporation C79 [GeForce 9400] [10de:0867]
DMI: Apple Inc. iMac9,1/Mac-F2218EA9
I've been booting in EFI mode.
I do not know of a regression. I've only tried 4.4 and this 4.8 kernels.
I've observed this with X running but I've been testing this without
starting a
graphical environment.

I've been testing by setting setting backlight values via the
/sys/backlight/nv_backlight/brightness interface.
Before a suspend I can set values such as 40, 70, 100 and the brightness seems
to be reasonable on the screen.

I then suspend to ram via the /sys/power/state interface.
Upon resuming the backlight appears to be at 100 percent. If I set the
brightness to values such as 30 and 60 the screen remains dark. It is barely
visible as a flicker at 70. At 100 it is visible.

I've observed that the value of NV50_PDISP_SOR_PWM_DIV (0x0061c080) is 0x1
after a boot but is set to 0x84 after a resume.
It appears there's an init script in the bios dump which sets it to the
value
of 0x84. I have confirmed if I use the nouveau option
nouveau.config=NvForcePost=1 that the behavior after booting is the same as
after a resume. The value of 0x61c080 is 0x84.

If I `nvapoke 0x061c080 0x1` after a resume the backlight seems to work fairly
well. I created patch to test this. I expect it isn't the proper solution.

I'm attaching the dmesg which includes a resume with the nouveau driver.
I'll also attach the vbios dump, acpidump, dmidecode, lspci, 

I've gathered an mmiotrace of the binary driver as it sets a few brightness
values as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/9b9fb28b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #1 from Jeffery Miller <jefferym at gmail.com> ---
Created attachment 127901
  --> https://bugs.freedesktop.org/attachment.cgi?id=127901&action=edit
ACPI dump of the system

acpidump of the system

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/9b2678ea/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #2 from Jeffery Miller <jefferym at gmail.com> ---
Created attachment 127902
  --> https://bugs.freedesktop.org/attachment.cgi?id=127902&action=edit
dmidecode binary output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/550d6a32/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #3 from Jeffery Miller <jefferym at gmail.com> ---
Created attachment 127903
  --> https://bugs.freedesktop.org/attachment.cgi?id=127903&action=edit
lspci output for the machine

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/6c792ab7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #4 from Jeffery Miller <jefferym at gmail.com> ---
Created attachment 127904
  --> https://bugs.freedesktop.org/attachment.cgi?id=127904&action=edit
VBIOS retrieved with nvagetbios

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/7841d267/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #5 from Ilia Mirkin <imirkin at alum.mit.edu> ---
An observation is that the nouveau code in nva3_get/set_intensity takes the
existing divider into account. However we only use that for nva3/5/8/f, not
nvaa/nvac.

Could you try changing nouveau_backlight.c:nv50_backlight_init to use
nva3_bl_ops for your chipset and seeing whether that fixes everything?

(Let me know if you're not sure how to do that, and I can put a patch
together.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/053eae8a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #6 from Jeffery Miller <jefferym at gmail.com> ---
Created attachment 127905
  --> https://bugs.freedesktop.org/attachment.cgi?id=127905&action=edit
mmiotrace of nvidia driver performing brightness changes

mmio trace of the nvidia driver 340.96
I set the brightness with the nvidia-settings command following the steps:

   modprobe nvidia-uvm
   Xorg &
   DISPLAY=:0 nvidia-settings -n -a BacklightBrightness=50
   DISPLAY=:0 nvidia-settings -n -a BacklightBrightness=70
   DISPLAY=:0 nvidia-settings -n -a BacklightBrightness=100

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/4d7b5403/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #7 from Jeffery Miller <jefferym at gmail.com> ---
I will patch and attempt to use the nva routines and report back.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/51f0e494/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #8 from Jeffery Miller <jefferym at gmail.com> ---
I patched as suggested having it use the nva3_bl_ops. The backlight remained
dark in this case. I was able to get the backlight to turn on by setting values
with nvapoke to match values I had seen earlier:

nvapoke 0x0061c080 0x1
nvapoke 0x0061c084 0x80000401

I noticed from the mmiotrace of the binary driver that it seems to set these
two registers when the brightness changes.
I'm away from the machine at the moment to post the details that seemed
relevant to me. 

I am not sure which registers might be important to check before and after. 

I'll look at the trace again and pop into it for some questions

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161110/0bb0d29f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #9 from Jeffery Miller <jefferym at gmail.com> ---
I tried a few more brightness tests with the nvidia binary blob. There's a
similar mmiotrace already attached.

I've observed that the nvidia driver sets the values of 
I observed that the nvidia driver sets both 0x0061c080 and 0x0061c084 on each
brightness change.
It always sets 0x0061c080 to 0x17 and 61c084 with the following
percent values:

% setting    |  0x0061c084 poke
---
21              0x800000d8
22              0x800000e2
30              0x80000134
50              0x80000201
70              0x800002ce
78              0x80000320
100             0x80000401

I noticed that if I change value to 21% (d8) or below the screen is dark/black.
It then stays dark at levels such as 30%, 50%, and such that worked previously.
If I set it to 78% or 100% the screen will appear again. Once it reappears the
50%, 30% values work as they did previously.

I patched the nouveau backlight code to always set the PWM_DIV to 0x17. The
nouveau driver then behaved the same for the various percent values mentioned
above. It also had the off at low requiring a high % to have it show again.

I reverted to my original patch which would always set the DIV to 0x1 on each
change. This makes it consistent with the fresh boot value. This has the side
effect that after a post (and a resume from suspend) the value is always the
same.
The visible range is wider for the 0x1 case. The screen doesn't turn fully
dark
until around 14%. Additionally it would return to the previous value without
having to jump all the way up to a high value. It could go from the 14% off
case back to 50% and the screen had the same brightness. I am observing the
brightness with my eye.
The percent to DUTY value being set to 0x61c084 is similar in each driver.
Nouveau sets 0x401 for 100%, 0x200 for 50%.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161111/13c7e8aa/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #10 from Jeffery Miller <jefferym at gmail.com> ---
Created attachment 127925
  --> https://bugs.freedesktop.org/attachment.cgi?id=127925&action=edit
Force NV50_PDISP_SOR_PWM_DIV when setting brightness for the iMac9,1 subvendor

This patch always sets the div to 0x1 for the device on this machine. It allows
consistent behavior between the first boot of the system and after a resume.

I apply it on each backlight change mimicking the nvidia blob's behavior in
this case. However, the nvidia blob sets the value to 0x17 in my observations.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161111/83991c20/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #11 from Jeffery Miller <jefferym at gmail.com> ---
I was prepared to implement some additions to adjust the values to make the
percentage values representative of the output.
I realized there is an apple_bl acpi backlight driver that may be applicable to
this problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161112/e399ad6d/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98677

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #12 from Martin Peres <martin.peres at free.fr> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/301.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/9ced3e0c/attachment.html>