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
