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

["Maciej W. Rozycki" <macro@linux-mips.org>]

Hi Alexandre,

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

> >  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 
`war_io_reorder_wmb'?

  Maciej