Date: Sat, 27 May 2000 18:41:35 -0600 From: Warner Losh <imp@village.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: <200005280041.SAA01578@harmony.village.org> In-Reply-To: Your message of "Sun, 28 May 2000 00:41:56 %2B0200." <Pine.LNX.4.10.10005280003250.1425-100000@linux.local> References: <Pine.LNX.4.10.10005280003250.1425-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.LNX.4.10.10005280003250.1425-100000@linux.local> =?ISO-8859-1?Q?G=E9rard_Roudier?= writes: : 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. I've seen several MIPS designs, and I've never seen one that do that. I have seen several where you have to be extremely careful about DMA. Generally MIPS designs have cache coherency problems. When one flushes the cache, these bridges should flush at the same time. : 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. The bus_space interface in NetBSD makes this explicit. : 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. For FreeBSD, yes. For NetBSD many drivers no changes were 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. src/sys/arch/*/include/bus*.h. : 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. NetBSD's experience has shown that this is mostly possible with very little work. Warner 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?200005280041.SAA01578>