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

[Carroll, Lewis]

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

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
>