From owner-freebsd-mips@FreeBSD.ORG Thu Jan 8 22:59:24 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D41C56F9; Thu, 8 Jan 2015 22:59:24 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0140.outbound.protection.outlook.com [157.56.111.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43934825; Thu, 8 Jan 2015 22:59:23 +0000 (UTC) Received: from BY1PR0501MB1607.namprd05.prod.outlook.com (25.160.203.156) by BY1PR0501MB1605.namprd05.prod.outlook.com (25.160.203.154) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 8 Jan 2015 22:59:06 +0000 Received: from BY1PR0501MB1607.namprd05.prod.outlook.com ([25.160.203.156]) by BY1PR0501MB1607.namprd05.prod.outlook.com ([25.160.203.156]) with mapi id 15.01.0053.000; Thu, 8 Jan 2015 22:59:06 +0000 From: Andrew Duane To: Warner Losh , Adrian Chadd Subject: RE: RFC: figuring out bus behaviour on these mips32r2 chips Thread-Topic: RFC: figuring out bus behaviour on these mips32r2 chips Thread-Index: AQHQKt7fGlPSzxSDoEOGN9thcyi3b5y21poAgAAAfRA= Date: Thu, 8 Jan 2015 22:59:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=aduane@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1605; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1605; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189002)(199003)(51704005)(64706001)(20776003)(31966008)(97736003)(122556002)(40100003)(4396001)(120916001)(19580395003)(99396003)(46102003)(19580405001)(86362001)(33656002)(54206007)(101416001)(2656002)(92566001)(66066001)(54606007)(54356999)(76176999)(50986999)(87936001)(62966003)(106356001)(21056001)(2900100001)(77156002)(105586002)(107046002)(102836002)(68736005)(74316001)(99286002)(2950100001)(106116001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1605; H:BY1PR0501MB1607.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 22:59:06.3144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1605 Cc: "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:59:25 -0000 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 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