On Mon, 15 Nov 2004, Tim Kelly wrote:

> I've come across a problem in the 2.0RC* obio attachment process that
> seriously affects Macs with two or more I/O controllers. An example
> would be Wallstreet Powerbooks with both Heathrow and Garwick chips.
> Heathrow controls the main bus, Garwick controls the pc card stuff. In
> order to determine how many Macs and users this affects, I am asking
> that list members consult their 2.0RC* dmesgs for the following:

	I can post a full wallstreet/PDQ dmesg but I don't remember there
being any problems with IRQs, my problem is that the pci code doesn't set
up PCI bridges correctly and therefore prevents cardbus from attaching. PR
26508. I don't quite understand why OpenFirmware doesn't set up the
cardbus bridge at power up, but it doesn't.

	The other machines I have are B&W G3, Beige G3, iMac G3 rev A,
iMac DV+ G3 400, and a Sawtooth AGP graphics G4. I'll check them and
report them to you off list as I get access to them.

> two or more obio nodes (obio0 and obio1)
> obio nodes that identify as devices other than 16 (obio0 at pci0 dev 13
> function 0)
> I/O controllers not configured
> devices behind non-primary I/O controllers not working
>
> The core problem is in the manner in which PCI devices are discovered
> and their location in the Open Firmware tree. The obio code assumes that
> the mac-io node will be the only PCI one found and that it will be at
> the top of the OF tree, so that walking the tree picks up the remaining
> devices. For single I/O Macs this is technically correct but not a good
> assumption to make. For multi-I/O controller Macs, it does not properly
> correlate PCI device ID to OF tree location, and the right IRQ will not
> be ascertained.

	Out of curiousity, does the ofppc port do anything different WRT
to PCI bindings to OpenFirmware that we could borrow?