From: William Jhun <wjhun@ayrnetworks.com>
To: "David S. Miller" <davem@redhat.com>
Cc: "linux-kernel@vger.kernel.org"@ayrnetworks.com,
"linux-mips@oss.sgi.com"@ayrnetworks.com
Subject: Re: Deprecate pci_dma_sync_{single,sg}()?
Date: Thu, 6 Jun 2002 10:40:37 -0700 [thread overview]
Message-ID: <20020606104036.A11943@ayrnetworks.com> (raw)
In-Reply-To: <20020605131231.B10773@ayrnetworks.com> <20020605.154747.58455261.davem@redhat.com>
On Wed, Jun 05, 2002 at 03:47:47PM -0700, David S. Miller wrote:
> From: William Jhun <wjhun@ayrnetworks.com>
> Date: Wed, 5 Jun 2002 13:12:31 -0700
>
> In the current linux-mips implementation, this has some subtle problems:
> pci_unmap_{single,sg}() is essentially a no-op.
>
> Right, I see the problem. I'll think about this some more.
>
> As it stands now, I think the correct solution is to require
> pci_dma_prep_single() before giving the buffer back to the
> device after the read.
Right, that's what I was thinking. Is it asking a lot to demand that all
existing drivers that use this interface add pci_dma_prep_single()? How
will backward compatiblility with older drivers work? That's why I
suggested leaving pci_dma_sync_single() and adding
pci_dma_release_single() which can leave the cache flush to
pci_dma_prep_single(). It seems like elsewhere, like the D-cache
flushing interface (for virtual aliasing), both old and new interfaces
co-exist. Does this seem to work out O.K. in your experience?
Will
next prev parent reply other threads:[~2002-06-06 17:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-05 20:12 Deprecate pci_dma_sync_{single,sg}()? William Jhun
[not found] ` <20020605.154747.58455261.davem@redhat.com>
2002-06-06 17:40 ` William Jhun [this message]
[not found] <mailman.1023308362.19729.linux-kernel2news@redhat.com>
2002-06-05 21:56 ` Pete Zaitcev
2002-06-05 23:02 ` 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=20020606104036.A11943@ayrnetworks.com \
--to=wjhun@ayrnetworks.com \
--cc="linux-kernel@vger.kernel.org"@ayrnetworks.com \
--cc="linux-mips@oss.sgi.com"@ayrnetworks.com \
--cc=davem@redhat.com \
/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