Date: Sun, 28 May 2000 00:41:56 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Warner Losh <imp@village.org> Cc: hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed Message-ID: <Pine.LNX.4.10.10005280003250.1425-100000@linux.local> In-Reply-To: <200005272143.PAA00751@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 May 2000, Warner Losh wrote: > In message <Pine.LNX.4.10.10005272157290.1197-100000@linux.local> =3D?ISO= -8859-1?Q?G=3DE9rard_Roudier?=3D writes: > : Existing bus abstractions tend to let think that the same software driv= er > : can deal with different buses, bridges or IO methods without having to > : care about how these things actually behave, notably regarding bufferin= g > : and ordering rules. This is untrue. >=20 > That statement is false. We have several drivers in the tree that > work on memory mapped or I/O mapped devices attached to many different > types of buses. NetBSD takes this even farther than we do. >=20 > : Existing bus abstractions may let driver writer think that everything t= hat > : addresses bridges, bus specific and arch specific properties is handled > : transparently given that the right abstract method is called in the rig= ht > : place. This is untrue. >=20 > But it does handle them transparently. Speaking about bus_space_*(): Does it make the thing follow the PCI ordering rules? Very probably not since it is impossible on some systems. 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. May-be bus_space handles transparently something that is not clearly specified.:) It seems that some MIPS machines only flush bridge buffering when a interrupt is raised. I didn't remember where I read that. For those ones, the only way to have workable drivers is to let the device stall until the driver will service the interrupt. If such machines exists, there is probably no way for any bus abstraction to make drivers, that run concurrently to the device firmware regarding bus transactions, to work properly. > : Existing bus transactions may let think that driver writers donnot have= =20 > : to care with ordering rules and coherency issues between transactions i= n=20 > : both directions targetting device and memory. > : This is untrue. >=20 > NetBSD's busdma does a great job of this. DMA is a horrible issue > with some machines donig it in virtual address space, and others doing > it in physical address space with no cache coherency. NetBSD does it > just fine and we're basically using the NetBSD interface. I mostly thought about bus_space(). I am quite aware about DMA issues on some machines. > : For example, if I want a WRITE TO MEMORY followed by a WRITE TO AN IO > : REGISTER performed from the C code to be seen consistently from the dev= ice > : (bus), most IO abstractions I have seen will do the bad work by just > : performing a memory barrier (or some additionnal barrier) after the WRI= TE > : TO THE IO REGISTER. If driver writer is not aware of this kind of > : subtleties, very ennoying bugs will be generated all around, in my > : opinion. >=20 > Most drivers do not do this. Those that do need to write to both will > use the proper tags. When the proper tags are used in the bus space > stuff, the proper barriers will be inserted at the right time (eg > after the write to memory) on those architectures that need it. Hmmm... That's the point I disagree on, btw. Inserting implicit barriers in the back of drivers can only be either sub-optimal or sometime not match driver expectations about ordering. Bus interface should allow more flexibility to drivers regarding ordering, in my opinion. > Most of these complaints are based on busspace, rather than the > newbus. bus space came from NetBSD and is working their very well. > FreeBSD has an older version of bus space in its tree. I've tried to > update it in the past, but the newbus stuff and the new NetBSD bus > space stuff overlap somewhat making it hard to modernize the busspace > stuff in FreeBSD. We will have to do it with the Sparc or MIPS ports > that are in the wings, but for now we are fat and happy. :-( I guess that porting to MIPS should need to complexify a lot the bus interface, but I bet that this probably will not be enough and that changes in some drivers will be needed. I donnot have NetBSD. If you can give me some pointers to relevant files that address the bus interface, I will try to download them and look into. I am only interested in the specification, so header files should be enough, unless a documentation exists. 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 code complexity, but when working on a driver, I think we must not forget the reality of what actually happens inside the machine. Regards, 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.10005280003250.1425-100000>