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 want 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 they > > should behave based on what you're operating on. > > Hmmm... This stuff happens to do the expected work on FreeBSD-alpha, but > 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 ordering > 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>