From: William Jhun <wjhun@ayrnetworks.com>
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: Carsten Langgaard <carstenl@mips.com>,
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
linux-mips@oss.sgi.com
Subject: Re: PCI patch of the day
Date: Wed, 7 Aug 2002 09:38:28 -0700 [thread overview]
Message-ID: <20020807093828.A6317@ayrnetworks.com> (raw)
In-Reply-To: <20020807120938.A13850@dea.linux-mips.net>; from ralf@oss.sgi.com on Wed, Aug 07, 2002 at 12:09:38PM +0200
Ralf,
Will the *_dma_cache_wback() routines ever be implemented? I sent out a
set of patches a while ago that defaults them to calling _wback_inv()
instead of calling panic(). Additionally I sent out some PCI DMA
coherency patches that would, for pci_map_*():
- Invalidate if DMAing from the device
- Writeback if DMAing to the device
- Writeback/Invalidate if bidirectional
pci_dma_sync_*() was changed to simply invalidate if DMAing from the
device or bidirectional. Conceivably, the pci_unmap_*() should
invalidate as well, since the following could happen:
- pci_dma_sync_*()
- driver reads out of buffer
- DMA happens again
- pci_unmap_*()
- buffer cachelines better be invalidated!
Not to mention that the whole PCI DMA interface is inherently broken.
I've cogitated on this and sent patches to those responsible, but was
told to buzz off. The above is a good example of this broken-ness:
you'll have an extra invalidate for no reason if you never end up using
pci_dma_sync_*() but just simply map, DMA and unmap. Otherwise, it'll be
broken for the pci_dma_sync_*() case. And I've already went on before
about how streaming mappings are broken for PCI_DMA_TODEVICE when
re-using one buffer.
I've already spent a lot of time trying to sort this out and get the
patches right, but since I received almost zero response I dropped it.
Apparently it's still broken enough to need further attention.
Will
On Wed, Aug 07, 2002 at 12:09:38PM +0200, Ralf Baechle wrote:
> Sigh, yes. The whole flushing thing was done improperly and the patches
> to fix that which I was integrating last night were not right either. The
> big question for me is why nobody was complaining or is suddently everybody
> only using coherent machines ...
prev parent reply other threads:[~2002-08-07 16:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-07 8:20 PCI patch of the day Carsten Langgaard
2002-08-07 10:09 ` Ralf Baechle
2002-08-07 16:38 ` William Jhun [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=20020807093828.A6317@ayrnetworks.com \
--to=wjhun@ayrnetworks.com \
--cc=carstenl@mips.com \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.