Date: Sat, 07 Jul 2001 16:54:44 -0600 From: Warner Losh <imp@harmony.village.org> To: Peter Wemm <peter@wemm.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, Makoto MATSUSHITA <matusita@jp.FreeBSD.org>, sos@freebsd.dk, current@FreeBSD.ORG Subject: Re: Problems with ata probing twice. Message-ID: <200107072254.f67MsiJ73462@harmony.village.org> In-Reply-To: Your message of "Sat, 07 Jul 2001 14:53:44 PDT." <20010707215344.4B1F2380F@overcee.netplex.com.au> References: <20010707215344.4B1F2380F@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010707215344.4B1F2380F@overcee.netplex.com.au> Peter Wemm writes: : The upshot of this is that drivers should be setting RF_SHAREABLE if they : themselves can handle the possibility that the motherboard is wired up for : sharing their IRQ. It is up to the bus controller to sort out what is : really electrically shareable and what is not... the drivers themselves do : not have this information (and should not be looking for it). I expect : the bus drivers need more work in this area. The more I think about this, the more I don't like it. Very few drivers in the tree (any?) cannot tolerate sharing interrupts. Many want fast interrupts, which does preclude sharing, but that's fundamentally different than just normal sharing. All the drivers in the tree should be able to tolerate being called when in fact there's nothing for the driver to do. While I haven't verified this with each and every driver in the tree, all the ones that I've had occasion to look at or work on work as expected when they are forced to share interrupts. That is, I advocate all busses that support sharing to or in RF_SHAREABLE when appropriate. The trouble is that with the current interfaces, that precludes one from using fast interrupts. FAST or not fast is a property of bus_setup_intr, not bus_alloc_resource. sio is the only driver in the tree using fast interrupts (although there are several not in the tree by third parties that use this) right now, and it treats the INTR_FAST bit as a strong hint only. It is particularly interesting for pccard drivers. On some systems, you can share interrupts (well, likely most of the deployed base at this point). On others, you can't (anything ISA based or laptops P120 or slower)[*]. There are even some pci based laptops that cannot route pci interrupts :-(. One problem with the current pci bus code is that it assumes that if you have a pci attachment, that you must want pci interrupt routing in all cases (which isn't true when some bridges are wired for ISA, the BIOS for the system isn't smart enough to route and we have not bridge driver specifically for that bridge). The bridge is the one that knows, one way or another, if the interrupts are shareable. Warner [*] Even on ISA systems, one can share interrupts to a limited extent. The two pccards could share interrupts (with the right magic programmed on some ISA chipsets). The pccards could share with the CSC interrupt (aka management interupt), but again this requires special magic on some bridges, none on others and isn't supported at all on still others). Some pccard bridge chipsets let you HI-Z IRQ 15 or 14 and thus share them with the IDE controller. I've disallowed all these sharing potentials because you'll notice a fair number of weasel words in the previous sentences (some, might, magic). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107072254.f67MsiJ73462>