On 06/11/2015 02:03 PM, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 11.06.2015 um 12:43 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
A few quick notes:
DISPC_TV_FID is something else.
I think I mixed it up with DISPC_TV_VSYNC coming from the HDMI timing generator.
Ok. Yes, DISPC supports external sync, where "external" means outside DISPC but inside DSS =). Although the external sync with DISPC is not something that would work with plain TE signal.
Having that kind of "stretch back porch" would not comply with DSI standard. And, to me, sounds like quite a hack.
Sometimes a working quick hack is more valuable than a good and broad solution that is not available :)
Sure. Feel free to try your quick hack, but it sounds to me like a very complex 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".
There is some relation to rotation because rotation means that the HSYNC frequency on the input is different from the HSYNC frequency to the panel. Even if VSYNC is identical. But you are right - keeping input and output in VSYNC is also a problem in non-rotated mode.
The SSD docs should explain how video mode can be used (i.e. how the SSD input and output are syncronized).
They say (and we can confirm) that the SSD generates a TE output signal (even in video mode) and the video source must be synchronized to it…
The TE here is probably directly sourced from the SSD's VSYNC, which exists with video mode also. They just never gate the TE signal. But DSI video mode does not need TE, it's only for command mode. I don't see how SSD can require TE with DSI video mode, and still say they are DSI compliant.
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.
That would be a “stretch back porch” applied to the SSD output going to the panel.
I think we can pass-through both HSYNC and VSYNC but AFAIK this does not work in combination with rotation (because different HSYNC frequency requirements).
Ok. So it might be that SSD does not support rotation with video mode.
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.
Understood. It looks to me as it makes using it with X11 or Qt a little difficult because AFAIK they expect a simply framebuffer and an auto-updating panel.
Yes, I don't recommend DSI command mode. But it is an option. The driver could be modified to send frames automatically, making DSI command mode look like normal video mode from user's point of view.
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.
I think we have enabled that and we see vertical tearing (i.e. the moment where buffers are swapped is not in sync).
And if SSD doesn't have double buffering support, I don't see how they can support rotation (properly).
Tomi
So it might end up that we have to try the second worst solution to sync the VSYNC interrupts by a daemon.
Or could the daemon simply to the same as the command mode ioctl()? I.e. we would trigger it by the panel VSYNC interrupt?
My recommendations for possible solutions:
1) try to use SSD with video mode. Maybe it can take the clock from the DSI video mode input, but you can still define different hsync/vsync/etc for output. That way SSD runs with the clock from OMAP, and they are synchronized, and SSD can still send the output in rotated form. This is how I would've designed the SSD chip, and I've seen similar on other chips.
Or, if it can't take the clock from the input video stream, you may still be able to sync SSD to the input's vsync. This I have also seen on other chips. In this mode the clocks may drift a bit, but as there's a sync point at the start of every frame, it doesn't matter as long as the drift is small.
2) try command mode. if it works flawlessly with SSD, hack the omapdss's dsi driver to continuously send frames.
Btw is there a public doc for the SSD chip?
Tomi