[AMD Official Use Only - Internal Distribution Only] Hi Harry,
It does sound like a firmware issue. I think we will need to do some investigation here. I would be curious if this is a driver regression or just never worked (not sure how new the driver being tested is). This point below seems to indicate the firmware might be using some uninitialized values in some if its calculations. Typically these value would be things like backlight characteristic curves that are passed to the firmware via a table generated in the power helpers file, and programmed in our dc code. I'm not 100% sure this is the problem, but it could be something we can take a look at from dmcu_load_iram. >> There's a bugreport on the tracker from a person with the same laptop >> model as mine that says that the threshold may vary from boot to boot. Thanks, Anthony -----Original Message----- From: Wentland, Harry <harry.wentl...@amd.com> Sent: Wednesday, May 20, 2020 5:53 PM To: Alex Deucher <alexdeuc...@gmail.com>; Alexander Monakov <amona...@ispras.ru>; Kazlauskas, Nicholas <nicholas.kazlaus...@amd.com>; Li, Sun peng (Leo) <sunpeng...@amd.com> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>; Deucher, Alexander <alexander.deuc...@amd.com>; Chiu, Michael <michael.c...@amd.com>; Koo, Anthony <anthony....@amd.com> Subject: Re: Flaky brightness on Renoir We've seen similar problems internally. Michael, does this "fix" your issue? Anthony, looks like smooth_brightness is problematic on (some) renoir systems. Thoughts? Thanks, Harry On 2020-05-20 5:47 p.m., Alex Deucher wrote: > Adding some display people. > > On Wed, May 20, 2020 at 5:46 PM Alexander Monakov <amona...@ispras.ru> wrote: >> >> Hello, >> >> I have a laptop with the recent Renoir SoC. Screen brightness is >> controlled via the amdgpu driver. Unfortunately it doesn't work >> properly: brightness doesn't go below a certain threshold. In one >> experiment I've found the threshold to be about 95 (of 255), which is >> quite high. >> >> There's a bugreport on the tracker from a person with the same laptop >> model as mine that says that the threshold may vary from boot to boot. >> >> So far I was able to find a workaround: avoiding >> dmcu_set_backlight_level like in the patch below gives more reliable >> backlight control (but at the expense of breaking "actual_brightness" >> sysfs file, because it reads from DMCU registers). >> >> What might be the problem and can I help investigate this further? >> Would really like to see this work properly. >> >> Alexander >> >> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c >> b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c >> index b8a3fc505c9b..3274b0d15893 100644 >> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c >> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c >> @@ -428,7 +428,7 @@ static bool dce_abm_set_backlight_level_pwm( >> backlight_pwm_u16_16, backlight_pwm_u16_16); >> >> /* If DMCU is in reset state, DMCU is uninitialized */ >> - if (use_smooth_brightness) >> + if (0 && use_smooth_brightness) >> dmcu_set_backlight_level(abm_dce, >> backlight_pwm_u16_16, >> frame_ramp, >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
