Hi Tomi, Rajendra and other,
I have run into a rather strange regression with the LCD panel display on my
GTA04 (OMAP3630 based phone) that you might be able to help me with.
I bisected down to two patches, neither of which cause the problem by
themselves, but both together do.
They are:
commit bd0f5cc3641cb76ae8fa2cc4924c29da157f8b2d
Author: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
Date: Thu Dec 13 14:21:30 2012 +0200
OMAPDSS: fix TV-out issue with DSI PLL
and
commit f7f73aab3d5bd19ba0f72ff00fb6b3be28e1a4d3
Author: Rajendra Nayak <rnayak@xxxxxx>
Date: Fri Apr 27 16:27:51 2012 +0530
ARM: OMAP: clock: Switch to COMMON clk
Yes - rather odd.
The details:
I'm currently trying to move from a 3.7 kernel on my GTA04 to a 3.10-rc
kernel (hopefully to have 3.10 fully working by the time it comes out..).
Once I got it compiling and booting I found that while the display worked
perfectly at boot, after it has been turned off (ioctl(FBIOBLANK)) and back
on again, it is all white - no discernible image at all.
A suspend/resume cycle at this point might bring it back, but it is often
shimmery (low vsync?) and once it had inverse colours.
I had noticed that the panel which normally gets a 22153 kHz pixel clock was
only getting a 21600 kHz clock. This turned out to be due to the fact
that dpi_calc_dispc_cb rejects odd divisors, and it used to use a divisor of
'3'.
I disabled that code and then the screen would wake successfully resume from
blank, but there was a strange artefact in the image. My display has a grey
background with some blue text. On the lines that have text, the grey
background had a very slight green tinge, especially when viewed at the
right angle.
I decided to try bisecting to find the cause of this, because I couldn't
even begin to guess what it might be. I found:
commit 2b8318881ddbcb67c5e8d2178b42284749442222
Merge: e81d372 e7f5c9a
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Sat Dec 15 13:03:48 2012 -0800
Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux
Pull fbdev changes from Tomi Valkeinen:
"OMAPDSS changes, including:
yes - a merge commit. Neither branch by itself caused the problem but the two
together do.
I then decided "in for a penny, in for a pound" and proceeded to bisect both
branches, merging in the other one at each test point.
This lead me to the two commits listed above.
bd0f5cc3641cb76 merged with e81d372 has the problem,
bd0f5cc3641cb76~1 merged with e81d372 is fine.
Similarly
f7f73aab3d5bd19b merged with e7f5c9a has the problem, while
f7f73aab3d5bd19b~1 merged with e7f5c9a is fine.
I tried reverting the "OMAPDSS: fix TV-out issue with DSI PLL" patch from
3.10-rc as below, and it seems to behave better, returning from blank
properly. This is without disabling the "no odd divisors" code.
I'm not really sure how it survives suspend, as suspend generally isn't
reliable for me on 3.10-rc yet - haven't look into why as yet.
Any help anyone could provide here would be greatly appreciated. I'm happy
to run any test patches you would like to suggest.
Thanks,
NeilBrown
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 757b57f..4d4f775 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -62,7 +62,7 @@ static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
- return NULL;
+// return NULL;
case OMAPDSS_VER_OMAP4430_ES1:
case OMAPDSS_VER_OMAP4430_ES2:
Attachment:
signature.asc
Description: PGP signature
