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 <harry.wentl...@amd.com>
> Sent: Wednesday, May 20, 2020 6:08 PM
> To: Koo, Anthony <anthony....@amd.com>; Wentland, Harry
> <harry.wentl...@amd.com>; 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>
> 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.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
