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 <amonakov@xxxxxxxxx> 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 <Harry.Wentland@xxxxxxx>
> > > Sent: Wednesday, May 20, 2020 6:08 PM
> > > To: Koo, Anthony <Anthony.Koo@xxxxxxx>; Wentland, Harry <Harry.Wentland@xxxxxxx>; Alex Deucher <alexdeucher@xxxxxxxxx>; Alexander Monakov <amonakov@xxxxxxxxx>; Kazlauskas, Nicholas <Nicholas.Kazlauskas@xxxxxxx>; Li, Sun peng (Leo) <Sunpeng.Li@xxxxxxx>
> > > Cc: amd-gfx list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>; Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Chiu, Michael <Michael.Chiu@xxxxxxx>
> > > 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 <Harry.Wentland@xxxxxxx>
> > > > Sent: Wednesday, May 20, 2020 5:53 PM
> > > > To: Alex Deucher <alexdeucher@xxxxxxxxx>; Alexander Monakov
> > > > <amonakov@xxxxxxxxx>; Kazlauskas, Nicholas
> > > > <Nicholas.Kazlauskas@xxxxxxx>; Li, Sun peng (Leo) <Sunpeng.Li@xxxxxxx>
> > > > Cc: amd-gfx list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>; Deucher, Alexander
> > > > <Alexander.Deucher@xxxxxxx>; Chiu, Michael <Michael.Chiu@xxxxxxx>;
> > > > Koo, Anthony <Anthony.Koo@xxxxxxx>
> > > > 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 <amonakov@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> > > >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > >
>
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
