Date: Thu, 18 May 2000 17:32:06 -0600 From: Warner Losh <imp@village.org> To: Alexander Langer <alex@big.endian.de> Cc: doc@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: request for review: bus_alloc_resource(9) Message-ID: <200005182332.RAA97696@harmony.village.org> In-Reply-To: Your message of "Thu, 18 May 2000 22:38:46 %2B0200." <20000518223846.A16098@cichlids.cichlids.com> References: <20000518223846.A16098@cichlids.cichlids.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Some problems. Here's my comments. I'm posting them in case my understanding is inaccurate. If it is, I don't want you to codify it. And I want to know so I don't keep misunderstanding :-) First, rid. "rid" is a bus specific handle that identifies the resource being allocated. For ISA this is an index into an array of resources that have been setup for this device by either the PnP mechanism, or via the hints mechanism. For PCCARD, similar things are used, but that may change in the future with newcard. For PCI it just happens to be the offset into pci config space which has a word that describes the resource. Who knows what it will be for other things. Second, RF_SHAREABLE should generally never be used. There's one exception. That's for interrupts that can be shared in the hardware. PCI bus is the only bus that does this reliably. Since the PCCARD bus can be bridged to the ISA bus or to PCI bus, you can't reliably share interrupts there. ISA bus interrupts cannot be shared (well, unless you have custom hardware or hack stock hardware, but if you are doing that, then you know what you are doing). Memory resources, ioport resources, etc are not usually shared between devices. There are lots of bus issues with doing that when you have a driver for multiple hungs of hardware. There are exceptions ot that, but not enough to be worth messing with. The dev parameter is the device requesting ownership, and optional activation of this resource. The parent, or its parent, owns the resource until it is delegated to this device. [[ as an aside, this is generally only done in the nexus, but may be done in pccard in the future ]]. When default values are used for start and end, then the count parameter may be ignored and the amount of resource specified by the bus, or the hints mechanism, is used instead of the vaule passed in. This is why you often see '1'. RF_ACTIVE doesn't need to be set. Once can reserve the resource before activating it. RF_ACTIVATE doesn't mean that the device has been activated, but rather that the bus_activate_resource() method should be called to cause the resource to become active. This isn't important on the ISA bus since resources are always active (even in the PnP model). For other buses, this may cause the bus bridges to make the resources actually available. The bus methods are free to change the RIDs that are passed to it. That's why it is a pointer. Many devices in the tree blindly assume that htis isn't the case and do not store the rids for later freeing. Bus interfaces may change in the future which might cause changes to happen where they don't happen today. Think of rids a a well defined cookie. One cookie may be a meta-cookie that causes the real cookie to be returned. Generally, one should mirror one's allocate and release calls. A technique that works well is to set the rid/res in a softc structure and then have the detach function automatically free these resources. This allows one to call, manually, the detach function when the attach fails. One should generally only call these functions in attach. If you must call them in probe, one must release the resource before returning from the probe. However, since they can affect bridge settings, it may be unavoidable to call them from the probe routine. There's no published interface that allows a probe/identify routine to ask if a range of addresses are in use. This generally only bites those busses which aren't self identifying. Currently the ISA bus is the only bus we support that isn't self identifying. PnP helps, but when you are trying to deal with legacy hardware that doesn't support PnP it can get gross. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005182332.RAA97696>