From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Matthew Wilcox <willy@debian.org>,
James Bottomley <James.Bottomley@steeleye.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Linux Arch list <linux-arch@vger.kernel.org>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
Andrew Morton <akpm@osdl.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"David S. Miller" <davem@redhat.com>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: RFC: being more anal about iospace accesses..
Date: Fri, 17 Sep 2004 15:20:46 +1000 [thread overview]
Message-ID: <1095398446.5109.43.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0409161152010.2333@ppc970.osdl.org>
> Actually, we could also take the "safe" approach, and just specify that
> the new "ioread()/iowrite()" interfaces are always very relaxed, and apart
> from endianness won't do much extra synchronization.
That would be catastrophic with 99% of the drivers on PPC. The processor
may speculate reads from outside spinlocks and that sort of horror, or
defer them to until much later, crossing writes and such things...
And we don't always have nice way of providing barriers. For example,
for enforcing a read to happen "now", the only way is to actually create
a pseudo dependency on the data returned by the read, so an
function/macro like "read_barrier()" can't be implemented unless it
takes the result of the read as an argument.
> What are sane rules? Clearly it is _not_ a sane rule to allow memory
> re-ordering to the same device, because most driver authors have problems
> as-is, and trying to make them aware of speculative reads and writes
> passing writes is just not going to fly. So a minimal sane rule would be
> that each device seens programmatic IO accesses in "thread order".
>
> But I think it would be ok to say that DMA needs explicit synchronization,
> and obviously write posting (as long as it doesn't re-order IO accesses)
> is fine. The latter is already true for MMIO (and arguably acceptable even
> for PIO, although x86's have historically had slightly stricter ordering
> on PIO).
Write posting is always assumed since it's already fine per PCI spec. I
don't agree with read vs. DMA.
> So how about trying to come up with a sane interface for "synchronize
> DMA". I _suspect_ it will have to be device-specific, so we should aim for
> a similar interface to the "dma-mapping" ones (ie based on "struct
> device", not the bus it's on).
>
> In most cases it would be a no-op, or we could hide some pointer a la
> "dev->bus->sync(dev)" (which could do a status read from the bridge or
> whatever..)
Ok, well, synchronize DMA would end up having to do a read on most
setups, so that mean knowing of a register on the device with no side
effects etc... difficult to acheive outside of the driver...
Ben.
next prev parent reply other threads:[~2004-09-17 5:22 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 22:57 RFC: being more anal about iospace accesses Linus Torvalds
2004-09-08 23:07 ` David S. Miller
2004-09-08 23:25 ` Linus Torvalds
2004-09-09 1:19 ` Linus Torvalds
2004-09-09 4:36 ` David S. Miller
2004-09-09 5:56 ` Richard Henderson
2004-09-09 5:04 ` viro
2004-09-09 5:05 ` David S. Miller
2004-09-09 5:13 ` Linus Torvalds
2004-09-09 6:08 ` viro
2004-09-09 8:27 ` Geert Uytterhoeven
2004-09-09 6:23 ` David Woodhouse
2004-09-09 13:14 ` Alan Cox
2004-09-11 6:09 ` Linus Torvalds
2004-09-11 6:42 ` Anton Blanchard
2004-09-11 7:26 ` Benjamin Herrenschmidt
2004-09-11 7:29 ` Geert Uytterhoeven
2004-09-11 7:23 ` Benjamin Herrenschmidt
2004-09-11 14:42 ` Alan Cox
2004-09-15 15:03 ` Linus Torvalds
2004-09-15 19:02 ` Geert Uytterhoeven
2004-09-15 19:16 ` Linus Torvalds
2004-09-15 19:40 ` Matthew Wilcox
2004-09-15 20:10 ` Linus Torvalds
2004-09-15 20:17 ` Linus Torvalds
2004-09-16 12:17 ` David Woodhouse
2004-09-16 13:52 ` Linus Torvalds
2004-09-15 20:20 ` Russell King
2004-09-15 20:34 ` Linus Torvalds
2004-09-15 20:51 ` Linus Torvalds
2004-09-15 22:38 ` James Bottomley
2004-09-16 2:33 ` Matthew Wilcox
2004-09-16 4:28 ` Linus Torvalds
2004-09-16 4:57 ` Benjamin Herrenschmidt
2004-09-16 4:58 ` Benjamin Herrenschmidt
2004-09-16 13:41 ` Matthew Wilcox
2004-09-16 18:21 ` Linus Torvalds
2004-09-16 18:52 ` Jesse Barnes
2004-09-16 19:09 ` Linus Torvalds
2004-09-16 20:02 ` Jesse Barnes
2004-09-16 20:37 ` James Bottomley
2004-09-16 20:42 ` Jesse Barnes
2004-09-16 21:37 ` Grant Grundler
2004-09-16 20:04 ` David S. Miller
2004-09-16 20:13 ` Jeff Garzik
2004-09-16 20:45 ` David S. Miller
2004-09-16 20:20 ` Jesse Barnes
2004-09-17 5:17 ` Benjamin Herrenschmidt
2004-09-17 15:30 ` Jesse Barnes
2004-09-16 19:01 ` Linus Torvalds
2004-09-16 19:13 ` Jeff Garzik
2004-09-16 19:50 ` Linus Torvalds
2004-09-16 20:07 ` Alan Cox
2004-09-17 5:44 ` Benjamin Herrenschmidt
2004-09-17 5:20 ` Benjamin Herrenschmidt [this message]
2004-09-17 15:03 ` Linus Torvalds
2004-09-16 22:30 ` Matthew Wilcox
2004-09-16 22:42 ` Linus Torvalds
2004-09-16 22:46 ` Jeff Garzik
2004-09-16 23:15 ` Linus Torvalds
2004-09-16 23:30 ` Jeff Garzik
2004-09-16 23:43 ` Linus Torvalds
2004-09-17 12:44 ` Matthew Wilcox
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=1095398446.5109.43.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=geert@linux-m68k.org \
--cc=jgarzik@pobox.com \
--cc=linux-arch@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
--cc=willy@debian.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