On Wed, 3 Apr 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.
>
> I did some more testing and it turns out that mb() is not entirely
> sufficient to prevent the boot hang. mb()'s latecy varies, sometimes it is
> sufficient, sometimes not.
>
> So, I submit this patch that adds 1us delay between any I/O accesses
> directed at the ISA bus. This patch makes my machine boot. 1us seems to be
> minimal acceptable value, with 800ns I still get hangs.
Why wasn't the delay needed then before commit cd0e00c10672 ("alpha: io:
reorder barriers to guarantee writeX() and iowriteX() ordering"), which
only moved `mb' around?
Maciej
