Strange OMAP3 LCD display regression - bisected.

[NeilBrown <neilb@suse.de>]

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


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@ti.com>
Date:   Thu Dec 13 14:21:30 2012 +0200

    OMAPDSS: fix TV-out issue with DSI PLL

and 

commit f7f73aab3d5bd19ba0f72ff00fb6b3be28e1a4d3
Author: Rajendra Nayak <rnayak@ti.com>
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@linux-foundation.org>
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]