>In fact, we _do_ support (some) EISA boards via ISA.  Pop in an EISA
>VGA card, and you'll get an ISA vga attachment.  8-)

Oh. well, vga was always a special-case hack :)

>The point with that was that the PCI bus space management/"bin
>packing" has to be done anyway before cardbus support is done, and
>doing it first means that people who currently have no working PCMCIA
>support get it immediately.  I.e. shuffle to get quicker result.  8-)

just to make sure I grok this:

The people who dont even have PCMCIA support are stuck there because
their BIOS isnt initializing their bridge (whether pcic or cbb). to
cure that, we need not just bin-packing, but code to initialize the
pcic/cbb and/or map its register BAR. Which may mean grovelling
around PCI attribute space.  Right?

And the `bin packing' isnt solely figuring out how much space to
allocate. its also providing support to the child devices (attached
via pcicma? or cardbus?)  so that when their attach functions get
called, they can allocate space within the corect window, as seen by
the parent. Right? Or am I misunderstanding?


>However, if working on other things leads to results, let it show up
>when it shows up.

Sure. But I thought Jason said he'd take on part of what you call
`binpacking'.  

That stilll leaves adding code to refrob unitialized CBBs so that
their BARs are visible and (bletch) maybe turning on the PCMCIA-compat-access,
if it isn't on (is that what you meant by "get support immediately??)
can be done in parallel.

E.g., a derivative of sys/dev/pci/i82365_pci.c, except that it'd match
based on class and subclass, and enable PCI BAR registers if
unmapped,, and enable the PCMCIA-compat mode. Is that what you meant
by ``immediate support'' for pcmcia, or was it something else again?