Re: Strange OMAP3 LCD display regression - bisected.

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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

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?

>  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)?

>  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.

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?

>  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.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]