svn commit: r300548 - in head/sys: conf dev/bhnd dev/bhnd/bhndb dev/bhnd/cores/chipc dev/bhnd/nvram dev/bhnd/siba modules/bhnd modules/bhnd/cores/bhnd_chipc
John Baldwin
jhb at freebsd.org
Tue May 24 03:21:47 UTC 2016
On Tuesday, May 24, 2016 01:12:19 AM Adrian Chadd wrote:
> Author: adrian
> Date: Tue May 24 01:12:19 2016
> New Revision: 300548
> URL: https://svnweb.freebsd.org/changeset/base/300548
>
> Log:
> [bhnd] Implement pass-through resource management for ChipCommon.
>
> This patchset adds support to bhnd_chipc for sharing SYS_RES_MEMORY
> resources with its children, allowing us to hang devices off of
> bhnd_chipc that rely on access to a subset of the device register space
> that bhnd_chipc itself must also allocate.
>
> We could avoid most of this heavy lifting if RF_SHAREABLE+SYS_RES_MEMORY
> wasn't limited to use with allocations at the same size/offset.
>
> As a work-around, I implemented something similar to vga_pci.c, which
> implements similar reference counting of of PCI BAR resources for its
> children.
>
> With these changes, chipc will use reference counting of SYS_RES_MEMORY
> allocation/activation requests, to decide when to allocate/activate/
> deactivate/release resources from the parent bhnd(4) bus.
>
> The requesting child device is allocated a new resource from chipc's
> rman, pointing to (possibly a subregion of) the refcounted bhnd resources
> allocated by chipc.
>
> Other resource types are just passed directly to the parent bhnd bus;
> RF_SHAREABLE works just fine with IRQs.
>
> I also lifted the SPROM device code out into a common driver, since this
> now allows me to hang simple subclasses off of a common driver off of both
> bhndb_pci and bhnd_chipc.
Hmm, what the PCI-PCI bridge driver does with NEW_PCIB is to allocate a single
resource from its parent bus for each I/O window it decodes. It then creates
a rman that is populated with the addresses in that resource and suballocates
from that rman. This allows child devices to allocate non-overlapping resources
exclusively (they could also do shareable mappings for subsets if applicable).
Right now NEW_PCIB assumes it can pass one of these "child" resources up to the
nexus to have it "mapped" via bus_activate_resource(). However, the recently
added bus_map_resource() provides a cleaner way to do this where a bridge device
can request a mapping for the sub-range of the resource on its "upstream"
side that corresponds to the range used by a resource for a child device.
--
John Baldwin
More information about the svn-src-all
mailing list