Re: Flaky brightness on Renoir
Hi,
it looks like part of the problem is that dmcu_load_iram is never called on
Renoir, and yet is_dmcu_initialized returns true. Would you agree?
Is something necessary to address that TODO still missing? It's from February
of last year.
Alexander
On Wed, 27 May 2020, Alex Deucher wrote:
> On Wed, May 27, 2020 at 6:30 PM Alexander Monakov wrote:
> >
> > Hey,
> >
> > note that the driver does not call dmcu_load_iram on Renoir, as
> > dm_late_init has
> >
> > /* todo will enable for navi10 */
> > if (adev->asic_type <= CHIP_RAVEN) {
> > ret = dmcu_load_iram(dmcu, params);
> >
> > and there's no other callsite for dmcu_load_iram.
> >
> > Why is it necessary anyway? The driver seems to have perfectly working
> > direct
> > programming for PWM registers, so why the extra complications with
> > brightness
> > control via a microcontroller middleman?
>
> The display guys can correct me if I'm wrong, but I believe it's
> mainly for power savings. I.e., the microcontroller can dynamically
> adjust the backlight levels and gamma to save power while still having
> the same apparent brightness.
>
> Alex
>
> >
> > Thanks.
> > Alexander
> >
> > On Wed, 20 May 2020, Koo, Anthony wrote:
> >
> > > [AMD Official Use Only - Internal Distribution Only]
> > >
> > > It's touching around that area, but just the endian-ness change itself
> > > would not cause the boot-to-boot variation observed here. But it could
> > > cause broken backlight behavior.
> > >
> > > I also don't know what driver is being tested, so I don't know other
> > > details like whether we are using DMUB on this system.
> > > But in general, I would try to check out whether those parameters look
> > > like they are loaded correctly.
> > >
> > > Thanks,
> > > Anthony
> > >
> > > -Original Message-----
> > > From: Wentland, Harry
> > > Sent: Wednesday, May 20, 2020 6:08 PM
> > > To: Koo, Anthony ; Wentland, Harry
> > > ; Alex Deucher ; Alexander
> > > Monakov ; Kazlauskas, Nicholas
> > > ; Li, Sun peng (Leo)
> > > Cc: amd-gfx list ; Deucher, Alexander
> > > ; Chiu, Michael
> > > Subject: Re: Flaky brightness on Renoir
> > >
> > > On 2020-05-20 6:03 p.m., Koo, Anthony wrote:
> > > > [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.
> > >
> > > Do you think this could be related to Wyatt's endian-ness fixes?
> > >
> > > Harry
> > >
> > > > 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
> > > > Sent: Wednesday, May 20, 2020 5:53 PM
> > > > To: Alex Deucher ; Alexander Monakov
> > > > ; Kazlauskas, Nicholas
> > > > ; Li, Sun peng (Leo)
> > > > Cc: amd-gfx list ; Deucher, Alexander
> > > > ; Chiu, Michael ;
> > > > Koo, Anthony
> > > > 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
> > > >
&g
Re: Flaky brightness on Renoir
On Wed, May 27, 2020 at 6:30 PM Alexander Monakov wrote:
>
> Hey,
>
> note that the driver does not call dmcu_load_iram on Renoir, as dm_late_init
> has
>
> /* todo will enable for navi10 */
> if (adev->asic_type <= CHIP_RAVEN) {
> ret = dmcu_load_iram(dmcu, params);
>
> and there's no other callsite for dmcu_load_iram.
>
> Why is it necessary anyway? The driver seems to have perfectly working direct
> programming for PWM registers, so why the extra complications with brightness
> control via a microcontroller middleman?
The display guys can correct me if I'm wrong, but I believe it's
mainly for power savings. I.e., the microcontroller can dynamically
adjust the backlight levels and gamma to save power while still having
the same apparent brightness.
Alex
>
> Thanks.
> Alexander
>
> On Wed, 20 May 2020, Koo, Anthony wrote:
>
> > [AMD Official Use Only - Internal Distribution Only]
> >
> > It's touching around that area, but just the endian-ness change itself
> > would not cause the boot-to-boot variation observed here. But it could
> > cause broken backlight behavior.
> >
> > I also don't know what driver is being tested, so I don't know other
> > details like whether we are using DMUB on this system.
> > But in general, I would try to check out whether those parameters look like
> > they are loaded correctly.
> >
> > Thanks,
> > Anthony
> >
> > -Original Message-
> > From: Wentland, Harry
> > Sent: Wednesday, May 20, 2020 6:08 PM
> > To: Koo, Anthony ; Wentland, Harry
> > ; Alex Deucher ; Alexander
> > Monakov ; Kazlauskas, Nicholas
> > ; Li, Sun peng (Leo)
> > Cc: amd-gfx list ; Deucher, Alexander
> > ; Chiu, Michael
> > Subject: Re: Flaky brightness on Renoir
> >
> > On 2020-05-20 6:03 p.m., Koo, Anthony wrote:
> > > [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.
> >
> > Do you think this could be related to Wyatt's endian-ness fixes?
> >
> > Harry
> >
> > > 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
> > > Sent: Wednesday, May 20, 2020 5:53 PM
> > > To: Alex Deucher ; Alexander Monakov
> > > ; Kazlauskas, Nicholas
> > > ; Li, Sun peng (Leo)
> > > Cc: amd-gfx list ; Deucher, Alexander
> > > ; Chiu, Michael ;
> > > Koo, Anthony
> > > 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
> > >> 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
> > >&g
RE: Flaky brightness on Renoir
Hey,
note that the driver does not call dmcu_load_iram on Renoir, as dm_late_init has
/* todo will enable for navi10 */
if (adev->asic_type <= CHIP_RAVEN) {
ret = dmcu_load_iram(dmcu, params);
and there's no other callsite for dmcu_load_iram.
Why is it necessary anyway? The driver seems to have perfectly working direct
programming for PWM registers, so why the extra complications with brightness
control via a microcontroller middleman?
Thanks.
Alexander
On Wed, 20 May 2020, Koo, Anthony wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> It's touching around that area, but just the endian-ness change itself would
> not cause the boot-to-boot variation observed here. But it could cause broken
> backlight behavior.
>
> I also don't know what driver is being tested, so I don't know other details
> like whether we are using DMUB on this system.
> But in general, I would try to check out whether those parameters look like
> they are loaded correctly.
>
> Thanks,
> Anthony
>
> -Original Message-
> From: Wentland, Harry
> Sent: Wednesday, May 20, 2020 6:08 PM
> To: Koo, Anthony ; Wentland, Harry
> ; Alex Deucher ; Alexander
> Monakov ; Kazlauskas, Nicholas
> ; Li, Sun peng (Leo)
> Cc: amd-gfx list ; Deucher, Alexander
> ; Chiu, Michael
> Subject: Re: Flaky brightness on Renoir
>
> On 2020-05-20 6:03 p.m., Koo, Anthony wrote:
> > [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.
>
> Do you think this could be related to Wyatt's endian-ness fixes?
>
> Harry
>
> > 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
> > Sent: Wednesday, May 20, 2020 5:53 PM
> > To: Alex Deucher ; Alexander Monakov
> > ; Kazlauskas, Nicholas
> > ; Li, Sun peng (Leo)
> > Cc: amd-gfx list ; Deucher, Alexander
> > ; Chiu, Michael ;
> > Koo, Anthony
> > 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
> >> 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
> >&
RE: Flaky brightness on Renoir
[AMD Official Use Only - Internal Distribution Only] Hi Harry, " Michael, does this "fix" your issue?" Yes, the change "fixes" the issue. It has the same effect as removing renoir_dmcu.bin work-around, where backlight control starts to work. Thanks again, Michael -Original Message- From: Wentland, Harry Sent: Wednesday, May 20, 2020 5:53 PM To: Alex Deucher ; Alexander Monakov ; Kazlauskas, Nicholas ; Li, Sun peng (Leo) Cc: amd-gfx list ; Deucher, Alexander ; Chiu, Michael ; Koo, Anthony 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 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
RE: Flaky brightness on Renoir
[AMD Official Use Only - Internal Distribution Only] It's touching around that area, but just the endian-ness change itself would not cause the boot-to-boot variation observed here. But it could cause broken backlight behavior. I also don't know what driver is being tested, so I don't know other details like whether we are using DMUB on this system. But in general, I would try to check out whether those parameters look like they are loaded correctly. Thanks, Anthony -Original Message- From: Wentland, Harry Sent: Wednesday, May 20, 2020 6:08 PM To: Koo, Anthony ; Wentland, Harry ; Alex Deucher ; Alexander Monakov ; Kazlauskas, Nicholas ; Li, Sun peng (Leo) Cc: amd-gfx list ; Deucher, Alexander ; Chiu, Michael Subject: Re: Flaky brightness on Renoir On 2020-05-20 6:03 p.m., Koo, Anthony wrote: > [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. Do you think this could be related to Wyatt's endian-ness fixes? Harry > 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 > Sent: Wednesday, May 20, 2020 5:53 PM > To: Alex Deucher ; Alexander Monakov > ; Kazlauskas, Nicholas > ; Li, Sun peng (Leo) > Cc: amd-gfx list ; Deucher, Alexander > ; Chiu, Michael ; > Koo, Anthony > 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 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
Re: Flaky brightness on Renoir
On 2020-05-20 6:03 p.m., Koo, Anthony wrote: > [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. Do you think this could be related to Wyatt's endian-ness fixes? Harry > 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 > Sent: Wednesday, May 20, 2020 5:53 PM > To: Alex Deucher ; Alexander Monakov > ; Kazlauskas, Nicholas ; Li, > Sun peng (Leo) > Cc: amd-gfx list ; Deucher, Alexander > ; Chiu, Michael ; Koo, > Anthony > 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 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
RE: Flaky brightness on Renoir
[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 Sent: Wednesday, May 20, 2020 5:53 PM To: Alex Deucher ; Alexander Monakov ; Kazlauskas, Nicholas ; Li, Sun peng (Leo) Cc: amd-gfx list ; Deucher, Alexander ; Chiu, Michael ; Koo, Anthony 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 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
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 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
Re: Flaky brightness on Renoir
Adding some display people. On Wed, May 20, 2020 at 5:46 PM Alexander Monakov 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
