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]

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