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 hardw= are itself) that requires the extra memory accesses to insure its own inter= nal operation ordering. Many of these have been on MIPS-architecture SoC sy= stems. .................................... Andrew L. Duane AT&T Technical Lead m=A0=A0=A0+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: >=20 > Hi, >=20 > I found that the new QCA955x chip (and some of the QCA934x things in=20 > shipping products versus what I have on my desk at home) behave poorly=20 > unless I do ye olde "write to register; read from register to flush" > paradigm. >=20 > In this specific instance, it's the MDIO controller on each MAC - if I=20 > do a read-after-write to those registers, everything is peachy. > Without it - and even with a call to wmb() - it still barfs. >=20 > Now, I went digging through the mips code, and wmb() -> mips_sync() ->=20 > just a sync operation. It doesn't do any other kind of barrier. >=20 > So - what's the mips32r2 spec require us to do for ensuring device IO=20 > has made it out to devices and we enforce ordering? Are we missing=20 > something in our mips_sync() implementation? SYNC is supposed to be SYNC. An absolute barrier, but that may have weakene= d 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>