Re: [PATCH] add delay between port write and port read

From: Will Deacon (will.deacon@xxxxxxx)
Date: Fri Feb 22 2019 - 12:38:51 EST


On Wed, Feb 20, 2019 at 05:52:18PM +0100, 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.

This thread seems to be confusing barriers with delays in places, but fwiw,
I agree with everything Maciej has said. I'm about to post a new version of
my memory-barriers.txt updates, so I'll cc people on that patch and we can
discuss the ordering side of things over there.

Will