In message: <[EMAIL PROTECTED]>
Thomas Moestl <[EMAIL PROTECTED]> writes:
: On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote:
: > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200:
: > > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote:
: > > There's a similar problem with hme devices in some Netra models, and
: > > so far I have just ignored this because of the ugliness involved
: > > (there were patches floating around at one point, but I did not commit
: > > them).
: > >
: > > The real fix (and the way I wanted to implement things from the
: > > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This
: > > is high on my list, waiting for time to become available :)
: >
: > Yikes, I just started looking at the acpi code, and there's a lot of
: > code in it!
:
: There's much setup to be done that the firmware is too lazy to do for
: us.
:
: > > > Is this why pciconf -r is returning 0xffffffff when reading the ebus
: > > > and firewire parts of the SME2300BGA? Simply because it isn't in
: > > > the ofw tree?
: > >
: > > Could be. We just cannot handle devices without firmware nodes - we
: > > don't know whether we can safely access them, cannot assign interrupts
: > > etc.
: >
: > Ok, the only problem is that is then we have the same problem the ACPI
: > code does in that hot swapping cards would have a problem. Since it
: > appears to me that the OFW tree doesn't get updated upon a swap. (At
: > least the usb part of the tree doesn't.)
:
: We do not support hotplugging at the moment anyway. If a bridge driver
: would implement that in the future without using any firmware support
: however, it will then need to know everything information about the
: interrupt routing required for its devices if it cannot use the
: firmware for this. in that case, it can just prevent the ofw_pci bus
: from attaching to it (this will be easily possible).
: I'd hope that machines that support hot-plugging of PCI devices would
: have firmware methods available to support that though.
We'll need to do so for the cardbus bridges. However, the interupt is
routed to the bridge and has to be shared with the cardbus/pccard
cards.
: > Does this mean that we should eliminate most of the Sun specific pci
: > bus drivers in favor of OFW specific ones like ACPI? or?
:
: No, it means introducing an OFW bus driver, which uses the firmware to
: enumerate the devices and to support interrupt routing. The bridge
: drivers would be mostly unaffected by this.
: The only problem with this approach is that it can change the device
: enumeration; I hope that the resulting one will be the same one that is
: printed on the boxen, so it should be advantageous for new
: installations, but a minor migration problem for old ones.
:
: I've got some code for this already, it just isn't done yet.
So are you talking about doing something akin to the acpi bridge code
or something else? Would this more properly be called a OFW PCI bus
driver, or would the OFW 'bus' reach over into other busses to add
children?
Warner
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
