Date: Sun, 14 Jan 2001 23:24:12 -0700 From: Warner Losh <imp@harmony.village.org> To: Robert Lipe <robertlipe@usa.net> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: bus_alloc_resource and RF_SHARABLE Message-ID: <200101150624.f0F6OCs15404@harmony.village.org> In-Reply-To: Your message of "Sun, 14 Jan 2001 00:44:53 CST." <20010114004453.D20766@rjlhome.sco.com> References: <20010114004453.D20766@rjlhome.sco.com> <200101131529.f0DFTps26367@aslan.scsiguy.com> <200101140356.f0E3uos95880@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010114004453.D20766@rjlhome.sco.com> Robert Lipe writes: : I can't say I gather that from the man page from bus_alloc_resource : at all. The restriction of RF_SHAREABLE applying only to IRQs and : the exclusive nature of this call (one per BAR) would be helpful to : call out in the doc. We should. : Just so I'm completely clear on this though, the intent is that multiple : bus_alloc_resource calls for a single BAR within a single driver is : explictly prohibited, right? So if I want to map ONLY the first byte : and the last byte of, say, a 16MB PCI BAR, I have to map the whole : thing, use the same resource handle for everything, and give up any : potential address space/vm protection afforded by having the middle : unmapped, right? Right now BARs can be only mapped once. If you have a physical device that is serviced by a bunch of sub-devices, you'll need to cope by providing that functionality in a "bridge" driver. I'm working on this for my NetBSD puc driver port. Warner P.S. The PUC driver is for serial and parallel pci cards that have a bazillion ways of gluing N 16550A UARTs and M PPCs with 1 or more BARs. The "multiplexing" of the BARs has to happen in the puc layer for sio and ppc attachments to work. 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?200101150624.f0F6OCs15404>