Hi Maciej, On Mon, Oct 08, 2018 at 01:36:55AM +0100, Maciej W. Rozycki wrote: > This patch series is a follow-up to my earlier consideration about MMIO > access ordering recorded here: <https://lkml.org/lkml/2014/4/28/201>. > > As I have learnt in a recent Alpha/Linux discussion starting here: > <https://marc.info/?i=alpine.LRH.2.02.1808161556450.13597%20()%20file01%20!%20intranet%20!%20prod%20!%20int%20!%20rdu2%20!%20redhat%20!%20com> > related to MMIO accessor ordering barriers ports are actually required to > follow the x86 strongly ordered semantics. As the ordering is not > specified in the MIPS architecture except for the SYNC instruction we do > have to put explicit barriers in MMIO accessors as otherwise ordering may > not be guaranteed. > > Fortunately on strongly ordered systems SYNC is expected to be as cheap > as a NOP, and on weakly ordered ones it is needed anyway. As from > revision 2.60 of the MIPS architecture specification however we have a > number of SYNC operations defined, and SYNC 0 has been upgraded from an > ordering to a completion barrier. We currently don't make use of these > extra operations and always use SYNC 0 instead, which this means that we > may be doing too much synchronisation with the barriers we have already > defined. > > This patch series does not make an attempt to optimise for SYNC operation > use, which belongs to a separate improvement. Instead it focuses on > fixing MMIO accesses so that drivers can rely on our own API definition. Agreed, using the lightweight sync types is a whole other can of worms. I did speak with the architecture team about the description of SYNC recently (in the context of nanoMIPS documentation if I recall) and hope the tweaks that were made to the architectural description of it might help with using them one day soon. > Following the original consideration specific MMIO barrier operations are > added. As they have turned out to be required to be implied by MMIO > accessors there is no immediate need to make them form a generic > cross-architecture internal Linux API. Therefore I defined them for the > MIPS architecture only, using the names originally coined by mostly taking > them from the PowerPC port. > > Then I have used them to fix `mmiowb', and then `readX' and `writeX' > accessors. Finally I have updated the `_relaxed' accessors to avoid > unnecessary synchronisation WRT DMA. Thanks - this definitely leaves us in a better place than we were :) All 4 patches applied to mips-next for 4.20. Paul
