EvilDragon said:
10 hours ago, EvilDragon said: Yes, it's annoying that it can't simply use the video input timings, but you could also say it's annoying that all SoCs ignore the anti-tearing signal when run in video mode...
I don't want to belabor this point too much, but most displays synchronize on their inputs, not the other way around. And there are actually some good reasons for this. If the same clock domain controls the display controller, processor, audio etc it's a lot easier to keep these things synchronized without worrying about time shifting anything or checking synchronization.
Yes, when the display is directly connected to the SoC. This also works without any issues.
However, whenever there's a MIPI-bridge (like the rotator chip or any MIPI to HDMI or whatever-bridge) involved, it's different.
There's the anti-tearing signal, and that one ALWAYS is an output from the bridge and an input on the SoC.
Don't ask me why - but that's what the MIPI commitee came up with.
We actually fell into that trap as well, as we thought this is a sync signal from the OMAP to the bridge (which would make a lot more sense in our opinion).
I can imagine that the reason they do it like this is the way the command mode works.
As mentioned, in command mode, the SoC only sends a frame whenever content changes. So if a smartphone shows the dashboard which doesn't change for a minute or so, it doesn't send a stream which reduces power usage.
So there's no sync coming from the SoC to the display or bridge during that time.
So the display controller (they usually have a framebuffer) has to keep the sync.
When the SoC wants to send one or more frames because the content is updated, it let's the display/bridge know which then sends the anti-tear-signal (which is a basically a 'send the frame now'-signal).
With that it mind, it makes sense the sync is coming from the displaycontroller / bridge to the SoC and not the other way round.
The rotator chip we're using is being used in millions of chinese android smartphones, all using command mode with the anti-tearing signal coming from the chip to the SoC.