Am Sun, 30 Mar 2014 20:39:59 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
As far as I know the full stream goes always through that chip, so there's no direct connection between the Panel to the OMAP5 in this case, but from the Panel to the IC to the OMAP5.
I mean the problem that the panel driver in Linux assumes that it can directly send DCS commands to the panel. Therefore they arrive at the interconnect chip which expects them in a special format to forward them to the panel or it will try to interpret them directly. So I am simply not sure if the software architecture of panel drivers is prepared for this situation. It can certainly be done, but may be a major task (for kernel drivers).
Well, it would probably need a special driver, but I can ask whether that is available or not.
I'm not hoping for ultra-fast rotation. But right now, it's ultra-slow. (notaz can give more details about it). Additionally, rotation eats up CPU power as well right now (100%)
Hm. I thought the tiler is working completely independently of the CPU cores? So it should only be set up once by the CPU?
Well, notaz may correct me in case I'm not 100% correct here (not sure I remember it all correctly).
One issue is: To rotate with TILER, the framebuffer needs to be in a special format. The X driver supports that format, so everything should be fine here. However, that is not the case or SDL or programs using directly the framebuffer.
These need to be converted - which is slowing it down a bit, but hopefully not too much. (besides: you can't simply recompile programs anymore - you need to add that conversion into the code as well)
The main problem is programs direcly writing to the hardware. The Pandora is very fast with notaz' emulators or enhanced SDL version, because it writes directly into the display memory.
And that's what's so horribly slow right now - and where it's related to that forum entry.
So as far as I understood: No problem when using X, but a huge issue with most games and emulators (due to SDL / Framebuffer access)
There's already a thread with no solution yet: http://e2e.ti.com/support/omap/f/885/p/322408/1121877.aspx
Is this really related? To me it appears as if someone has connected a camera and does memcpy a lot of data. This may of course drive the CPU to 100%.
We need to use memcpy as well for all non-X stuff - which is a lot.
So I would not give up too fast. Saving a chip and reducing maximum resolution IMHO warrants investing some more time into potential software issues...
Well, that issue is probably something we cannot solve alone. It's a simple memcpy command. It could be one of the many OMAP5 registers that's not properly setup, and only TI knows what they do.
Right now, rotation is faster when doing in software than using memcpy and using the TILER, so it' not really usable.
If I understood notaz correctly, we basically lose a few hundred (!!) fps because of that.
If no software fix can be found, we need to find a way to rotate the display using some hardware.
It would certainly be more convenient as well - as a simple recompile of games won't work, you need to add the rotation code.
My hope was that we can setup TILER independent from the programs, so that it always rotates the screen regardless what program is running. But that doesn't work, as it needs a special format.
notaz can probably explain it more accurate and better than me.