Messages in this thread | | | Date | Fri, 17 Dec 2010 11:31:03 +0000 | Subject | Re: [PATCH] arm: dma-mapping: move consistent_init to early_initcall | From | Catalin Marinas <> |
| |
On 17 December 2010 10:26, Saravana Kannan <skannan@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. From the kernel perspecitve, the secure side is just another entity that accesses the RAM directly. It's not a physically separate device indeed but from a direct memory access perspective it can be treated as any other device.
In the DMA API we can fall back to the non-coherent ops when a NULL struct device is passed. I assume in your code you already pass a NULL device to dma_alloc_coherent().
-- Catalin
| |