Date: Fri, 2 Jun 2000 10:10:47 +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.10006020938340.281-100000@linux.local> In-Reply-To: <200005282051.NAA04805@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 May 2000, Mike Smith wrote: > > Speaking about bus_space_*(): Does it make the thing follow the PCI > > ordering rules? Very probably not since it is impossible on some system= s. >=20 > There's no attempt to do this, no. However, it's possible to implement= =20 > this if there's a need. >=20 > > Typically, a driver may want to order some operations and also not brea= k > > 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 s= ee > > 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 they= =20 > 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. 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) As a result, for the moment, the only way for me to provide correct ordering support for other archs (notably ppc) will be to add some assembly language in driver code. On the other hand, I didn't found the kernel interface for byte ordering operations (think about NetBSD htole32() and friends). > > Hmmm... That's the point I disagree on, btw. Inserting implicit barrier= s > > in the back of drivers can only be either sub-optimal or sometime not > > match driver expectations about ordering. Bus interface should allow mo= re > > flexibility to drivers regarding ordering, in my opinion. >=20 > I think Warner answered this, and he probably understood your point=20 > better; at the moment, the driver is solely responsible for managing=20 > ordering. None of our current busspace backends perform any sort of=20 > ordering. And this let me claim that some drivers may well be broken regarding ordering on some archs. This happen to be the case at least for the ncr on both FreeBSD-alpha, and on NetBSD-alpha/ppc, very probably. But I suspect numerous other pci device drivers to suffer of the same problem. Generally, ordering problems donnot prevent a driver from working most of the time, but extremally weird breakage may happen sometimes. > > By the way, as I wrote in my previous mail, I am unable to propose a > > better interface. I only wanted to point out that bus abstractions are = far > > from being perfect. They make portability possible without too much cod= e > > complexity, but when working on a driver, I think we must not forget th= e > > reality of what actually happens inside the machine. >=20 > 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) 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. ;-) 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.10006020938340.281-100000>