On Mon, 3 Jun 2013 10:24:18 +0300 Tomi Valkeinen <tomi.valkei...@ti.com> 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
signature.asc
Description: PGP signature
