Date: Sat, 5 Oct 2013 16:51:39 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Stanislav Sedov <stas@freebsd.org> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: How's bus-space stuff supposed to work with superscalar MIPS? Message-ID: <CAJ-Vmoky4Sc6DURPj_YeahUPe8=XurP_j7k1S_6L4gzhCXyPrw@mail.gmail.com> In-Reply-To: <5AD9EE93-9D19-4A07-B189-43DA0C4A85E9@FreeBSD.org> References: <CAJ-Vmo=PNSsW0eEAhc9LEDLswsj41VN%2BFX1vakQL=qGGdKqMuw@mail.gmail.com> <5AD9EE93-9D19-4A07-B189-43DA0C4A85E9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 October 2013 16:06, Stanislav Sedov <stas@freebsd.org> wrote: > > On Oct 5, 2013, at 10:18 AM, Adrian Chadd <adrian@freebsd.org> wrote: > > > Hi all, > > > > I've been bringing up the AR9344 PHY and after a lot of digging, I > > discovered that I can fix things by changing ARGE_WRITE() (ie, write to > the > > ethernet space registers) to: > > > > bus_write_4(); > > bus_read_4(); > > > > .. to (what I'm guessing here) flush the write out before the next > > instruction is run. > > > > So, given this particular hilarity has shown up, what's the story with > > doing IO accesses on a superscalar MIPS CPU? If it's going to kseg1, is > it > > somehow going to magically enforce ordering? Or am I right in thinking we > > will need explicit barriers here? > > > > I don't know specifics of mips74k, but usually one indeed needs memory > barriers > when performing read of write operation sequences that require ordering on > device I/O (e.g changing the ring and writing the new ring index > afterwards). I would > not be surprised if the cpu reorders i/o bus memory access, especially a > multi-issue > one. > > It is a good idea to have barriers where needed regardless. We have > special macros > for them which are defined to nothing on the in-order platforms. Right. I know this stuff. I really though want to know this kind of stuff: * What the specifics are for superscalar MIPS CPUs; * What the bus space stuff should be be providing by default (and I've been down this path once, with ath(4) bugs, PPC, and the bus space macros not enforcing flushes after IO operations, even though the API requires drivers do it themselves..); * Whether it should be enough to map space COHERENT - then it's up to the underlying bus implementation to implement enforcing ordering. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmoky4Sc6DURPj_YeahUPe8=XurP_j7k1S_6L4gzhCXyPrw>