From: Arvid Brodin <arvid.brodin@enea.com>
To: "Håvard Skinnemoen" <hskinnemoen@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
Hans-Christian Egtvedt <egtvedt@samfundet.no>,
arnd@arndb.de
Subject: Re: dma_unmap_single() lacking cache sync on some archs?
Date: Thu, 29 Sep 2011 20:56:28 +0200 [thread overview]
Message-ID: <4E84BF5C.4020601@enea.com> (raw)
In-Reply-To: <CAF8ieYUPcer2ZwaOi6YbiZQPeDBFukT2_dPStH10G_15Rh1fpw@mail.gmail.com>
Håvard Skinnemoen wrote:
> Hi,
>
> On Tue, Sep 27, 2011 at 5:13 AM, Arvid Brodin <arvid.brodin@enea.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
prev parent reply other threads:[~2011-09-29 18:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-27 12:13 dma_unmap_single() lacking cache sync on some archs? Arvid Brodin
2011-09-27 16:55 ` Håvard Skinnemoen
2011-09-27 18:27 ` Arnd Bergmann
2011-09-29 18:56 ` Arvid Brodin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E84BF5C.4020601@enea.com \
--to=arvid.brodin@enea.com \
--cc=arnd@arndb.de \
--cc=egtvedt@samfundet.no \
--cc=hskinnemoen@gmail.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).