All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabian Vogt <fabian@ritter-vogt.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Daniel Tang <dt.tangr@gmail.com>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
Date: Sun, 04 Aug 2019 22:13:46 +0200	[thread overview]
Message-ID: <1676212.IEmuWfiXUz@linux-e202.suse.de> (raw)
In-Reply-To: <CACRpkda-5xu2-X5yo=dXchSvuD=ZmZSpTbGNrkv6V+UKs27xWA@mail.gmail.com>

Hi,

Am Samstag, 3. August 2019, 11:51:59 CEST schrieb Linus Walleij:
> On Thu, Jul 25, 2019 at 9:26 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
> 
> > On a real CX the LCD displays shows content without
> > any other changes to the set, but has a ~3Hz pulsating effect scrolling from
> > the top to the bottom and the gray text changes color slightly.
> 
> So you mean something meaningful appears in the LCD
> but there are visual disturbances?
> 
> > Without the patchset applied everything looks perfectly.
> >
> > I tried setting vrefresh to 20, fb_bpp to 16 and forcing an inverted panel
> > clock, but the pulsing didn't change.
> >
> > Using the emulated CX I compared the contents of the registers and found
> > that only the IPC bit (which I tried to set, so that's likely not it) and
> > the interrupt registers have a different content.
> >
> > Any idea?
> 
> I think it's the clock settings in patch 2/3.
> 
> I just set them to "1000" (1MHz since its in kHz) based on some
> educated guesses.
> 
> The old driver set the clock to "1" (kHz) so just try that first,
> maybe it is really that slow.

Did that, it looked rather unhealthy for the LCD. Mostly white with some
glitching except for ~2-3 lines with content scrolling on the screen.

200kHz was still way to slow, so tried the opposite direction.
With a clock of 10MHz the display seems to be working fine and produces a
visibly stable output.

Thanks,
Fabian

> It's just that the old driver also set refres to 60 fps which doesn't
> add up, but I think that setting is simply ignored and that is why
> it works.
>
> Yours,
> Linus Walleij

---
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e5cfe1398a3b..3addcdab8adb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2763,7 +2763,7 @@ static const struct panel_desc arm_rtsm = {
 
 static const struct drm_display_mode nspire_cx_lcd_mode[] = {
 	{
-		.clock = 1000,
+		.clock = 10000,
 		.hdisplay = 320,
 		.hsync_start = 320 + 50,
 		.hsync_end = 320 + 50 + 6,
@@ -2791,7 +2791,7 @@ static const struct panel_desc nspire_cx_lcd_panel = {
 
 static const struct drm_display_mode nspire_classic_lcd_mode[] = {
 	{
-		.clock = 1000,
+		.clock = 10000,
 		.hdisplay = 320,
 		.hsync_start = 320 + 6,
 		.hsync_end = 320 + 6 + 6,




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Fabian Vogt <fabian@ritter-vogt.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Daniel Tang <dt.tangr@gmail.com>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
Date: Sun, 04 Aug 2019 22:13:46 +0200	[thread overview]
Message-ID: <1676212.IEmuWfiXUz@linux-e202.suse.de> (raw)
In-Reply-To: <CACRpkda-5xu2-X5yo=dXchSvuD=ZmZSpTbGNrkv6V+UKs27xWA@mail.gmail.com>

Hi,

Am Samstag, 3. August 2019, 11:51:59 CEST schrieb Linus Walleij:
> On Thu, Jul 25, 2019 at 9:26 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
> 
> > On a real CX the LCD displays shows content without
> > any other changes to the set, but has a ~3Hz pulsating effect scrolling from
> > the top to the bottom and the gray text changes color slightly.
> 
> So you mean something meaningful appears in the LCD
> but there are visual disturbances?
> 
> > Without the patchset applied everything looks perfectly.
> >
> > I tried setting vrefresh to 20, fb_bpp to 16 and forcing an inverted panel
> > clock, but the pulsing didn't change.
> >
> > Using the emulated CX I compared the contents of the registers and found
> > that only the IPC bit (which I tried to set, so that's likely not it) and
> > the interrupt registers have a different content.
> >
> > Any idea?
> 
> I think it's the clock settings in patch 2/3.
> 
> I just set them to "1000" (1MHz since its in kHz) based on some
> educated guesses.
> 
> The old driver set the clock to "1" (kHz) so just try that first,
> maybe it is really that slow.

Did that, it looked rather unhealthy for the LCD. Mostly white with some
glitching except for ~2-3 lines with content scrolling on the screen.

200kHz was still way to slow, so tried the opposite direction.
With a clock of 10MHz the display seems to be working fine and produces a
visibly stable output.

Thanks,
Fabian

> It's just that the old driver also set refres to 60 fps which doesn't
> add up, but I think that setting is simply ignored and that is why
> it works.
>
> Yours,
> Linus Walleij

---
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e5cfe1398a3b..3addcdab8adb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2763,7 +2763,7 @@ static const struct panel_desc arm_rtsm = {
 
 static const struct drm_display_mode nspire_cx_lcd_mode[] = {
 	{
-		.clock = 1000,
+		.clock = 10000,
 		.hdisplay = 320,
 		.hsync_start = 320 + 50,
 		.hsync_end = 320 + 50 + 6,
@@ -2791,7 +2791,7 @@ static const struct panel_desc nspire_cx_lcd_panel = {
 
 static const struct drm_display_mode nspire_classic_lcd_mode[] = {
 	{
-		.clock = 1000,
+		.clock = 10000,
 		.hdisplay = 320,
 		.hsync_start = 320 + 6,
 		.hsync_end = 320 + 6 + 6,

  reply	other threads:[~2019-08-04 20:14 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23 13:37 [PATCH 0/3] RFT: PL111 DRM conversion of nspire Linus Walleij
2019-07-23 13:37 ` Linus Walleij
2019-07-23 13:37 ` [PATCH 1/3] RFT: drm/pl111: Support grayscale Linus Walleij
2019-07-23 13:37   ` Linus Walleij
2019-07-23 15:19   ` Fabian Vogt
2019-07-23 15:19     ` Fabian Vogt
2019-07-24 12:33     ` Linus Walleij
2019-07-24 12:33       ` Linus Walleij
2019-07-25 19:26       ` Fabian Vogt
2019-07-25 19:26         ` Fabian Vogt
2019-08-03  9:51         ` Linus Walleij
2019-08-03  9:51           ` Linus Walleij
2019-08-04 20:13           ` Fabian Vogt [this message]
2019-08-04 20:13             ` Fabian Vogt
2019-07-23 16:22   ` [1/3] " David Lechner
2019-07-23 16:22     ` David Lechner
2019-07-23 17:25   ` [PATCH 1/3] " Adam Jackson
2019-07-23 17:25     ` Adam Jackson
2019-07-23 21:06     ` Daniel Vetter
2019-07-23 21:06       ` Daniel Vetter
2019-07-24 12:52       ` Linus Walleij
2019-07-24 12:52         ` Linus Walleij
2019-07-24 14:06         ` Daniel Vetter
2019-07-24 14:06           ` Daniel Vetter
2019-07-23 13:37 ` [PATCH 2/3] RTF: drm/panel: simple: Add TI nspire panels Linus Walleij
2019-07-23 13:37   ` Linus Walleij
2019-07-23 17:54   ` Sam Ravnborg
2019-07-23 17:54     ` Sam Ravnborg
2019-07-24 13:58     ` Linus Walleij
2019-07-24 13:58       ` Linus Walleij
2019-07-24 18:53       ` Sam Ravnborg
2019-07-24 18:53         ` Sam Ravnborg
2019-07-23 13:37 ` [PATCH 3/3] RFT: ARM: nspire: Move CLCD set-up to device tree Linus Walleij
2019-07-23 13:37   ` Linus Walleij
2019-07-23 18:10 ` [PATCH 0/3] RFT: PL111 DRM conversion of nspire Sam Ravnborg
2019-07-23 18:10   ` Sam Ravnborg
2019-07-24 12:28   ` Linus Walleij
2019-07-24 12:28     ` Linus Walleij
2019-07-24 12:47     ` Pawel Moll
2019-07-24 12:47       ` Pawel Moll
2019-07-24 12:53       ` Linus Walleij
2019-07-24 12:53         ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1676212.IEmuWfiXUz@linux-e202.suse.de \
    --to=fabian@ritter-vogt.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dt.tangr@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.