Hi notaz,
Am 03.05.2016 um 13:13 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 03.05.2016 um 13:08 schrieb Grazvydas Ignotas notasas@gmail.com:
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).
That is what I am currently trying. I already had msleep(1) but it might need even more sleep... Next test will be with msleep(100) after each dcs command.
Well. I have added msleep(100). And removed _nosync from all gen_write and dcs_write commands. Because I assume that it will then sync with something.
Result: no difference. Grey stripes pattern. Except that it takes longer to boot!
So it is not a simple programming speed issue.
And another test I have done:
I have added a NO_SSD config option for the ssd2858.ko which disables all programming of the ssd chip, but still forwards the commands and activities from the panel driver to the OMAP DSI driver. And I have tested with the display board where no ssd2858 is installed and the omap mipi output is directly fed into the panel.
This setup works (unrotated of course).
I.e. all tricks added to make the man-in-the-middle driver work. It is only the ssd2858 which does not behave as instructed.
Some more ideas I have to test: * the reset impulse to the ssd is too short * there is not enough delay between releasing reset and starting programming (this is definitively longer with the mipi-debug+script)
Neither does explain why I don't see a difference in the control registers... Unless some internal modules could have been improperly reset so that they can't handle the register values correctly.
BR, Nikolaus