From: "David S. Miller" <davem@redhat.com>
To: dsaxena@plexity.net
Cc: mporter@kernel.crashing.org, lists@mdiehl.de,
linux-kernel@vger.kernel.org
Subject: Re: [Patch] dma_sync_to_device
Date: Wed, 11 Feb 2004 19:58:12 -0800 [thread overview]
Message-ID: <20040211195812.4db8cede.davem@redhat.com> (raw)
In-Reply-To: <20040212034610.GA27317@plexity.net>
On Wed, 11 Feb 2004 20:46:11 -0700
Deepak Saxena <dsaxena@plexity.net> wrote:
> /me groks now. I am assuming this is a 2.7 thing as it is
> reinterpreting/redefining the API.
No, it is adding an operation that previously was impossible to
make occur.
> In ARM, pci_dma_sync_single() does
> a cache flush, which is why I was confused asked about two cache flushes.
> What you are proposing is that by definition pci_dma_sync_* syncs
> bridges caches with system memory, while pci_dma_sync_device_* syncs
> the CPU's cache with system memory.
>
> This will definetely confuse a lot of driver writers.
What I am proposing, is to keep pci_dma_sync_*() with it's current definition
which is to transfer control of the buffer from DEVICE to CPU. It has always
been defined this way.
I am also adding a new operation, pci_dma_sync_device_*() which transfers control
of the buffer from CPU back to DEVICE. This operation was not possible previously.
Therefore we will merge this into both 2.6.x and 2.4.x as soon as a suitable full
and reviewed patch exists.
If you flush the cache on ARM for pci_dma_sync_*(), so what? If the cpu writes to
the buffer then asks the device to DMA from the area it's going to see garbage.
To be honest there aren't many pci_dma_sync_*() users, and thus it is relatively
easy to audit them all for problems in this area. Yes, updates and clarifications
in the docs will be necessary as well.
next prev parent reply other threads:[~2004-02-12 3:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-10 17:31 [Patch] dma_sync_to_device Martin Diehl
2004-02-10 18:42 ` David S. Miller
2004-02-10 18:59 ` Martin Diehl
2004-02-11 6:17 ` Deepak Saxena
2004-02-11 6:51 ` Martin Diehl
2004-02-11 16:39 ` Deepak Saxena
2004-02-11 17:51 ` David S. Miller
2004-02-11 18:18 ` Matt Porter
2004-02-11 18:30 ` David S. Miller
2004-02-11 18:57 ` Deepak Saxena
2004-02-11 19:08 ` David S. Miller
2004-02-12 3:46 ` Deepak Saxena
2004-02-12 3:58 ` David S. Miller [this message]
2004-02-13 1:49 ` Jamie Lokier
2004-02-14 7:24 ` David S. Miller
2004-02-11 19:23 ` Matt Porter
2004-02-11 19:30 ` David S. Miller
2004-02-11 18:43 ` linux-2.6.2 Kernel Problem Elikster
2004-02-14 11:51 ` Adrian Bunk
-- strict thread matches above, loose matches on Subject: below --
2004-02-13 14:27 [Patch] dma_sync_to_device James Bottomley
2004-02-14 8:51 ` Martin Diehl
2004-02-14 22:34 ` James Bottomley
2004-02-14 23:18 ` David S. Miller
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=20040211195812.4db8cede.davem@redhat.com \
--to=davem@redhat.com \
--cc=dsaxena@plexity.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@mdiehl.de \
--cc=mporter@kernel.crashing.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