public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: zaitcev@redhat.com
Cc: wjhun@ayrnetworks.com, linux-kernel@vger.kernel.org
Subject: Re: Deprecate pci_dma_sync_{single,sg}()?
Date: Wed, 05 Jun 2002 16:02:01 -0700 (PDT)	[thread overview]
Message-ID: <20020605.160201.76773422.davem@redhat.com> (raw)
In-Reply-To: <200206052156.g55LuTI15282@devserv.devel.redhat.com>

   From: Pete Zaitcev <zaitcev@redhat.com>
   Date: Wed, 5 Jun 2002 17:56:29 -0400

   >[...]
   > In the current linux-mips implementation, this has some subtle problems:
   > pci_unmap_{single,sg}() is essentially a no-op. Thus, in the above
   > example, a driver would break (stale cachelines from a previous
   > pci_dma_sync_*/read would not be invalidated). One might argue that a
   > cache invalidate should happen in the pci_unmap_single(). But then the
   > other case (where a driver does a pci_map, DMAs, does a pci_unmap, and
   > sends it up the stack) would require an additional cache
   > flush/invalidate that is not needed at all.
   
   Frist, fix mips, it is broken.

No, MIPS is not broken.  If there is no intervening call into
the PCI DMA layer between the read of the data and giving
the buffer back to the device, it has no reason to flush.

It flushes when it should, at pci_map_single() time for
PCI_DMA_FROM_DEVICE direction.

This provides the behavior exactly as inteded by the API.
It is precisely the optimization non-cache-coherent cpu
systems are expected to do for best performance.

  reply	other threads:[~2002-06-05 23:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1023308362.19729.linux-kernel2news@redhat.com>
2002-06-05 21:56 ` Deprecate pci_dma_sync_{single,sg}()? Pete Zaitcev
2002-06-05 23:02   ` David S. Miller [this message]
2002-06-05 20:12 William Jhun
     [not found] ` <20020605.154747.58455261.davem@redhat.com>
2002-06-06 17:40   ` William Jhun

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=20020605.160201.76773422.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wjhun@ayrnetworks.com \
    --cc=zaitcev@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