Date: Fri, 2 Jun 2000 23:16:54 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Mike Smith <msmith@FreeBSD.ORG> Cc: hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed Message-ID: <Pine.LNX.4.10.10006022213120.689-100000@linux.local> In-Reply-To: <200006021931.MAA03790@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Jun 2000, Mike Smith wrote: > > > > 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. > > >=20 > > > The bus_space_barrier() interface takes the bus tag and handle as=20 > > > arguments, so the ordering operations can make decisions about how th= ey=20 > > > should behave based on what you're operating on. > >=20 > > 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. >=20 > I think I'm understanding you here; you want to be able to ensure that a= =20 > set of eg. mmio-to-bus operations are completed before a following=20 > memory-write operation is performed, in an architecture where write=20 > ordering is not guaranteed? It is generally just the opposite. There are a couple of places in the ncr and sym drivers, and very probably in some other PCI device drivers, where the software driver (or the device) wants the other part to see a sequence of operations in a given order. I can take as an example the way ncr/sym handles the start queue: PSEUDO code in sym: - Queue the IDLE JOB to STARTQUEUE[i+1] - MEMORY_BARRIER - Queue the useful JOB to STARTQUEUE[i] - MEMORY_BARRIER - Write the SIGP bit to register ISTAT (tells the chip about a new job) Under Intel the memory barriers are just nil since program ordering is ensured. But under other architectures a reordering of the 3 writes can occur and lead to breakage if bad luck (Btw, extreme bad luck is needed). The ncr hasn't yet memory barriers since it was written for Intel. Btw, there are only a fiew places where a memory barrier is needed is these drivers. An other example: Normally PCI device drivers assume that (MM)IO operations are not reordered and that a read that transverses the bridges does flush posted transactions prior to the read being carried out to the device. On weak ordering systems, this requires appropriate barrier to be executed _prior_ to the (MM)IO read for the assumption to be valid. This is fine for alpha on both FreeBSD and NetBSD, but at least PPC kernel bus read function seems to call the barrier after the (MM)IO read under NetBSD (and also Linux:) which appears incorrect to me. > In this case, perhaps the NetBSD wbflush() addon is what actually=20 > 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=20 > time visualising what you'd want this for (but would appreciate being=20 > informed if you have the time). Hmmm... I haven't documentation enough on common PCI devices in order to understand their respective PCI device drivers, but each time I have looked into a PCI device driver I was almost sure that some PCI ordering problems existed in some places (most of the times related to posted transactions if MMIO was intended to be used). > > 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) >=20 > In the "bus space" way of thinking, all memory operations are mmio, even= =20 > if the mapped space is in system memory. Amen! ... But probably wrong. ;-) At least, it is my understanding of it. "bus space" seems to me to only care about IO/MMIO regarding ordering and it is probably too short thinking since ordering also involves memory accesses, for the reason PCI devices and CPU usually communicate using also memory as you know. > > On the other hand, I didn't found the kernel interface for byte orderin= g > > operations (think about NetBSD htole32() and friends). >=20 > We haven't (yet) ported to a non-little-endian architecture. You can=20 > reasonably expect that we will follow the NetBSD folks' lead on this, as= =20 > they've had plenty of time to come up with solutions that work. (Unless= =20 > you or someone else comes up with violent objections, of course.) I may have some in a near future, but very probably not violent at all. :) > > > Just so. The real joy, of course, comes when you're trying to make a= =20 > > > drive behave "correctly" on a wide range of different machines. 8) > >=20 > > I actually want it to be a joy, but for now it is a nightmare, unless I= =20 > > 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. ;-) >=20 > 8) If I implement portable (but stupid) htole32() and friends, only barriers are to be remade according to arch in the driver. All the other bus concerns use the corresponding kernel interface. This let me hope that joy is about to come. :) G=E9rard. 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?Pine.LNX.4.10.10006022213120.689-100000>