From owner-freebsd-hackers Sat May 27 17:41:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 73BC637B590 for ; Sat, 27 May 2000 17:41:48 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29961; Sat, 27 May 2000 18:41:46 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01578; Sat, 27 May 2000 18:41:35 -0600 (MDT) Message-Id: <200005280041.SAA01578@harmony.village.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Subject: Re: 4.0 - Isa devices not being probed Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 28 May 2000 00:41:56 +0200." References: Date: Sat, 27 May 2000 18:41:35 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message =?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