Re: [PATCH] arm: dma-mapping: move consistent_init to early_initcall

[Catalin Marinas]

On 17 December 2010 10:26, Saravana Kannan <skannan@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/