[PATCH] arm: dma-mapping: move consistent_init to early_initcall
Catalin Marinas
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
>>> mind
>>> 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.
> Russell,
>
> 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
> stuff.
If there is no better proposal, I'm for such extension to the DMA API.
More information about the linux-arm-kernel
mailing list