[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4E84BF5C.4020601@enea.com>
Date: Thu, 29 Sep 2011 20:56:28 +0200
From: Arvid Brodin <arvid.brodin@...a.com>
To: Håvard Skinnemoen <hskinnemoen@...il.com>
CC: <linux-kernel@...r.kernel.org>, <linux-embedded@...r.kernel.org>,
Hans-Christian Egtvedt <egtvedt@...fundet.no>, <arnd@...db.de>
Subject: Re: dma_unmap_single() lacking cache sync on some archs?
Håvard Skinnemoen wrote:
> Hi,
>
> On Tue, Sep 27, 2011 at 5:13 AM, Arvid Brodin <arvid.brodin@...a.com> wrote:
>> [Resending with CC to affected parties]
>>
>> Hi,
>>
>> I would expect cache synchronization for DMA_TO_DEVICE and DMA_BIDIRECTIONAL
>> when dma_map_single() is called, and for DMA_FROM_DEVICE and DMA_BIDIRECTIONAL
>> when dma_unmap_single() is called.
>>
>> However, on some architechtures (at least avr32, blackfin, ...), cache
>> synchronization only happens when dma_map_single() is called (and then
>> irrespective of DMA direction). dma_unmap_single() is a no-op for these archs.
>>
>> See e.g. http://lxr.linux.no/#linux+v3.0.4/arch/avr32/include/asm/dma-mapping.h#L117
>>
>> Isn't this a bug?
>
> I don't think so. What do other architectures do?
>
> We always need to sync before the transfer because if there is dirty
> data in the cache, it might get written to RAM during the transfer,
> which would be bad. Then, since the relevant cache lines are already
> clean and invalid, and the CPU is not allowed to access the buffer
> during the transfer, there's no need to sync again when the transfer
> is complete.
I see. Thanks for the explanation!
>
> Havard
--
Arvid Brodin
Enea Services Stockholm AB
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists