arm_syscall cacheflush breakage on VIPT platforms

[jamie@shareable.org (Jamie Lokier)]

Aguirre Rodriguez, Sergio Alberto wrote:
> In OMAP3 specifically, we were looking for this to happen, since we have
> big buffers that we need to share with other subsystems.
> 
> For example, when we take a 8 megapixel RAW 10-bit image (16MB) and
> we want to send it to the DSP bridge driver, doing a memcpy to another kernel
> allocated and mmaped buffer is a very suboptimal idea.
> (which is our only option as per your statement)

I used to think that about moving compressed video data around.  I
wanted my video decoding application to avoid copying compressed data
(which is about 20Mbit/s).  But then I did some back-of-the-envelope
calculations and decided it was so much easier to copy:

You're copying 16MB.  Let me guess - 32 bit data bus?  According to
Wikipedia, OMAP3 CPU is 600 to 1000MHz.  I've no idea what you're RAM
bus speed is, but is it somewhere around 200MHz?

Just guesstimating here: 16MB on 32-bit bus at 200MHz, copying to RAM
and back again = 200/8 = 0.04 seconds.

Is 0.04 seconds copying time worth devising zero-copy schemes for?  If
that's every frame of a video I'd say yes (but you'd have other
problems first); if it's non-video camera processing then I'd say no.
It's _nice_ to shave off 0.04 seconds, but weight it up against the
difficulties (and overheads) of making reliable DMA in this case.

-- Jamie