RFC: figuring out bus behaviour on these mips32r2 chips

[Andrew Duane]

Warner is right: from a memory operation ordering perspective, SYNC should do it. That said, I have in my day encountered hardware registers (or hardware itself) that requires the extra memory accesses to insure its own internal operation ordering. Many of these have been on MIPS-architecture SoC systems.

....................................
Andrew L. Duane
AT&T Technical Lead
m   +1 603.770.7088
o    +1 408.933.6944 (2-6944)
skype: andrewlduane
aduane at juniper.net


-----Original Message-----
From: owner-freebsd-mips at freebsd.org [mailto:owner-freebsd-mips at freebsd.org] On Behalf Of Warner Losh
Sent: Thursday, January 08, 2015 5:55 PM
To: Adrian Chadd
Cc: freebsd-mips at freebsd.org
Subject: Re: RFC: figuring out bus behaviour on these mips32r2 chips


> On Jan 7, 2015, at 6:03 PM, Adrian Chadd <adrian at FreeBSD.org> wrote:
> 
> Hi,
> 
> I found that the new QCA955x chip (and some of the QCA934x things in 
> shipping products versus what I have on my desk at home) behave poorly 
> unless I do ye olde "write to register; read from register to flush"
> paradigm.
> 
> In this specific instance, it's the MDIO controller on each MAC - if I 
> do a read-after-write to those registers, everything is peachy.
> Without it - and even with a call to wmb() - it still barfs.
> 
> Now, I went digging through the mips code, and wmb() -> mips_sync() -> 
> just a sync operation. It doesn't do any other kind of barrier.
> 
> So - what's the mips32r2 spec require us to do for ensuring device IO 
> has made it out to devices and we enforce ordering? Are we missing 
> something in our mips_sync() implementation?

SYNC is supposed to be SYNC. An absolute barrier, but that may have weakened to being merely a strong ordering instruction such that all writes before it happen before all writes after it.

Warner