Hi, here are the latest MIPI signals.
This time from the lg4591 driver to avoid problems introduced by our driver (our signals look almost the same).
The yellow one is a clock lane and the blue one is a data lane.
We see the switch from high-speed (video) to low power (data only) mode.
Almost everything is ok: - data is jumping on low delta levels in high speed mode until it ends and switches to high voltage. - the blue line is 0V before some bit modulation occurs is likely because we have an almost a black line - this means that we only see the error correction code at the end of a line. - and the clock does essentially the same - but turns off later (as expected). - but what is missing is any comparable activity on the clock during high speed mode (left half of the screen). Rather it looks as if it is constantly on 50% of the expected level (as defined by the data lane).
The last test I have done so far is to swap the lanes by changing our board file. Then, the yellow and blue signals swap their role but the situation remains exactly the same!
So this is the proof that the missing clock is something coming from *inside* the OMAP5. And is not something by a potentially broken OMAP5 output driver or problem on our interface hardware.
What I could imagine is that there is indeed something missing or wrong in the DSI programming by the Linux driver. I have read again through the DSI programming chapters of the TRM and there appears to be some "divide by two mode" where I interpret a comment as if that one is not available in the OMAP4. So it *might* be required to use that mode on the OMAP5 for such high resolution displays - and the DSS driver could be not aware of it.
So it could be that the OMAP5 is trying to output 864 MHz which is beyond the spec of the output driver. And therefore it outputs the 50% level instead of oscillating from 0% to 100% and back.
But so far this is just a vague hypothesis.
BR, Nikolaus
Am 24.02.2014 um 16:50 schrieb Dr. H. Nikolaus Schaller:
Hi, here are the latest MIPI signals.
This time from the lg4591 driver to avoid problems introduced by our driver (our signals look almost the same).
The yellow one is a clock lane and the blue one is a data lane.
We see the switch from high-speed (video) to low power (data only) mode.
Almost everything is ok:
- data is jumping on low delta levels in high speed mode until it ends and switches to high voltage.
- the blue line is 0V before some bit modulation occurs is likely because we have an almost a black line
- this means that we only see the error correction code at the end of a line.
- and the clock does essentially the same - but turns off later (as expected).
- but what is missing is any comparable activity on the clock during high speed mode (left half of the screen). Rather it looks as if it is constantly on 50% of the expected level (as defined by the data lane).
The last test I have done so far is to swap the lanes by changing our board file. Then, the yellow and blue signals swap their role but the situation remains exactly the same!
So this is the proof that the missing clock is something coming from *inside* the OMAP5. And is not something by a potentially broken OMAP5 output driver or problem on our interface hardware.
What I could imagine is that there is indeed something missing or wrong in the DSI programming by the Linux driver. I have read again through the DSI programming chapters of the TRM and there appears to be some "divide by two mode" where I interpret a comment as if that one is not available in the OMAP4. So it *might* be required to use that mode on the OMAP5 for such high resolution displays - and the DSS driver could be not aware of it.
So it could be that the OMAP5 is trying to output 864 MHz which is beyond the spec of the output driver. And therefore it outputs the 50% level instead of oscillating from 0% to 100% and back.
But so far this is just a vague hypothesis.
I just had an idea how to test this hypothesis:
I can reduce the pixel and DSI clock frequencies defined by the driver by the factor 2 or 4 or 8 and then I should see something if the clocks are simply too fast.
Planned for Wednesday...
BR, Nikolaus
Am Tue, 25 Feb 2014 07:09:55 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Found this one: http://e2e.ti.com/support/omap/f/885/t/307996.aspx
Looks we're not the only ones with the issue... and it seems OMAP4 and 5 ARE different!
Am 24.02.2014 um 16:50 schrieb Dr. H. Nikolaus Schaller:
Hi, here are the latest MIPI signals.
This time from the lg4591 driver to avoid problems introduced by our driver (our signals look almost the same).
The yellow one is a clock lane and the blue one is a data lane.
We see the switch from high-speed (video) to low power (data only) mode.
Almost everything is ok:
- data is jumping on low delta levels in high speed mode until it
ends and switches to high voltage.
- the blue line is 0V before some bit modulation occurs is likely
because we have an almost a black line
- this means that we only see the error correction code at the end
of a line.
- and the clock does essentially the same - but turns off later (as
expected).
- but what is missing is any comparable activity on the clock
during high speed mode (left half of the screen). Rather it looks as if it is constantly on 50% of the expected level (as defined by the data lane).
The last test I have done so far is to swap the lanes by changing our board file. Then, the yellow and blue signals swap their role but the situation remains exactly the same!
So this is the proof that the missing clock is something coming from *inside* the OMAP5. And is not something by a potentially broken OMAP5 output driver or problem on our interface hardware.
What I could imagine is that there is indeed something missing or wrong in the DSI programming by the Linux driver. I have read again through the DSI programming chapters of the TRM and there appears to be some "divide by two mode" where I interpret a comment as if that one is not available in the OMAP4. So it *might* be required to use that mode on the OMAP5 for such high resolution displays - and the DSS driver could be not aware of it.
So it could be that the OMAP5 is trying to output 864 MHz which is beyond the spec of the output driver. And therefore it outputs the 50% level instead of oscillating from 0% to 100% and back.
But so far this is just a vague hypothesis.
I just had an idea how to test this hypothesis:
I can reduce the pixel and DSI clock frequencies defined by the driver by the factor 2 or 4 or 8 and then I should see something if the clocks are simply too fast.
Planned for Wednesday...
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi
On Mon, Feb 24, 2014 at 5:50 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
What I could imagine is that there is indeed something missing or wrong in the DSI programming by the Linux driver. I have read again through the DSI programming chapters of the TRM and there appears to be some "divide by two mode" where I interpret a comment as if that one is not available in the OMAP4. So it *might* be required to use that mode on the OMAP5 for such high resolution displays - and the DSS driver could be not aware of it.
So it could be that the OMAP5 is trying to output 864 MHz which is beyond the spec of the output driver. And therefore it outputs the 50% level instead of oscillating from 0% to 100% and back.
There is also fair number of DSI issues in OMAP5 errata document, like PCD = 2 causing DISPC deadlock.. It might make sense dumping DSS registers and checking them against TRM, i.e. if everything is making sense there..
Gražvydas