PLEASE REVIEW: Adding a pci_if method to facilitate specialized PCI bus drivers

[John Baldwin]

On 27-Jun-2003 Thomas Moestl wrote:
> On Fri, 2003/06/27 at 14:01:45 -0400, John Baldwin wrote:
>> On 27-Jun-2003 Thomas Moestl wrote:
>> > On Fri, 2003/06/27 at 13:37:00 -0400, John Baldwin wrote:
>> >> On 13-Jun-2003 Thomas Moestl wrote:
>> >> > This requires us to get this firmware property in the OFW PCI bus
>> >> > driver before routing the interrupt; that can't be done in the pcib
>> >> > route_interrupt method, since we don't know whether we are routing for
>> >> > another bridge (where we use whichever index we get passed) or for a
>> >> > child device (in which case we would need to look at the firmware
>> >> > property).
>> >> 
>> >> Actually, can't you tell this by doing:
>> >> 
>> >>         if (device_get_parent(device_get_parent(dev)) == pcib)
>> >>                 /* Routing direct child. */
>> >>         else
>> >>                 /* Routing descedent of a child bridge. */
>> > 
>> > No, pcib will always be a grandparent of dev. When routing a
>                                                             ^ for 
>> > descendant child bridge, dev will itself be the device_t of a bridge,
>               ^ of a (oops)
>> > otherwise it is that of the device we are routing to.
>> Doh, yes. :(  Hmm, can you try something like this maybe:
>> 
>>         if (pci_get_class(dev) == PCIC_BRIDGE &&
>>             pci_get_subclass(dev) == PCIS_BRIDGE_PCI)
>>                 /* Routing across a child bridge. */
>>         else
>>                 /* Routing a direct child that is not a bridge. */
> 
> This leaves two possible problems: first, there are other types of
> bridges (we currently support PCI-ISA and PCI-EBus ones, cardbus might
> also work) for which we need to use PCIB_ROUTE_INTERRUPT(); that could
> likely be dealt with by not testing the subclass at all.
> More importantly, however, a bridge might want to allocate an
> interrupt for itself; for example, cardbus bridge drivers do this to
> handle insertion/ejection/etc events.
> 
> I think that handling this at the bus driver level is a much cleaner
> solution.

Then should we eliminate pcib_route_interrupt() and make it a PCI bus
method?  I just think it is rather odd to require this interface to be
duplicated in two different places.  Doing it in the bus might actually
make life simpler.  Right now when using different tables for routing
PCI interrupts on x86, I have to write two different bridge drivers all
the time, one for host bridges and one for PCI-PCI bridges, thus we have
ACPI host-PCI and PCI-PCI bridge drivers, PCIBIOS $PIR host-PCI and PCI-PCI
bridge drivers and MPTable host-PCI and PCI-PCI bridge drivers.  Being
able to just have an ACPI PCI bus driver, a PCIBIOS PCI bus driver, and
an MPTable PCI bus driver would be nice.   However, I am curious what
pushing this down into the bus layer buys you.  Do you have the sparc64
PCI bus and PCI bridge drivers up somewhere?

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/