Am 02.04.2014 um 16:15 schrieb Michael Mrozek:
Am Wed, 2 Apr 2014 15:51:09 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Yes, BOE and Solomon Systech are sitting in the same building and working together. The Solomon chip is already being used with that exact display
What is the application? A TV (Moviel) screen or a computer display?
Many gaming smartphones in China.
For movies they might get a good and completely invisible compression. But for Windows, Text, Line graphics it might not work well.
Why? I've got codecs on my video editing machine that generally does lossless compression (mathematical) and only uses lossy algorithms in case the bandwitdh is not enough.
Almost any desktop picture can easily compressed lossless to about 20% of the size, as colors don't change that much (windows often have 90% the same color, etc.).
I've just made a snapshot of my desktop with about 4 different open windows full of text, a background image, etc.
Uncompressed (BMP) it's 4,1MB, with compression (LZW) TIFF (lossless) it's 1MB, with highest PNG compression (lossless as well) it's 726kB.
I cannot see a reason why a standard desktop screen should not fit into 50% with mathematical compression.
Because it depends on the content if it can be compressed. There are (rare) situations where you can't compress the image losless to 50%.
- compression works for movies here the image quality can be
reduced whithout the eye seeing the difference
Compression works for anything, depending on algorithms being used. TIFF and TGA support lossless (LZMA) compression as well.
But any lossless compression may get a compression rate of 0%. The system must be able to handle this special case as well.
Yes, in which case lossy compression will be added. That already works fine with various encoders I use on my video editing machine: I set a maximum bitrate and can do picture-per-picture compression (I-Frame only, so no moving estimation) and it's only doing lossy compression in case the bitrate is set too low.
That's nothing special these days.
But that is IMHO a false analogy. Because your video editing equipment can do that it does not mean that the chip does it.
Might be useful when using it to read PDFs, when not much happens.
But there we also don't have problems with TILER :)
What does that have to do with the power saving features of the chip?
For a static image the TILER only needs to rotate once.
Which is not an issue. The issue is with non-static images, which also need to work on our system.
Right now it seems TILER will both cause a huge impact on the CPU as well as make coding more complex as it needs a special format, whereas the Solomon Systech chip CAN do rotation and scaling without the need of CPU power or special code. The kernel would simply see it as landscape display.
No. The kernel must program the chip so that it works as intended. So there is an additional driver in the kernel. Although it will likely be straightforward and not very complex.
According to Solomon Systech (and as I can see from the examples I've sent earlier this morning), you send the MIPI commands to the Solomon Systech chip instead of to the display.
So instead of a display driver talking to the display you got a "display" driver talking to the Solomon chip, which then takes care of the rest.
Yes, exactly what I mean.
Yes, by reducing image quality.
Which is something you don't even know yet, and especially not how bad it is.
We will see it as soon as we have built a prototype.
I've got all datasheets and will send them to you tonight. 5 displays will be ready in about 20 days, the Solomon Systech chips will probably arrive next week.
Fine!
The longer I think about it it appears to me that we are simply not sure how to use the TILER efficiently (see below).
Well, according to Tomi it seems TILER was never intended to be used to rotate a full display.
Maybe I have a completely different pipelines in mind from my studying of the TRM and I must admit that I still don't exactly know what Notaz's experiments do where we get the 320x240 slowness.
I don't know exactly where the issue is as well, but as far as I have understood it's the copying into TILERs memory that slows things down a lot.
Yes, and that is where I understood (wrongly?) the TRM that the TILER can be used directly by the DISPC to read only from memory. I.e. it does not write anything because it directly goes to the panel. No write, no write problems.
But I may have misinterpreted the TRM completely:
10.2.1 DISPC Overview • Common: – Rotation 0, 90, 180, and 270 degrees using DMM-TILER • DMA (internal to the DISPC): – Support for accessing tiled structure through the TILER inside the dynamic memory management (DMM) – Support for accessing nontiled structure through the TILER or directly – Support for rotation, flip-flop, and mirroring though the TILER inside the DMM – Support for memory fragmentation though the TILER inside the DMM – Integrated shared buffers between DMA engine and pipelines
10.2.4.7 DISPC Rotation and Mirroring The DISPC provides flexible mechanisms for efficient implementation of rotation using the DISPC, its DMA engine, and the rotation engine of the TILER. The rotation is handled only through the TILER, which supplies the encoded pixels to the DISPC.
Table 10-27. DISPC Register Settings for Rotation Using TILER
So it appears that the TI designers have thought about efficient interaction between TILER and DISPC.
All this TILER things would have to be set up only once during boot and just the Scaler Unit must be adjusted during run-time to different framebuffer dimensions.
That would be perfect if it works like that, but somehow it seems it doesn't work like that.
If we use the Solomon Systech Chip, we've got the following issues:
Just for completeness how the pipeline would look like with Solomon chip:
- application (e.g. 480x800 screen 50fps) ->
- memory mapped frame buffer ->
- MIPI ->
- Rotator Chip ->
- MIPI ->
- panel (720 x 1280 x 60fps)
Removed the scaler, as the rotator chip can scale and rotate.
Yes, you are right.
What I don't exactly get matched with our discussions are the specs on their web page:
SSD2848 4-lane MIPI in, 4-lane MIPI out bridge chip Transmission rate support up to 4 x 1.5Gbps lanes. display up to 1920*1200 Mass Production Send Request SSD2858 4-lane MIPI in, 8-lane MIPI out bridge chip Rx support up to 4 x 1.5Gbps lanes, Tx support up to 8 x 1.0Gbps lanes, display up to 2560*1600
This would mean we can use it with the LG Full-HD panel?
NEGATIVE: you get 44% of the pixels at 50% of the price
MOQ: LG: 5000 = 400,000 EUR MOQ: BOE: 1000 = 30,000 EUR
If you have 370,000 EUR you can lend me until we sold the first 2000 - 3000 Pyras, then we could see that as negative point, yes :)
Killer argument :)
If you want a better display you would try to get the 400k€. If you believe in 5000 per year, it does not matter.
But don't mind. We will do the experiments with the rotator and see.
BR, Nikolaus
-- 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