Date: Sat, 5 Oct 2013 16:06:58 -0700 From: Stanislav Sedov <stas@FreeBSD.org> To: Adrian Chadd <adrian@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: <5AD9EE93-9D19-4A07-B189-43DA0C4A85E9@FreeBSD.org> In-Reply-To: <CAJ-Vmo=PNSsW0eEAhc9LEDLswsj41VN%2BFX1vakQL=qGGdKqMuw@mail.gmail.com> References: <CAJ-Vmo=PNSsW0eEAhc9LEDLswsj41VN%2BFX1vakQL=qGGdKqMuw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 5, 2013, at 10:18 AM, Adrian Chadd <adrian@freebsd.org> wrote: > Hi all, >=20 > 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 th= e > ethernet space registers) to: >=20 > bus_write_4(); > bus_read_4(); >=20 > .. to (what I'm guessing here) flush the write out before the next > instruction is run. >=20 > 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? >=20 I don't know specifics of mips74k, but usually one indeed needs memory barri= ers 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 mul= ti-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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5AD9EE93-9D19-4A07-B189-43DA0C4A85E9>