All of lore.kernel.org
 help / color / mirror / Atom feed
* drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
@ 2017-12-18  0:08 Carroll, Lewis
  2017-12-20 23:29 ` Harry Wentland
  0 siblings, 1 reply; 8+ messages in thread
From: Carroll, Lewis @ 2017-12-18  0:08 UTC (permalink / raw)
  To: dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 1134 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 4627 bytes --]

[-- Attachment #2: Linux_4.14_drm_ast_fix_corrupted_gamma.patch --]
[-- Type: application/octet-stream, Size: 3665 bytes --]

From 0a0649f37c5015c0d60aef08e1ac9d496120d8a3 Mon Sep 17 00:00:00 2001
From: Lewis Carroll <lewis.carroll@amd.com>
Date: Sat, 16 Dec 2017 23:47:13 -0500
Subject: [PATCH] drm/ast: Fix corrupted gamma when DPMS enable is not needed
 at driver init

Under a scenario where a connector is already active at driver init, the
driver will not make a DPMS ON call, thus the gamma table is not loaded to
the silicon. This can result in corrupted colors on the display. Add a DPMS
ON call in the commit callback to force this to happen.

Move hard-coded gamma table size to a macro

Non-functional whitespace clean-up
---
 drivers/gpu/drm/ast/ast_mode.c   | 13 +++++--------
 drivers/gpu/drm/ast/ast_tables.h |  2 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 6f3849e..064c619 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -73,7 +73,7 @@ static void ast_crtc_load_lut(struct drm_crtc *crtc)
 	g = r + crtc->gamma_size;
 	b = g + crtc->gamma_size;
 
-	for (i = 0; i < 256; i++)
+	for (i = 0; i < AST_GAMMA_LUT_SIZE; i++)
 		ast_load_palette_index(ast, i, *r++ >> 8, *g++ >> 8, *b++ >> 8);
 }
 
@@ -223,9 +223,8 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, struct drm_display_mo
 	}
 
 	return true;
-
-
 }
+
 static void ast_set_std_reg(struct drm_crtc *crtc, struct drm_display_mode *mode,
 			    struct ast_vbios_mode_info *vbios_mode)
 {
@@ -493,7 +492,6 @@ static void ast_set_start_address_crt1(struct drm_crtc *crtc, unsigned offset)
 	ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x0d, (u8)(addr & 0xff));
 	ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x0c, (u8)((addr >> 8) & 0xff));
 	ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xaf, (u8)((addr >> 16) & 0xff));
-
 }
 
 static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -644,9 +642,9 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
 {
 	struct ast_private *ast = crtc->dev->dev_private;
 	ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0);
+	ast_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
 }
 
-
 static const struct drm_crtc_helper_funcs ast_crtc_helper_funcs = {
 	.dpms = ast_crtc_dpms,
 	.mode_set = ast_crtc_mode_set,
@@ -654,7 +652,6 @@ static const struct drm_crtc_helper_funcs ast_crtc_helper_funcs = {
 	.disable = ast_crtc_disable,
 	.prepare = ast_crtc_prepare,
 	.commit = ast_crtc_commit,
-
 };
 
 static void ast_crtc_reset(struct drm_crtc *crtc)
@@ -696,7 +693,7 @@ static int ast_crtc_init(struct drm_device *dev)
 		return -ENOMEM;
 
 	drm_crtc_init(dev, &crtc->base, &ast_crtc_funcs);
-	drm_mode_crtc_set_gamma_size(&crtc->base, 256);
+	drm_mode_crtc_set_gamma_size(&crtc->base, AST_GAMMA_LUT_SIZE);
 	drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
 	return 0;
 }
@@ -707,7 +704,6 @@ static void ast_encoder_destroy(struct drm_encoder *encoder)
 	kfree(encoder);
 }
 
-
 static struct drm_encoder *ast_best_single_encoder(struct drm_connector *connector)
 {
 	int enc_id = connector->encoder_ids[0];
@@ -731,6 +727,7 @@ static void ast_encoder_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
 {
+
 }
 
 static void ast_encoder_prepare(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h
index 5f4c2e8..6213e89 100644
--- a/drivers/gpu/drm/ast/ast_tables.h
+++ b/drivers/gpu/drm/ast/ast_tables.h
@@ -24,6 +24,8 @@
 #ifndef AST_TABLES_H
 #define AST_TABLES_H
 
+#define AST_GAMMA_LUT_SIZE	256
+
 /* Std. Table Index Definition */
 #define TextModeIndex		0
 #define EGAModeIndex		1
-- 
2.9.3


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-18  0:08 drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed] Carroll, Lewis
@ 2017-12-20 23:29 ` Harry Wentland
  2017-12-21  0:00   ` Carroll, Lewis
  0 siblings, 1 reply; 8+ messages in thread
From: Harry Wentland @ 2017-12-20 23:29 UTC (permalink / raw)
  To: Carroll, Lewis, dri-devel

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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-20 23:29 ` Harry Wentland
@ 2017-12-21  0:00   ` Carroll, Lewis
  2017-12-21 10:06     ` Daniel Vetter
  0 siblings, 1 reply; 8+ messages in thread
From: Carroll, Lewis @ 2017-12-21  0:00 UTC (permalink / raw)
  To: Wentland, Harry, dri-devel

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@amd.com>; dri-devel@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-21  0:00   ` Carroll, Lewis
@ 2017-12-21 10:06     ` Daniel Vetter
  2017-12-21 15:21       ` Carroll, Lewis
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Vetter @ 2017-12-21 10:06 UTC (permalink / raw)
  To: Carroll, Lewis; +Cc: dri-devel

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

> 
> Lewis
> 
> -----Original Message-----
> From: Wentland, Harry 
> Sent: Wednesday, December 20, 2017 6:29 PM
> To: Carroll, Lewis <Lewis.Carroll@amd.com>; dri-devel@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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-21 10:06     ` Daniel Vetter
@ 2017-12-21 15:21       ` Carroll, Lewis
  2017-12-21 20:31         ` Daniel Vetter
  0 siblings, 1 reply; 8+ messages in thread
From: Carroll, Lewis @ 2017-12-21 15:21 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: dri-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-21 15:21       ` Carroll, Lewis
@ 2017-12-21 20:31         ` Daniel Vetter
  2017-12-21 20:58           ` Carroll, Lewis
  2017-12-22 22:37           ` Carroll, Lewis
  0 siblings, 2 replies; 8+ messages in thread
From: Daniel Vetter @ 2017-12-21 20:31 UTC (permalink / raw)
  To: Carroll, Lewis, Michel Dänzer; +Cc: dri-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-21 20:31         ` Daniel Vetter
@ 2017-12-21 20:58           ` Carroll, Lewis
  2017-12-22 22:37           ` Carroll, Lewis
  1 sibling, 0 replies; 8+ messages in thread
From: Carroll, Lewis @ 2017-12-21 20:58 UTC (permalink / raw)
  To: dri-devel; +Cc: Daenzer, Michel

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

> -----Original Message-----
> From: daniel.vetter@ffwll.ch [mailto:daniel.vetter@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Thursday, December 21, 2017 3:31 PM
> To: Carroll, Lewis <Lewis.Carroll@amd.com>; Daenzer, Michel
> <Michel.Daenzer@amd.com>
> Cc: Wentland, Harry <Harry.Wentland@amd.com>; dri-
> devel@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@amd.com>
> wrote:
> >> -----Original Message-----
> >> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> >> Vetter
> >> Sent: Thursday, December 21, 2017 5:07 AM
> >> To: Carroll, Lewis <Lewis.Carroll@amd.com>
> >> Cc: Wentland, Harry <Harry.Wentland@amd.com>; dri-
> >> devel@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

[-- Attachment #2: drm_ast_load_default_gamma_ramp.patch --]
[-- Type: application/octet-stream, Size: 3820 bytes --]

From 084e236e30b9e23fec759d021e804815db5b80d0 Mon Sep 17 00:00:00 2001
From: Lewis Carroll <lewis.carroll@amd.com>
Date: Sat, 16 Dec 2017 23:47:13 -0500
Subject: [PATCH] drm/ast: Load default gamma ramp at driver init

After the fbdev emulation gamma handling rework in drm-next-4.14 merge,
what appeared to be a superfluous call to load_lut was removed. The
AST2500 silicon requires a default gamma ramp to be loaded even if the
visual profile doesn't support or use a gamma clut (e.g. fbdev using
FB_VISUAL_TRUECOLOR). The result is that colors on the display are
corrupted (e.g. blue background, incorrect text colors).

Add back a call to load_lut in the driver init function.

Other non-functional changes in the patch:
 * Move hard-coded gamma table size to a macro
 * Whitespace clean-up
---
 drivers/gpu/drm/ast/ast_mode.c   | 13 +++++--------
 drivers/gpu/drm/ast/ast_tables.h |  2 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 6f3849e..e49f5f4 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -73,7 +73,7 @@ static void ast_crtc_load_lut(struct drm_crtc *crtc)
 	g = r + crtc->gamma_size;
 	b = g + crtc->gamma_size;
 
-	for (i = 0; i < 256; i++)
+	for (i = 0; i < AST_GAMMA_LUT_SIZE; i++)
 		ast_load_palette_index(ast, i, *r++ >> 8, *g++ >> 8, *b++ >> 8);
 }
 
@@ -223,9 +223,8 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, struct drm_display_mo
 	}
 
 	return true;
-
-
 }
+
 static void ast_set_std_reg(struct drm_crtc *crtc, struct drm_display_mode *mode,
 			    struct ast_vbios_mode_info *vbios_mode)
 {
@@ -493,7 +492,6 @@ static void ast_set_start_address_crt1(struct drm_crtc *crtc, unsigned offset)
 	ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x0d, (u8)(addr & 0xff));
 	ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x0c, (u8)((addr >> 8) & 0xff));
 	ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xaf, (u8)((addr >> 16) & 0xff));
-
 }
 
 static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -646,7 +644,6 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
 	ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0);
 }
 
-
 static const struct drm_crtc_helper_funcs ast_crtc_helper_funcs = {
 	.dpms = ast_crtc_dpms,
 	.mode_set = ast_crtc_mode_set,
@@ -654,7 +651,6 @@ static const struct drm_crtc_helper_funcs ast_crtc_helper_funcs = {
 	.disable = ast_crtc_disable,
 	.prepare = ast_crtc_prepare,
 	.commit = ast_crtc_commit,
-
 };
 
 static void ast_crtc_reset(struct drm_crtc *crtc)
@@ -696,7 +692,8 @@ static int ast_crtc_init(struct drm_device *dev)
 		return -ENOMEM;
 
 	drm_crtc_init(dev, &crtc->base, &ast_crtc_funcs);
-	drm_mode_crtc_set_gamma_size(&crtc->base, 256);
+	drm_mode_crtc_set_gamma_size(&crtc->base, AST_GAMMA_LUT_SIZE);
+	ast_crtc_load_lut(&crtc->base);  /* Load default gamma ramp */
 	drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
 	return 0;
 }
@@ -707,7 +704,6 @@ static void ast_encoder_destroy(struct drm_encoder *encoder)
 	kfree(encoder);
 }
 
-
 static struct drm_encoder *ast_best_single_encoder(struct drm_connector *connector)
 {
 	int enc_id = connector->encoder_ids[0];
@@ -731,6 +727,7 @@ static void ast_encoder_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
 {
+
 }
 
 static void ast_encoder_prepare(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h
index 5f4c2e8..6213e89 100644
--- a/drivers/gpu/drm/ast/ast_tables.h
+++ b/drivers/gpu/drm/ast/ast_tables.h
@@ -24,6 +24,8 @@
 #ifndef AST_TABLES_H
 #define AST_TABLES_H
 
+#define AST_GAMMA_LUT_SIZE	256
+
 /* Std. Table Index Definition */
 #define TextModeIndex		0
 #define EGAModeIndex		1
-- 
2.9.3

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
  2017-12-21 20:31         ` Daniel Vetter
  2017-12-21 20:58           ` Carroll, Lewis
@ 2017-12-22 22:37           ` Carroll, Lewis
  1 sibling, 0 replies; 8+ messages in thread
From: Carroll, Lewis @ 2017-12-22 22:37 UTC (permalink / raw)
  To: dri-devel; +Cc: Daenzer, Michel

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@lists.freedesktop.org
> Cc: Wentland, Harry <Harry.Wentland@amd.com>; 'Daniel Vetter'
> <daniel@ffwll.ch>; Daenzer, Michel <Michel.Daenzer@amd.com>
> Subject: RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table
> [patch proposed]
> 
> > -----Original Message-----
> > From: daniel.vetter@ffwll.ch [mailto:daniel.vetter@ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Thursday, December 21, 2017 3:31 PM
> > To: Carroll, Lewis <Lewis.Carroll@amd.com>; Daenzer, Michel
> > <Michel.Daenzer@amd.com>
> > Cc: Wentland, Harry <Harry.Wentland@amd.com>; dri-
> > devel@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@amd.com>
> > wrote:
> > >> -----Original Message-----
> > >> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> > >> Vetter
> > >> Sent: Thursday, December 21, 2017 5:07 AM
> > >> To: Carroll, Lewis <Lewis.Carroll@amd.com>
> > >> Cc: Wentland, Harry <Harry.Wentland@amd.com>; dri-
> > >> devel@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-12-22 22:53 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-18  0:08 drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed] Carroll, Lewis
2017-12-20 23:29 ` Harry Wentland
2017-12-21  0:00   ` Carroll, Lewis
2017-12-21 10:06     ` Daniel Vetter
2017-12-21 15:21       ` Carroll, Lewis
2017-12-21 20:31         ` Daniel Vetter
2017-12-21 20:58           ` Carroll, Lewis
2017-12-22 22:37           ` Carroll, Lewis

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.