drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]

[Daniel Vetter]

Fyi Michel, we've discussed similar issues for radeon/amdgpu on irc.

On Thu, Dec 21, 2017 at 4:21 PM, Carroll, Lewis <Lewis.Carroll at amd.com> wrote:
>> -----Original Message-----
>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Thursday, December 21, 2017 5:07 AM
>> To: Carroll, Lewis <Lewis.Carroll at amd.com>
>> Cc: Wentland, Harry <Harry.Wentland at amd.com>; dri-
>> devel at lists.freedesktop.org
>> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table
>> [patch proposed]
>>
>> On Thu, Dec 21, 2017 at 12:00:39AM +0000, Carroll, Lewis wrote:
>> > The discussion sounds similar as well - related to load_lut() not being called.
>> >
>> > Perhaps after the drm-next-4.14 merge, whatever call stack used to cause
>> > load_lut to always get called is now gone. Even if FB_VISUAL_TRUECOLOR
>> > doesn't support a clut, some hardware may still need a default gamma lut
>> > loaded (appears to be the case with the AST2500). Perhaps checking for
>> > that profile and loading the default LUT prepared by
>> > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...?
>>
>> Yeah drivers should load that somehow. Unfortunately I'm going on
>> vacations now, so I'm not going to fix anything anytime soon. Might be
>> good to ping Peter Rosin, he did all the fbdev emulation gamma handling
>> rework (which is the patch that removed the superflously-looking call to
>> ->load_lut that some drivers relied on to have a consistent lut state).
>> -Daniel
>
> Enjoy the holidays.
>
> Wonder if it would be better to just call load_lut after
> drm_mode_crtc_set_gamma_size instead of adding a potentially
> unnecessary DPMS ON event to the commit call-back as I did...? Or call
> load_lut in the commit callback instead of the DPMS ON call...?
>
> The first approach (calling load_lut after set_gamma_size) also works on
> two test systems.

Yeah, I think that's the cleanest approach. The underlying issue is
that a bunch of drivers are not making sure that on driver-load they
have a consistent sw/hw state for the gamma ramp. As long as you had
fbcon enabled the strange ->load_lut call (which isn't really
necessary for drivers that got this right) papered over these issues.

So a call to you driver's load_lut right affter
drm_mode_crtc_set_gamma_size should fix this correctly. a-b:me if you
submit that patch.

/me off for real now

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch