Date: Fri, 02 Jun 2000 12:31:13 -0700 From: Mike Smith <msmith@freebsd.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed Message-ID: <200006021931.MAA03790@mass.cdrom.com> In-Reply-To: Your message of "Fri, 02 Jun 2000 10:10:47 %2B0200." <Pine.LNX.4.10.10006020938340.281-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Typically, a driver may want to order some operations and also not = break > > > post buffering each time a write is performed. It may for example w= ant to > > > order some operations, but not flush all writes immediately. I didn= 't see > > > how to tell bus about that. > > = > > The bus_space_barrier() interface takes the bus tag and handle as = > > arguments, so the ordering operations can make decisions about how th= ey = > > should behave based on what you're operating on. > = > Hmmm... This stuff happens to do the expected work on FreeBSD-alpha, bu= t > the bus_space_barrier() apparent semantic seems more restrictive. What = we > may want is to have some handle on the order a sequence of memory _and_= > mmio operations is actually carried out to the system bus. I think I'm understanding you here; you want to be able to ensure that a = set of eg. mmio-to-bus operations are completed before a following = memory-write operation is performed, in an architecture where write = ordering is not guaranteed? In this case, perhaps the NetBSD wbflush() addon is what actually = addresses your concerns? To be honest, I haven't ever run across a peripheral where this sort of timing would be a concern; I have a hard = time visualising what you'd want this for (but would appreciate being = informed if you have the time). > But the > bus_space_barrier() semantic only seems to care about mmio operations. = (I > have had a look into NetBSD ppc. Here too, bus_space_barrier() does the= > expected work, despite the apparent restrictive semantic of this verb) In the "bus space" way of thinking, all memory operations are mmio, even = if the mapped space is in system memory. > On the other hand, I didn't found the kernel interface for byte orderin= g > operations (think about NetBSD htole32() and friends). We haven't (yet) ported to a non-little-endian architecture. You can = reasonably expect that we will follow the NetBSD folks' lead on this, as = they've had plenty of time to come up with solutions that work. (Unless = you or someone else comes up with violent objections, of course.) > > Just so. The real joy, of course, comes when you're trying to make a= = > > drive behave "correctly" on a wide range of different machines. 8) > = > I actually want it to be a joy, but for now it is a nightmare, unless I= = > decide to do the real work from the device driver. Unfortunately, I > haven't time enough to study all existing architectures and existing > bridges variants. > This let the expected joy not to be about to come. ;-) 8) -- = \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006021931.MAA03790>