Date: Sat, 15 Oct 2011 21:45:23 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@FreeBSD.ORG> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: newbus bus access routines and bus_space_barrier() Message-ID: <4EEA1F8B-9854-4C5C-A397-95AD454D3680@bsdimp.com> In-Reply-To: <CAJ-VmonJnHyLQJ-kVtMV=X7mq7=wq2MGn9wUqdbEtZ6qXd52rg@mail.gmail.com> References: <CAJ-VmonJnHyLQJ-kVtMV=X7mq7=wq2MGn9wUqdbEtZ6qXd52rg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Usually they are needed, but we get away without them often because they = are needed in a limited set of circumstances and we have memory barriers = in our locking primitives. Warner On Oct 15, 2011, at 7:48 PM, Adrian Chadd wrote: > Hi all, >=20 > I'm not clued up on the way of the bus API, so please excuse the > newbie questions. >=20 > Nathan and I found that ath(4) wasn't working for a user because of a > missing bus barrier. Ath trips it up because it does lots of loops of > register reads/writes through the bus stream API rather than the > normal bus API. > It does this because it handles the register value swapping in > hardware rather than in software. >=20 > The correct fix is to teach ath(4) to use bus_space_barrier() calls > when doing stream calls, which I can do, but the newbus documentation > points out that both normal and stream bus access doesn't enforce > ordering, and barrier calls are needed. But I don't see lots of > bus_space_barrier() calls everywhere. Why's that? >=20 > Thanks, >=20 >=20 > Adrian > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EEA1F8B-9854-4C5C-A397-95AD454D3680>