Date: Thu, 8 Jan 2015 22:59:06 +0000 From: Andrew Duane <aduane@juniper.net> To: Warner Losh <imp@bsdimp.com>, Adrian Chadd <adrian@FreeBSD.org> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: RE: RFC: figuring out bus behaviour on these mips32r2 chips Message-ID: <BY1PR0501MB1607CE6F684CF8D8A5D326F0CE470@BY1PR0501MB1607.namprd05.prod.outlook.com> In-Reply-To: <B54C22FD-1EF2-4ABE-8ACF-002619ECA4EB@bsdimp.com> References: <CAJ-Vmo=SY8q7fnycbjj_HVkLj0QdHymNftKXsmm1teussdMOrw@mail.gmail.com> <B54C22FD-1EF2-4ABE-8ACF-002619ECA4EB@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@juniper.net -----Original Message----- From: owner-freebsd-mips@freebsd.org [mailto:owner-freebsd-mips@freebsd.org] On Behalf Of Warner Losh Sent: Thursday, January 08, 2015 5:55 PM To: Adrian Chadd Cc: freebsd-mips@freebsd.org Subject: Re: RFC: figuring out bus behaviour on these mips32r2 chips > On Jan 7, 2015, at 6:03 PM, Adrian Chadd <adrian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BY1PR0501MB1607CE6F684CF8D8A5D326F0CE470>