Memory allocated by the coherent memory allocators will be marked
uncacheable, which means it's pointless calling consistent_sync()
to perform cache maintainence on this memory; it's just a waste of
CPU cycles.

Moreover, with the (subsequent) merge of outer cache support, it
actually breaks things to call consistent_sync() on anything but
direct-mapped memory.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

dma_sync_single is no more (and to be removed in 2.7) so this export should be dma_sync_single_for_cpu.

Also export dma_sync_single_for_device.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Kevin Hilman

Previous locking changes to dmabounce incorrectly return non-NULL even
when buffer not found.  Fix it up.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Kevin Hilman

This time with IRQ versions of locks.

Rework also enables compatability with realtime-preemption patch.
With the current locking via interrupt disabling, under RT,
potentially sleeping functions can be called with interrupts
disabled.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Erik Hovland

I found a typo and what seems to be a run-on sentence in
arch/arm/common/dmabounce.c

This patch corrects both.
Signed-off-by: NErik Hovland <erik@hovland.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Encapsulate pool data into dmabounce_pool.  Only account successful
allocations.  Use dma_mapping_error().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Convert dmabounce.c to use list_for_each_entry() instead of
list_for_each() + list_entry().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When DMA bounce buffers were unmapped and the data was memcpy'd to
the original buffer, we were not ensuring that the data was written
to RAM.  This means that there was the potential for page cache
pages to have different cache states depending whether they've been
bounced or not.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!