Re: Strange OMAP3 LCD display regression - bisected.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 3 Jun 2013 10:24:18 +0300 Tomi Valkeinen <tomi.valkeinen@xxxxxx>
wrote:

> Hi,
> 
> On 02/06/13 09:50, NeilBrown wrote:
> 
> > 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..).
> 
> I presume the panel driver is not in the mainline? Is there anything
> special with the panel, or is it just a "dummy" DPI panel that doesn't
> need any kind of configuration?

Not in mainline.  If you are interested it is here:

http://git.neil.brown.name/?p=gta04.git;a=blob;f=drivers/video/omap2/displays/panel-tpo-td028ttec1.c;h=c127e47b88ff2822fc0f168ed6706e16d6115abf;hb=69c0e01e14bd9651a1768f8108d21d39334e724b

Needs lots of cleanup.  Pokes at a bunch of SPI registers which I might have
documentation for somewhere but haven't had time to look at it yet.


> 
> >  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.
> 
> I'll try blanking on my omap3 board with 3.10-rc (I think I haven't
> tried it). Did you check if the DSS hardware lost context (visible from
> the PM counters)?

I turned on some debugging statements and the mentioned lost-context counters
in a way that suggested they were being handled correctly (save and restore
reported appropriately matching numbers).

> 
> >  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'.
> 
> Normally panels should not be that picky. In my experience the pixel
> clock has to be very far from the nominal, until the panel start to fail.

As I said, it works fine at first boot.  So the panel obviously copes.  But
something weird happens at blank/unblack which is affect by the pixel clock
setting in a non-obvious way.

> 
> However, the code in dpi_calc_dispc_cb only rejects odd divisors, if the
> pixel clock is greater than 100MHz. So I don't understand how you're
> seeing it affect here. Are you sure the pclk is ~22MHz?

If think you got some maths wrong.
dpi_calc_dispc_cb() contains:
	if (ctx->pck_min >= 1000000) {

which isn't 100MHz, unless the units are 0.1KHz, which seems unlikely.
It looks to me like the units for pck_min is Hz, so the cut off is 1MHz.
So that should be:
	if (ctx->pck_min >= 100000000) {
??

> 
> >  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.
> 
> Odd, indeed. Without reverting the patch, the DSS uses a clock from the
> PRCM as func clock and for pixel clock. As the common clock framework is
> somehow involved in the breakage, maybe (pure guess) something related
> to the PRCM clock is configured wrong.
> 
> And with reverting the above patch, DSS uses DSI PLL for fclk and pclk,
> and DSI PLL in turn only needs sysclk, so maybe the possible problem
> with PRCM doesn't affect this case.
> 

I'll try the patch that Paul and Jean-Philippe suggested and report the
results.

Thanks

NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux