Hi,

On Tue, May 3, 2016 at 1:22 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:

I don't exactly know which registers DISPC_OVL_BA0 are and what they do but, I have digged through
the source code and found out that the reason is a different framebuffer base address

It's the RAM address from where to fetch the image. the memory is dynamically allocated on every boot, so it's normal for address to change on each boot.
 
in omap_plane_atomic_update().
So it is just a side-effect of loading the driver in a different sequence compared to others. And should not be
the reason for our symptoms.

The symptoms are:
* with mipi-debug driver and ssd2858 script it works in normal or rotation mode (this is how ED presents the Pyra to the public)
* it does not work (although it did last week) in ssd test pattern output mode.
* with ssd2858.ko it shows a b/w striped pattern (which does not depend on video input) - but the pattern rotates if the ssd2858 is instructed to do so

As we know the SSD is very picky and requires programming sequence to be perfect or it just won't work.

It might be register programming order, especially DCS commands, you could try making a trace log of each register and DCS write and see if the order matches the script.

Could also easily be a timing issue. With mipi-debug you get huge delays between every register write because the system has to switch between userspace/kernelspace on each register write, while the driver does it all a lot faster. You can add some usleeps() everywhere as a test and maybe isolate later where the delay is really needed (assuming that's the problem at all).

Gražvydas