Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

From: Maciej W. Rozycki
Date: Thu Mar 07 2019 - 12:59:47 EST

Hi Alexandre,

I'm away on holiday and also connectivity is so-so here, so just a quick

> > Is there an MMIO completion barrier missing there somewhere by any chance
> > causing an IRQ that has been handled already to be redelivered because an
> > MMIO write meant to clear the IRQ at its origin at handler's completion
> > has not reached its destination before interrupts have been reenabled in
> > the issuing CPU? Just a thought.
> I've finally got a chance to bisect the IRQ14 (nobody cared) regression
> on my yeeloong. It took me to MIPS: Enforce strong ordering for MMIO
> accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f).

Thanks for looking into it.

> I've only just started trying to figure out what exactly in the change
> leads to problems. So far, I've determined that changing both uses of
> __BUILD_IOPORT_SINGLE so that barrier is passed as 0 rather than 1
> removes the undesirable effects, both on top of that patch, and on top
> of v5.0:
> #define __BUILD_IOPORT_PFX(bus, bwlq, type) \
> - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,) \
> - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
> + __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0,) \
> + __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0, _p)

So this seems backwards to me, port I/O is supposed to be strongly
ordered, so if removing the ordering guarantee "fixes" your problem, then
there must be a second bottom here. Offhand either there is a race
condition somewhere which the lack of ordering here covers somehow, or
there is a silicon erratum of some sort somewhere that the SYNC
instruction triggers.

A further investigation is required I'm afraid. Does your platform use