[PATCH] arm: dma-mapping: move consistent_init to early_initcall
catalin.marinas at arm.com
Fri Dec 17 06:31:03 EST 2010
On 17 December 2010 10:26, Saravana Kannan <skannan at codeaurora.org> wrote:
>>> Looks like you agree with our approach. If that's the case, would you
>>> Acking Jeff's initial patch that this thread is based on?
>> I read Catalin's reply as agreeing with me.
> Catalin, Can you clarify?
I'll try but I started my holidays and I'll only be online occasionally.
Just to clarify, even if I ack Jeff's patch, it is for Russell to
decide what gets merged. Now, Jeff's patch doesn't show anything about
how the dma_alloc_coherent is used, just suggests something in the
commit log, so I don't see it critical to this discussion. I wouldn't
ack it without agreement on the extension of the DMA API (which can
only have a no-op get_dma_ops at this point).
I agree with Russell's points that just using the DMA API as it is may
break in the future, hence a proposal to treat it slightly different.
People in ARM working on a generic state save/restore mechanism face
the same problem - they need some non-cacheable memory for
synchronisation. I'm not sure whether they managed to find an
alternative algorithm with cached memory and cache flushing and I also
haven't followed the development to give more details.
> I agree with your point about using an API for purpose and not property.
> But I read Catalin's proposal as, let's treat secure domain as another DMA
> "device". If we make a conscious agreement to do that, then using the DMA
> API for secure domain would be "using it for its purpose" and we will make
> an effort to not break it with future updates. Of course, if we don't
> agree on that proposal, then we can't use the DMA API for secure domain
If there is no better proposal, I'm for such extension to the DMA API.
More information about the linux-arm-kernel