Bug 198885 - amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".
Summary: amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or...
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-22 13:13 UTC by Przemek
Modified: 2018-03-28 00:20 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.15.4
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg with "amdgpu.dc=1" (61.85 KB, text/plain)
2018-02-22 13:13 UTC, Przemek
Details

Description Przemek 2018-02-22 13:13:21 UTC
Created attachment 274359 [details]
dmesg with "amdgpu.dc=1"

I am using gentoo ~amd64, kernel 4.15.4, amdgpu with amdgpu.dc=1 on CIK A6 APU - R4 Mullins.

There is no possibility to change brightness level both with Fn keys or directly by an "echo" command, even as root when "amdgpu.dc=1" is set:

ls -l /sys/class/backlight/amdgpu_bl0/
razem 0
-r--r--r-- 1 root root 4096 02-22 13:41 actual_brightness
-rw-r--r-- 1 root root 4096 02-22 13:41 bl_power
-rw-r--r-- 1 root root 4096 02-22 13:41 brightness
lrwxrwxrwx 1 root root    0 02-22 13:41 device -> ../../../0000:00:01.0
-r--r--r-- 1 root root 4096 02-22 13:40 max_brightness
drwxr-xr-x 2 root root    0 02-22 13:41 power
lrwxrwxrwx 1 root root    0 02-22 13:40 subsystem -> ../../../../../class/backlight
-r--r--r-- 1 root root 4096 02-22 13:40 type
-rw-r--r-- 1 root root 4096 02-22 13:39 uevent


"/sys/class/backlight/amdgpu_bl0 # echo 22 > actual_brightness
bash: actual_brightness: permission denied"

and 

"/sys/class/backlight/amdgpu_bl0 # echo 128 > brightness
bash: echo: błąd zapisu: Bad argument"

Without "amdgpu.dc=1" in kernel command line changing brightness level is working as expected, both Fn keys, and echoing directly to a file.

I know that there are plans enabling amdgpu.dc by default, so impossibility to change brightness level IMHO is a big "no go".
Comment 1 Michel Dänzer 2018-02-22 15:26:22 UTC
(In reply to Przemek from comment #0)
> -r--r--r-- 1 root root 4096 02-22 13:41 actual_brightness
[...]
> "/sys/class/backlight/amdgpu_bl0 # echo 22 > actual_brightness
> bash: actual_brightness: permission denied"

As you can see above, this file is read-only.


> "/sys/class/backlight/amdgpu_bl0 # echo 128 > brightness
> bash: echo: błąd zapisu: Bad argument"

What does

 cat max_brightness

say? If it's a value smaller than 128, does writing a value <= that to the brightness file work?


> Without "amdgpu.dc=1" in kernel command line changing brightness level is
> working as expected, both Fn keys, and echoing directly to a file.

What values do the brightness, max_brightness and actual_brightness files contain in that case?
Comment 2 Przemek 2018-02-22 16:36:12 UTC
Hi Michel,

Thank you very much for insane-fast response.

Yes, "actual_brightness" is a bad example, same occurs on this file without "amdgpu.dc=1".

Here are values from requested files:

"/sys/class/backlight/amdgpu_bl0 # cat brightness
3" 

"/sys/class/backlight/amdgpu_bl0 # cat max_brightness
255"

"/sys/class/backlight/amdgpu_bl0 # cat actual_brightness
3"

I have tried different values also:
"/sys/class/backlight/amdgpu_bl0 # echo 100 > brightness
bash: echo: błąd zapisu: Bad argument
/sys/class/backlight/amdgpu_bl0 # echo 50 > brightness
bash: echo: błąd zapisu: Bad argument
/sys/class/backlight/amdgpu_bl0 # echo 10 > brightness
bash: echo: błąd zapisu: Bad argument"
Comment 3 Przemek 2018-02-22 17:01:03 UTC
And here values from requested files without "amdgpu.dc=1"

"/sys/class/backlight/amdgpu_bl0 # ls -l
razem 0
-r--r--r-- 1 root root 4096 02-22 17:50 actual_brightness
-rw-r--r-- 1 root root 4096 02-22 17:50 bl_power
-rw-r--r-- 1 root root 4096 02-22 17:39 brightness
lrwxrwxrwx 1 root root    0 02-22 17:50 device -> ../../card0-eDP-1
-r--r--r-- 1 root root 4096 02-22 17:39 max_brightness
drwxr-xr-x 2 root root    0 02-22 17:50 power
lrwxrwxrwx 1 root root    0 02-22 17:39 subsystem -> ../../../../../../../class/backlight
-r--r--r-- 1 root root 4096 02-22 17:39 type
-rw-r--r-- 1 root root 4096 02-22 17:38 uevent"

"/sys/class/backlight/amdgpu_bl0 # cat brightness
23"

"/sys/class/backlight/amdgpu_bl0 # cat actual_brightness
23"

"/sys/class/backlight/amdgpu_bl0 # cat max_brightness
255"


With smaller values from previous post (with "amdgpu.dc=1" on kernel commandline) screen is much brighter, as backlight was set almost 100%.
Comment 4 Harry Wentland 2018-02-23 14:24:50 UTC
Thanks for reporting this. It's currently not hooked up for ASICs older than Carrizo. We'll take a look. 

You're right that it clashes with the kernel's 'no regressions' policy should we change pre-VEGA ASIC support with DC to enabled by default.
Comment 5 Przemek 2018-02-23 16:12:02 UTC
(In reply to Harry Wentland from comment #4)
> Thanks for reporting this. It's currently not hooked up for ASICs older than
> Carrizo. We'll take a look. 
> 
> You're right that it clashes with the kernel's 'no regressions' policy
> should we change pre-VEGA ASIC support with DC to enabled by default.

Hi Harry,

I am glad to hear that the reason is already known, and we are not searching it blindly.

There is still time till 4.17 merge window ends, so if you would like me to try out some patches, please do not hesitate.

Thanks,
Przemek.
Comment 6 Harry Wentland 2018-03-27 15:44:00 UTC
Can you try the drm-next-4.17-wip branch from https://cgit.freedesktop.org/~agd5f/linux? This should be fixed there.
Comment 7 Przemek 2018-03-28 00:20:22 UTC
Sorry for the delay but I had to git clone whole agd5f branch repo once again since I was moving my installation to another drive.

Moreover I had kernel panic with PSP platform module turned on (CONFIG_CRYPTO_DEV_SP_PSP), but it is not the case of this bug report. (BTW as from the specs this apu has one included).

Brightness keys are working as expected, /sys/class/backlight/amdgpu_bl0/brightness is now editable by "echo", Display Core is initialized with v3.1.40, so I am closing this bug report as solved/code fix.

Thank you very much for fast and accurate action on this. Done to a turn.

Thanks once again,
Przemek.

Note You need to log in before you can comment on or make changes to this bug.