Hi Tomi, we are trying to find out why the low power communication with the ssd2858 rotator chip is unreliable.
My last test was to boot the OMAP5432EVM, start the rotator with the panel-mipi-debug driver and just send generic read packets to the ssd (to read out a register value) in a loop. The shell script speed appears to be one packet every 6ms. There is no high speed video stream enabled.
This sequence did succeed ~10 times and then failed:
[ 52.880569] dsi: mipi_debug_reset(0) [ 57.342784] dsi: mipi_debug_regulator(1) [ 64.613874] dsi: mipi_debug_reset(1) [ 76.991831] x_res=1280 [ 76.994491] y_res=720 [ 76.997052] dsi: mipi_debug_start() [ 77.001041] dsi: mipi_debug_power_on() [ 77.014577] dsi: enabled() [ 95.800064] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.806605] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.812807] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.818963] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.825080] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.831298] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.837691] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.843805] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.849950] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.856059] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.862200] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 96.366686] omapdss DSI error: Failed to receive BTA [ 96.371901] omapdss DSI error: DSI error, irqstatus 100010 [ 96.377759] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 96.876725] omapdss DSI error: Failed to receive BTA [ 96.881939] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.386659] omapdss DSI error: Failed to receive BTA [ 97.391875] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.896653] omapdss DSI error: Failed to receive BTA [ 97.901863] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.406643] omapdss DSI error: Failed to receive BTA [ 98.411862] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.916677] omapdss DSI error: Failed to receive BTA [ 98.921890] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.426620] omapdss DSI error: Failed to receive BTA [ 99.431840] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.936594] omapdss DSI error: Failed to receive BTA [ 99.941803] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.446674] omapdss DSI error: Failed to receive BTA [ 100.451894] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.956567] omapdss DSI error: Failed to receive BTA [ 100.961783] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 101.466561] omapdss DSI error: Failed to receive BTA [ 101.471781] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5
Using an Oscilloscope I could see some packets on the DSI lane 1 as expected, but what I wonder is why I see silence (LP-11 state) after the first BTA/DSI error.
This means that the OMAP5 stops any transmission. Is this expected behaviour of the DSI driver?
And I usually need to reboot the EVM to get out of this state. So can we somehow “reset” the DSI subsystem to the initial state without reboot?
BR, Nikolaus
Am Wed, 1 Apr 2015 10:30:43 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Just a quick addition: The low power communication WAS working last year with an older kernel. So it might be that the bug appeared sometime with a more recent kernel.
Hi Tomi, we are trying to find out why the low power communication with the ssd2858 rotator chip is unreliable.
My last test was to boot the OMAP5432EVM, start the rotator with the panel-mipi-debug driver and just send generic read packets to the ssd (to read out a register value) in a loop. The shell script speed appears to be one packet every 6ms. There is no high speed video stream enabled.
This sequence did succeed ~10 times and then failed:
[ 52.880569] dsi: mipi_debug_reset(0) [ 57.342784] dsi: mipi_debug_regulator(1) [ 64.613874] dsi: mipi_debug_reset(1) [ 76.991831] x_res=1280 [ 76.994491] y_res=720 [ 76.997052] dsi: mipi_debug_start() [ 77.001041] dsi: mipi_debug_power_on() [ 77.014577] dsi: enabled() [ 95.800064] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.806605] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.812807] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.818963] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.825080] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.831298] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.837691] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.843805] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.849950] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.856059] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.862200] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 96.366686] omapdss DSI error: Failed to receive BTA [ 96.371901] omapdss DSI error: DSI error, irqstatus 100010 [ 96.377759] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 96.876725] omapdss DSI error: Failed to receive BTA [ 96.881939] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.386659] omapdss DSI error: Failed to receive BTA [ 97.391875] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.896653] omapdss DSI error: Failed to receive BTA [ 97.901863] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.406643] omapdss DSI error: Failed to receive BTA [ 98.411862] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.916677] omapdss DSI error: Failed to receive BTA [ 98.921890] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.426620] omapdss DSI error: Failed to receive BTA [ 99.431840] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.936594] omapdss DSI error: Failed to receive BTA [ 99.941803] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.446674] omapdss DSI error: Failed to receive BTA [ 100.451894] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.956567] omapdss DSI error: Failed to receive BTA [ 100.961783] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 101.466561] omapdss DSI error: Failed to receive BTA [ 101.471781] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5
Using an Oscilloscope I could see some packets on the DSI lane 1 as expected, but what I wonder is why I see silence (LP-11 state) after the first BTA/DSI error.
This means that the OMAP5 stops any transmission. Is this expected behaviour of the DSI driver?
And I usually need to reboot the EVM to get out of this state. So can we somehow “reset” the DSI subsystem to the initial state without reboot?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 01/04/15 11:30, Dr. H. Nikolaus Schaller wrote:
Hi Tomi, we are trying to find out why the low power communication with the ssd2858 rotator chip is unreliable.
Do you have any other devices to test this? A DSI panel without using the ssd2858?
My last test was to boot the OMAP5432EVM, start the rotator with the panel-mipi-debug driver and just send generic read packets to the ssd (to read out a register value) in a loop. The shell script speed appears to be one packet every 6ms. There is no high speed video stream enabled.
This sequence did succeed ~10 times and then failed:
[ 52.880569] dsi: mipi_debug_reset(0) [ 57.342784] dsi: mipi_debug_regulator(1) [ 64.613874] dsi: mipi_debug_reset(1) [ 76.991831] x_res=1280 [ 76.994491] y_res=720 [ 76.997052] dsi: mipi_debug_start() [ 77.001041] dsi: mipi_debug_power_on() [ 77.014577] dsi: enabled() [ 95.800064] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.806605] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.812807] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.818963] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.825080] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.831298] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.837691] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.843805] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.849950] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.856059] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.862200] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 96.366686] omapdss DSI error: Failed to receive BTA [ 96.371901] omapdss DSI error: DSI error, irqstatus 100010 [ 96.377759] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 96.876725] omapdss DSI error: Failed to receive BTA [ 96.881939] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.386659] omapdss DSI error: Failed to receive BTA [ 97.391875] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.896653] omapdss DSI error: Failed to receive BTA [ 97.901863] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.406643] omapdss DSI error: Failed to receive BTA [ 98.411862] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.916677] omapdss DSI error: Failed to receive BTA [ 98.921890] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.426620] omapdss DSI error: Failed to receive BTA [ 99.431840] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.936594] omapdss DSI error: Failed to receive BTA [ 99.941803] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.446674] omapdss DSI error: Failed to receive BTA [ 100.451894] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.956567] omapdss DSI error: Failed to receive BTA [ 100.961783] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 101.466561] omapdss DSI error: Failed to receive BTA [ 101.471781] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5
Using an Oscilloscope I could see some packets on the DSI lane 1 as expected, but what I wonder is why I see silence (LP-11 state) after the first BTA/DSI error.
It's been quite a while since I did anything with DSI, so I can't say much. If you have only a few changes on top of the mainline kernel, it might be relatively easy to git-bisect it (presuming there's an older kernel that works).
You could also try lowering (or increasing if it's already low) the LP clock rate, or having small delays between DSI reads, to see if those have any effect.
This means that the OMAP5 stops any transmission. Is this expected behaviour of the DSI driver?
Kind of. The driver doesn't have much support to recover from (presumably) HW issues. Especially as in some/many cases we should reset the whole DSI or even DSS IP.
And, of course, the problem might be in the external components. If they keep pulling the DSI lines in some position, you won't see anything with oscilloscope. Although in that case I think you should see complexio errors from the DSI driver.
And I usually need to reboot the EVM to get out of this state. So can we somehow “reset” the DSI subsystem to the initial state without reboot?
Well, if you use kernel modules, you can unload and load the dss modules. Sometimes that's enough. But unfortunately the HW sometimes gets "stuck" and a proper reset for the HW block would be needed.
And at the moment we don't have proper support for resetting the blocks, as the HWMOD framework is supposed to handle the registers where the RESET bit is.
So it's quite broken, but that is normally not a big issue as the unrecoverable issues should not happen if the HW works properly. And, obviously, the SW doesn't have bugs that would cause the problems.
Tomi
Hi Tomi,
Am 07.04.2015 um 16:04 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 01/04/15 11:30, Dr. H. Nikolaus Schaller wrote:
Hi Tomi, we are trying to find out why the low power communication with the ssd2858 rotator chip is unreliable.
Do you have any other devices to test this? A DSI panel without using the ssd2858?
Yes, and there it works.
My last test was to boot the OMAP5432EVM, start the rotator with the panel-mipi-debug driver and just send generic read packets to the ssd (to read out a register value) in a loop. The shell script speed appears to be one packet every 6ms. There is no high speed video stream enabled.
This sequence did succeed ~10 times and then failed:
[ 52.880569] dsi: mipi_debug_reset(0) [ 57.342784] dsi: mipi_debug_regulator(1) [ 64.613874] dsi: mipi_debug_reset(1) [ 76.991831] x_res=1280 [ 76.994491] y_res=720 [ 76.997052] dsi: mipi_debug_start() [ 77.001041] dsi: mipi_debug_power_on() [ 77.014577] dsi: enabled() [ 95.800064] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.806605] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.812807] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.818963] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.825080] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.831298] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.837691] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.843805] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.849950] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.856059] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 95.862200] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 02 [ 96.366686] omapdss DSI error: Failed to receive BTA [ 96.371901] omapdss DSI error: DSI error, irqstatus 100010 [ 96.377759] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 96.876725] omapdss DSI error: Failed to receive BTA [ 96.881939] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.386659] omapdss DSI error: Failed to receive BTA [ 97.391875] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 97.896653] omapdss DSI error: Failed to receive BTA [ 97.901863] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.406643] omapdss DSI error: Failed to receive BTA [ 98.411862] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 98.916677] omapdss DSI error: Failed to receive BTA [ 98.921890] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.426620] omapdss DSI error: Failed to receive BTA [ 99.431840] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 99.936594] omapdss DSI error: Failed to receive BTA [ 99.941803] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.446674] omapdss DSI error: Failed to receive BTA [ 100.451894] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 100.956567] omapdss DSI error: Failed to receive BTA [ 100.961783] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5 [ 101.466561] omapdss DSI error: Failed to receive BTA [ 101.471781] dsi: mipi_debug_read(g, 00 04) -> 00 00 00 00 failed: -5
Using an Oscilloscope I could see some packets on the DSI lane 1 as expected, but what I wonder is why I see silence (LP-11 state) after the first BTA/DSI error.
It's been quite a while since I did anything with DSI, so I can't say much. If you have only a few changes on top of the mainline kernel, it might be relatively easy to git-bisect it (presuming there's an older kernel that works).
You could also try lowering (or increasing if it's already low) the LP clock rate, or having small delays between DSI reads, to see if those have any effect.
Sorry, I forgot to announce that we have understood / solved that problem.
There is some MIPI-DSI document that says that the LP clocks must be in range 67% … 150% of each other.
We did fulfill this condition (9.6 MHz vs. 12 MHz), but either the OMAP5 or the ssd2858 is more critical.
Only after making it 96% the same (12 MHz vs. 11.5 MHz) the BTA errors did vanish. So I am now only struggling with programming the ssd2858 chip.
But the panel-mipi-debug driver is really helpful in this case. I have even added a “start” command where I can modify some timing parameters passed to the OMAP DSI drivers to accomodate different pixelclock, resolutions, lp clock settings etc.
This means that the OMAP5 stops any transmission. Is this expected behaviour of the DSI driver?
Kind of. The driver doesn't have much support to recover from (presumably) HW issues. Especially as in some/many cases we should reset the whole DSI or even DSS IP.
And, of course, the problem might be in the external components. If they keep pulling the DSI lines in some position, you won't see anything with oscilloscope. Although in that case I think you should see complexio errors from the DSI driver.
And I usually need to reboot the EVM to get out of this state. So can we somehow “reset” the DSI subsystem to the initial state without reboot?
Well, if you use kernel modules, you can unload and load the dss modules. Sometimes that's enough. But unfortunately the HW sometimes gets "stuck" and a proper reset for the HW block would be needed.
And at the moment we don't have proper support for resetting the blocks, as the HWMOD framework is supposed to handle the registers where the RESET bit is.
Ok, I see. So it might get stuck in a way that only a CPU reboot helps.
So it's quite broken, but that is normally not a big issue as the unrecoverable issues should not happen if the HW works properly. And, obviously, the SW doesn’t have bugs that would cause the problems.
Well, if SW works and HW is stable, nobody needs that. It would just help me (developer) if neither is :)
BR, Nikolaus
On 07/04/15 17:49, Dr. H. Nikolaus Schaller wrote:
So it's quite broken, but that is normally not a big issue as the unrecoverable issues should not happen if the HW works properly. And, obviously, the SW doesn’t have bugs that would cause the problems.
Well, if SW works and HW is stable, nobody needs that. It would just help me (developer) if neither is :)
If you encounter the issue often while hacking, it's simple to change the dss driver's probe to set the RESET bit in the DSS_SYSCOFIG, right after enabling clocks. That will reset all the DSS submodules.
And, of course, you have to use modules, and remove and load them, for the reset to happen.
Tomi