Am 01.04.2014 um 19:00 schrieb Michael Mrozek:
Am Tue, 1 Apr 2014 15:22:47 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
If you use chip like that, make sure the rotation actually works. I don't know if they have something magical there, but normally you need a double buffer fb in the chip to support rotation. One buffer is written by the SoC, while the other is sent to the LCD. If there's just a single buffer, you'll get diagonal tearing.
I have looked into the data sheet and it appears that even 720x1280 drives the chip to its limits: • Half-WUXGA (0.5 x 1920 x 1200 pixels) frame buffer • Support rotation up to 1280x800 resolution with SSL Compression • Support rotation up to 960x600 resolution without image compression
So it has only enough on-chip RAM for a single buffer.
Well, according to Solomon Systech, the display got a pin specifically for tear-free rotation when used with an OMAP5.
Surely that pin has some reason... it wouldn't really make sense adding such pin if the OMAP5 can do the same with its own hardware. Something we really need to check.
And SSL-Compression means:
"SSL segment-based (4 pixels per segment) data compression/decompression with zero software overhead"
So it appears that we won't get full resolution 720x1280 rotated with that chip with less problems than with OMAP5 TILER! The problems will just be somewhere else.
Is that, once again, a special framebuffer format or is that something that maybe MIPI supports and it only needs to be switched off?
As far as I understand it is a simple 24bit*lines*pixels bit stream coming in landcape out from the OMAP5 DISPC formatted in 1280 wide MIPI containers. One for each line. So the input is more or less a digitalized TV image.
This is temporarily stored in the frame buffer on the chip.
It is then read out in 720 vertical containers and encoded again as MIPI so that a portrait mode panel starts to scan vertical lines from left to right.
The issue is that the frame buffer in the chip is apparently only ~1 Mpix.
Which is sufficient for a 720x1280 panel.
But it is written on the input side while it is read out. So depending on sync you will have areas with frame x and areas with frame x+1.
This is what Tomi means with the risk of tearing.
Solomon Systech might have added the TE signal - which is more or less a VSYNC impulse. And that should be used by the kernel driver to write in some synced way.
But I have no idea about the details and if using that makes another bottleneck.
-- 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