CONSISTENT_DMA_SIZE limitations

[Magnus Damm]

On Wed, Apr 28, 2010 at 3:47 PM, Eric Miao <eric.y.miao at gmail.com> wrote:
> On Wed, Apr 28, 2010 at 2:25 PM, Magnus Damm <magnus.damm at gmail.com> wrote:
>> Extending CONSISTENT_DMA_SIZE seems like a good idea to me, but I'm
>> not sure if doing so will break something else. Perhaps I need to
>> rework some code in arch/arm/mm/dma-mapping.c?
>>
>
> Hi Magnus,
>
> For a hackish way of enabling something, I don't think that's a bad idea
> to extend CONSISTENT_DMA_SIZE. And it's often seen by framebuffer
> and video/graphics related drivers, which is normally hungry for large
> amount of consistent memory. However, I'm a little bit concerned about
> such usage, (esp. I'm not sure how this is done in ARMv7), my preference
> would be:
>
> 1) either use the dma API
> 2) or reserve a large chunk of memory during boot and get it remapped later

Hi Eric,

So we already have a bunch of multimedia-related drivers upstream for
SH, and they often make use of dma_alloc_coherent() and friends.
Chunks of physically contiguous memory are allocated during boot and
passed on to the platform drivers as a struct resource. This is true
for the LCDC fbdev and the CEU v4l2 code, as well as all the uio
devices. To avoid fragmentation issues the v4l2 driver also creates a
memory pool from the struct resource using
dma_declare_coherent_memory().

Eventually I'd like to tie in the IOMMU, but first i'd like to enable
the existing drivers by extending CONSISTENT_DMA_SIZE.

Thanks for your comments!

/ magnus