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

[Carroll, Lewis]

> -----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.

> 
> >
> > Lewis
> >
> > -----Original Message-----
> > From: Wentland, Harry
> > Sent: Wednesday, December 20, 2017 6:29 PM
> > To: Carroll, Lewis <Lewis.Carroll 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]
> >
> > This looks similar to this bug that I spotted while finally going through my
> large dri-devel backlog: https://bugzilla.kernel.org/show_bug.cgi?id=198123
> >
> > The discussion continues here https://lists.freedesktop.org/archives/dri-
> devel/2017-December/160667.html
> >
> > Not sure if this is related but the symptoms sound quite similar.
> >
> > Harry
> >
> > On 2017-12-17 07:08 PM, Carroll, Lewis wrote:
> > > Happy Holidays.
> > >
> > >
> > >
> > > Test-driving Linux 4.14 from the Ubuntu Bionic repo on an AMD EPYC
> server using the A-Speed AST2500 BMC and the AST DRM driver and
> framebuffer console configured into the kernel, I have observed multiple
> systems where the analog VGA color palette for the framebuffer console is
> incorrect. Background is blue and all text colors other than white / gray are
> incorrect.
> > >
> > >
> > >
> > > Instrumenting the AST DRM driver, it seems the default gamma table isn't
> loaded to the silicon until there is a DPMS action. When there is a DPMS
> action other than DPMS OFF, the gamma table is loaded and all is well. On
> these boards, the kernel is not calling for a DPMS event at driver init so the
> gamma table is not loaded.
> > >
> > >
> > >
> > > The attached proposed patch adds a DPMS ON event to the commit
> callback after a kernel modeset call. This solves the problem, however there
> may be a better / more proper way to solve this.
> > >
> > >
> > >
> > > Assuming no one on the mailing list has hardware on which to verify this, I
> am happy to be a test driver for any suggested fixes.
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > >
> > > Lewis Carroll
> > >
> > > Principal Solutions Architect
> > >
> > > AMD Enterprise Business Group
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch