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

[Carroll, Lewis]

Spoke too soon. Original patch worked better (adding call to DPMS ON event
in commit call-back. Disregard the latest I sent. Apologies.

> -----Original Message-----
> From: Carroll, Lewis
> Sent: Thursday, December 21, 2017 3:58 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Wentland, Harry <Harry.Wentland at amd.com>; 'Daniel Vetter'
> <daniel at ffwll.ch>; Daenzer, Michel <Michel.Daenzer at amd.com>
> Subject: RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table
> [patch proposed]
> 
> > -----Original Message-----
> > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Thursday, December 21, 2017 3:31 PM
> > To: Carroll, Lewis <Lewis.Carroll at amd.com>; Daenzer, Michel
> > <Michel.Daenzer 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]
> >
> > 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.
> 
> Reworked patch attached, commit message changed to summarize the
> Above discussion.
> 
> >
> > /me off for real now
> >
> > Cheers, Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch