Date: Sat, 5 Oct 2013 22:15:29 -0600 From: Warner Losh <imp@bsdimp.com> 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: <0ED4F6A1-458A-474F-97F1-488336AB9A4D@bsdimp.com> 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 11:18 AM, Adrian Chadd 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. read after write ensures that the write is flushed by definition. > 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? If you are on a super-scalor architecture, then you'll need memory barriers. It doesn't look like we've implemented them just yet. > I'd like to sneak this into the initial mips74k bringup support that I'm > going to commit to -HEAD soon. Sneak what in? Warner > Thanks, > > > -adrian > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0ED4F6A1-458A-474F-97F1-488336AB9A4D>