Hi all, I have studied the OMAP5 TRM and section
10.2.4.12.6 DISPC Timing Generator and Panel Settings
describes that the DISPC indeed has a fixed format and I have not found a hint to trigger it by an external VSYNC. I wonder why TI didn’t add this to an already very complex SoC. We would not need all these tilers, replication filters, and pipelines, YUV transforms, etc. but such a simple feature to stretch the back porch until an external trigger arrives is missing…
BTW: the HDMI subsystem seems to have such a feature: „DISPC_TV_FID“ (Figure 10-83. DISPC TV Output Architecture).
But what about adding a (software) control loop around it?
The idea would be to act on two interrupts: a) the VSYNC1_IRQ interrupt from DISPC b) the TE input (as GPIO interrupt)
Both come with approx. 60Hz, i.e. very slowly. So the proposed mechanism isn’t heavy CPU load (could even be done by some Cortex M4 code if we ever manage to get it working).
Now my idea is that the CPU tries to measure the time between the interrupts.
Depending on the outcome we could try to increase or decrease VBP so that the control loop synchronises the DISPC speed *and* phase to the SSD TE output.
Could that work?
It would need: 1. detection of these interrupts 2. measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?) 3. modify VBP setting of DISPC on the fly (i.e. without disturbing DISPC operation) - register DISPC_TIMING_Vo[31:20] - so that the difference is likely ~0 next time [1][2]
The question will become how that fits into the OMAP DSS driver architecture. Would it become a special mode or a separate „external sync“ driver module? Or should we try to integrate such a function into the ssd2858 panel driver (if possible)?
BR, Nikolaus
[1] if that scheme works, two such measurements and an arbitrary initial modification of VBP could allow to calculate the correct VBP value. So I think locking could be done in 2-3 frames. [2] it is not necessary to have 0 skew. It must just be small enough so that DISPC buffer swapping occurs during vertical blanking as indicated by the SSD. So I would assume that we have 20-30 lines error bandwidth. So interrupt context switch latency in the kernel is also not critical.
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de