On 01/04/14 14:41, Grazvydas Ignotas wrote:
Hi,
Nice, thanks for figuring it out.
Btw, please try to add me in "To:" for the post, as I may well miss the reply if it's not directed to me.
On Tue, Apr 1, 2014 at 9:58 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
I was able to get rid of the L3 errors when using TILER 2D buffer. Patch attached. It's illegal to use caching on TILER 2D buffers, so that was causing the issues.
Hmm, that was write combining, not caching. Shame even that doesn't
I was using "caching" in the broad sense. write-combining is a form of caching. So the only allowed option is to disable all caching.
I have to say I'm not 100% sure about the above. It maybe that write-combining works with certain kinds of CPU accesses. But I still guess that disabling the caching is a safe generic fix here.
work, accessing strongly ordered memory will be very slow even if the page fault problem is fixed.
I don't know about "very slow", but yes, it will definitely affect the performance. Do you happen to have any numbers?
Do you have any ideas what kind of access patters to the fb are common? Is it normal to draw pixels here and there? I hope not. If the normal pattern is to copy bigger pieces to the framebuffer, the performance hit may not be huge (just guessing).
It sucks having to use a shadow buffer, even if DMA does it, it still means additional ~1GB/s of memory bandwidth wasted (~500MB/s for reading + ~500MB/s for writing to TILER), which adds to ~500MB/s needed for DISPC to update the screen and whatever is needed for CPU to draw the frame. I hope ED makes the right decision and at least uses lower resolution screen.
Yes, I agree. TILER + very high resolution screen sounds risky to me, if the target is to support "all" applications (as in, compared to, say, all apps working on top of android compositor which uses sgx or such).
Tomi