But what the resource.c does does is allocate the address space of the PCI
bus, in this case. If you want your resource controller to manage that
address space, it must control the pci region.
> To give one example (there must be others), for some PCMCIA devices,
> the PCMCIA bus driver constructs an IO region by concatenating several
> bridge IO windows with different functional properties. From the
> hardware perspective, there are several IO resources in play: the
> windows can be configured and released independently. A client driver
> "sees" this as, functionally, just a single block of ports. How
> should this be represented in the resource tree? Does the client
> driver need to know that its one contiguous IO resource was actually
> implemented in a more complicated way by the low level hardware?
I think that the intention here is that the low level driver interacts with
the resource manager. The low level driver may then contruct via IO/remap
a window into the resources it owns, and may then allocate that resource how
it pleases.
If I understand it then, David wants to use the resource control both for
the purpose Linus had in mind, and in order to allocate io-remapped regions
that are constructed by "bus drivers".
bus drivers allocate raw PCI space
construct ioremapped space
export constructed space
device drivers allocate constructed space
Is that right?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/