A few quick notes:
DISPC_TV_FID is something else.
Having that kind of "stretch back porch" would not comply with DSI standard. And, to me, sounds like quite a hack.
SSD data sheet says it supports video mode and command mode, and it says it support rotation. What you are discussing here is not related to rotation, but "how can video mode be used with SSD". The SSD docs should explain how video mode can be used (i.e. how the SSD input and output are syncronized).
If a device (SSD) supports video mode, it should be able to synchronize with the video input stream. I don't see how SSD could advertize supporting video mode if it cannot sync with the input.
Command mode should work with omapdss. omapfb has ioctl to send a frame. omapdrm doesn't support command mode. The command mode SW implementation is designed so that the expectation is that the userspace explicitly requests a frame to be updated, i.e. there's no "automatic update" support.
Also note that rotation requires double buffering in SSD, i.e. they have 2 x frame memory, update from SoC goes to one, while the other one is being displayed on panel. Presumably it requires config to use double buffering. If you don't do that, and update the same piece of memory from SoC while it's being displayed, you'll see diagonal tearing.
And if SSD doesn't have double buffering support, I don't see how they can support rotation (properly).
Tomi
On 06/11/2015 12:17 AM, Dr. H. Nikolaus Schaller wrote:
Am 10.06.2015 um 23:09 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Wed, Jun 10, 2015 at 11:06 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
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…
Agreed...
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:
- detection of these interrupts
Should work.
- measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?)
Sort of... You can read the µs timestamp fine but there will be random interrupt latency because the CPUs may be busy with other things (wakeup latency depending if CPU was asleep, higher priority interrupt handling or critical sections with irqs disabled) when our interrupts arrive - Linux is not a realtime OS.
Agreed. But I think the required precision is in the range of 10 scan lines, i.e. 130µs.
That said we already use similar hack to read pandora's touchscreen during vblank to avoid horrible noise we get doing that during active display and it works kind of ok.
- 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]
Note that DISPC_TIMING_Vx is a shadow register (hardware only reads it on VFP start), which may cause trouble, but hopefully it would work. Some filter code could be added to deal with latency spikes.
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)?
Sounds like it will be quite horrible with little chance of getting mainlined, so will be a maintenance burden forever either for us or whoever accepts it into mainline. Although it's probably better that out-of-tree pandora's TS hack where I had to fight against linux's driver isolation to get completely unrelated drivers to cooperate.
Anyway this sounds like the least bad solution so far,
:)
the other one being potential use of command mode with TE. Tomi, can command mode be used to achieve steady 60fps?
This would be better of course.
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.
I think it would need constant adjustment because of OMAP's and SSD's clocks being derived from separate crystals, and the smallest adjustment granularity we has is the whole line or column. The clock frequency difference will slightly differ between different units too, will be affected by temperatures and so on...
[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.
We can manipulate this somewhat by choosing large blanking periods, but still drifting needs to be dealt with somehow…
Drifting is accounted for by making it phase locked (and not frequency locked). I.e. if the frequencies disagree by let’s say 0.1 Hz, this might mean 20 lines skew per second. Enough time to regulate the VBP of the intermediate frames.
So I see no problem if the VBP is adjusted every now and then to keep the average frequency the same - and the sync pulses start roughly at the same moment.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel