> -----Original Message----- > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel > Vetter > Sent: Thursday, December 21, 2017 5:07 AM > To: Carroll, Lewis <Lewis.Carroll@xxxxxxx> > Cc: Wentland, Harry <Harry.Wentland@xxxxxxx>; dri- > devel@xxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxx>; dri- > devel@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxx > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
