Re: [PATCH] add delay between port write and port read
From: Mikulas Patocka (mpatocka@xxxxxxxxxx)
Date: Wed Feb 20 2019 - 12:47:41 EST
On Wed, 20 Feb 2019, Arnd Bergmann wrote:
> On Wed, Feb 20, 2019 at 4:38 PM Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> wrote:
> > On Wed, 20 Feb 2019, Mikulas Patocka wrote:
> > > > Well, actually `iowriteX' is generic and for MMIO you have `writeX'.
> > > > See lib/iomap.c, the comment at the top and e.g. `iowrite8' there for an
> > > > actual proof. Alpha may have an oddball implementation, but there you go.
> > > > Drivers will assume they can do `iowriteX' to any kind of I/O resource,
> > > > and ordering must be respected as per Documentation/memory-barriers.txt.
> > >
> > > So, do you think that the barrier whould be added to iowriteX and slow
> > > down every MMIO access?
> > We need it either for `outX' and `iowriteX' calls operating on port I/O
> > resources, or for neither of them, both at a time, to ensure the required
> > consistency between the two interfaces. If that badly affects MMIO (and
> > is not required there; please remind me what the exact justification to
> > use `mb' here is, as it's not entirely clear to me from the commit
> > message; `mb' is a barrier and not means for a delay), then we need to
> > find a away for `iowriteX' to tell port I/O and MMIO accesses apart and
> > only apply the barrier for the former kind.
> Will Deacon is in the process of sanitizing our documentation for this,
> and this part is still under discussion.
> I personally don't see a problem with having different barrier
> semantics between outb() and iowrite8(), the reasoning being that
> any caller of iowriteX() would already have to be careful about
> posted writes when iowriteX is backed by ioremapped memory
> space rather than port I/O.
> I think the more important question we have to figure out here
> however is why exactly the barrier is needed for alpha, as I still
> don't fully understand the issue:
Port delays were common on MS-DOS with the ISA bus. On the ISA bus, the
device cannot reject a transaction, so the programmer has to wait until
the device is ready before talking to it.
My hypothesis is that the engineers who built this Alpha Avanti machine
simply bought some crappy serial line and real-time clock logic from some
ISA bus vendor. And so it requires delays. The PCI stuff on the same
machine doesn't require any extra delays.
> a) maybe the barrier here is only needed to provide the
> non-posted PCI write behavior required by outb(), in that
> case I would suggest adding the barriers to outX() but
> perhaps not iowriteX()
Except for serial line and real-time-clock, the machine works OK. So
there's no need to slow down regural PCI accesses that use iowriteX.
> b) or the barriers are in fact needed for /any/ I/O operation
> on alpha, to ensure that a store is ordered with regard to
> a following load. If this is the case, we need the barriers
> in all three families: outX(), writeX() and iowriteX().
My understanding is that multiple accesses to the same PCI space are