Ok, latest news after peeking and poking into Linux, I have fixed the SYNC_LOST issue:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=commit;h=b...
That was quite complex. The problem is that the only controls we have are struct omap_video_timings and omap_dss_dsi_videomode_timings which can be set in the driver. From these, the guts of Linux calculate some register settings for the OMAP5. Depending on their correctness, the DSI stays in sync or does not.
Now, there is no simple formula that tells what to specify in the driver for those structs to get some expected output. Rather I can only find out fro the register settings what the OMAP5 is doing. And then modify the controls to set other register values.
The required information to understand that is unfortunately spread over several documents and locations: * OMAP TRM * Linux kernel source * Driver source * some special Spread Sheet by TI to visualize what the OMAP is doing - if you know the register values * Linux kernel log * cat /sys/kernel/debug/omapdss/clk * cat /sys/kernel/debug/omapdss/dsi1_regs
What increases the complexity is that the same divider value or clock signal has at least 3 different names in these information sources. And if I e.g. look into the dsi1_regs I have to find and analyse the hex code as a bit pattern in the TRM to see what it is doing.
But finally I found out: * DSI needs its own view on the hsync and vsync pulses vs. front/back porch (Austastlücke) - and that must be fully synchronized with the DISPC * so it is not sufficient to define that like for a RGB panel just for the DISPC * there are rounding effects to consider * not all combinations of values are possible - this may e.g. be the reason why I always did get 450 MHz yesterday
Well, the author of the Linux DSS API could have made life much easier for us if we would not even have to specify a pixel clock but only the horizontal and vertical size + pulses and a frame rate. Everything else should be possible to be calculated in the kernel - if I can do it manually by using this spreadsheet. So Linux seems to provide a half-hearted solution. At least the 3.8 DSS. I know that there is a complete rewrite in 3.14 - but that is still -rc1. [Sidenote: I don't know if such a DSS framework exists for the Z3770 Atom at all - ok, looks as if there is work in progress: http://www.spinics.net/lists/intel-gfx/msg37329.html].
But after digging through that mess back and forth I finally found a combination that appears to work. At least there are no more DSI PLL and SYNC errors. Meaning we should see a steady data stream on the MIPI port.
Next step will be to debug if I can really see these signals with the scope and to check if the reset impulse is applied correctly. And if the data lanes have correct polarity.
So it turns out that the step-by-step approach to remove road blocks is better than trying everything in one big bang :)
Well, this is something where TI *could* have helped - but either slower (because if I post a question it may take a while until they answer) or I would have had to understand it anyways what they are talking about.
But Panel still remains black. So let's address the next road-block :)
BR, Nikolaus