From owner-freebsd-current Thu Nov 9 0:31:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E756B37B479; Thu, 9 Nov 2000 00:31:45 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id TAA07445; Thu, 9 Nov 2000 19:31:01 +1100 Date: Thu, 9 Nov 2000 19:31:26 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: "Matthew N. Dodd" , "Justin T. Gibbs" , Bill Paul , current@FreeBSD.ORG Subject: Re: vx driver patch In-Reply-To: <200011082018.NAA32387@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Nov 2000, Warner Losh wrote: > In message "Matthew N. Dodd" writes: > : On Wed, 8 Nov 2000, Warner Losh wrote: > : > The cardbus code, for example, will or in the RF_SHAREABLE bit when > : > appropriate. > : > : Right, but the drivers that are consumers of the PCI or CARDBUS bus > : interface shouldn't have to deal with RF_SHAREABLE; the bus driver should > : do that. I grant you that this isn't the case at the moment but it should > : be. > > We are in violent agreement. The cardbus bridge code is the one that > adds RF_SHAREABLE in the right places. We currently have about 146 calls to bus_alloc_resource() for SYS_RES_IRQ. Most seem to get this wrong. E.g.: - pci drivers "know" that pci interrupts are shareable and force RF_SHAREABLE. Is this required by the pci spec? - the isa compatibility code and pcvt force RF_SHAREABLE although isa irqs are rarely shareable. - sio forces !RF_SHAREABLE, but it is possible for sio interrupts to be shared if they aren't fast. - the pci compatibility code forces RF_SHAREABLE, except for fast interrupts it forces !RF_SHAREABLE. This overloads RF_SHAREABLE to mean that the device driver supports sharing. Perhaps this is what RF_SHAREABLE as supplied by drivers should mean. The bus level can match it with shareability actually available and maybe reprogram that shareability to match what the driver prefers. This seems to require more flags for requires/prefer/no_preference/cant_do. Non-shared resources should degrade gracefully to shared ones if a driver that requires shared is attached after a driver that prefers non-shared. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message