Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
> 1.  The way Hayakawa-san's existing CardBus patches bus windows (i.e.,
>     a bus bridge which only provdes access to a subset of the parent's
>     bus-space on the bridged, child bus) is far from great.  I think
>     Jason and i have said much the same idea about how to fix that,
>     tho' we've said it in very different language. Basic idea
>     is to have a bus-space tag keep track of the `window' on the
>     bus in which the tag can acutally allocate space.

It's not clear that 'alloc' is the right mechanism to use anyway.
Read on.


> 2.  Support for CardBus bridge chips which arent initialized properly
>     by BIOSes. We can add support for `known' bridge chips as PCI
>     devices, and configure them, but given the rate-of-change in the
>     PCI world, that may be a losing battle as new bridge chips get
>     introduced way faster than we can do releases.

This is a specific case of a more general problem:

Support for PCI chips which aren't initialized properly by BIOSes.

The "right" (i.e. realistically most likely to produce working
systems) thing to do here is, unfortunately, to do whatever is
necessary to configure PCI devices which aren't properly configured.
By that I mean walk the PCI tree and fill in the BARs and other
registers as necessary.  This isn't an intractable problem; you just
see which header type each device is, and go from there.

Handling of bridges (host, PCI-PCI, or CardBus) is different from that
of normal devices because, basically, you have to bin-pack the
sub-devices' address needs, then figure out how much space to allocate
for the brige, etc.

It's not immediately obvious to me that this can be done automatically
and 'well' with the existing pci code structure, because of the fact
that a 'pci' bus is one single PCI bus, and there's no notion of a
'complete' PCI bus hierarchy.  i suppose you could put a few extra
args in the pci bus attach args struct, to be used only when attaching
the primary...  (Specifically, those args 'want' to be the base and
length of the various regions of PCI space supported by the host
chipset, so the host bus bridge can have the 'right' bin-packing done.)

For each bridge, the constraints of sub-devices can either be mandated
by the existing bridge configuration (because e.g. it's already been
programmed), or can be determined by examining the sub-devices and
then set appropriately when packing the next higher-level bridge.


Doing the address space configuration for a card stuck into a card-bus
bridge after initial configuration is relatively "easy."  You just
have to pack its address requirements into the area provided by/to the
cardbus bridge.  The cardbus bridge has to know to try to reserve
reasonable amounts of space for cards which might be plugged in, as
well.



I'm not working on this, but i can provide input to people who want
to.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.