Re: A question about hot-pluggable PCI.

• Previous message: Bruce M Simpson: "Re: A question about hot-pluggable PCI."
• In reply to: Bruce M Simpson: "Re: A question about hot-pluggable PCI."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 13 Apr 2005 08:38:53 -0600 (MDT)
To: bms@spc.org

In message: <20050413141336.GA777@empiric.icir.org>
            Bruce M Simpson <bms@spc.org> writes:
: On Mon, Apr 11, 2005 at 11:21:14AM -0600, M. Warner Losh wrote:
: > No we don't. We use what the BIOS provides, but will lazily allocate
: > the BARs as necessary. We don't open the resource windows on the
: > bridges, however.
:
: This 'sorta' works now.
:
: I program a hard-coded window into the PCI bridge behind CardBus. Drivers
: attaching to devices behind the bridge are able to get the ranges they need,
: with the exception of the ATA controller inside the chassis, which I know
: is a special case for PCI.
:
: This of course is a hack which may not work for the !i386 case, as it relies
: on the HUB-PCI bridge behaviour of Intel chipsets, which is to pass all
: transactions across (according to some of the comments in pci_pci.c).

It is possible to make this work without the reliance on the hub-pci
behavior. You have to do things in a heirarchical manner, like I've
been saying...

: It turns out interrupt routing is the problem. I don't think it's possible
: to route an interrupt across CardBus to a downstream PCI bridge in the same
: way as is usually done for PCI-PCI bridges.

Right. CardBus bridges have one interrupt. Period. That's all you
get. Everyone gets it.

: When I added the following, I found drivers attaching to devices inside the
: chassis were able to allocate interrupts and service them:-
:
: %%%
: + if (!strcmp(device_get_name(bus), "cardbus"))
: + intnum = 11; /* Hardcode the IRQ routed to my CardBus bridge */
: + else
: intnum = PCIB_ROUTE_INTERRUPT(device_get_parent(bus), pcib, parent_intpin + 1);
: %%%
:
: ...whereas normally the code was 'routing' IRQ 6 to INTA on the bridge.
: I don't see a pcib_route_interrupt method for pccbb, which is the grandparent
: of the pcib instance I'm attaching. So I check if the devclass of the immediate
: parent is "cardbus".

This is way ugly. Chances are we need to add pcib_route_interrupt to
pccbb to make this less gross. It is almost always a layering
violation to string compare device names... If you find a bug in
other parts of the driver tree, you should fix it there rather than
kludge it in another part...

: This suggests that the code may have been erroneously routing an interrupt
: from 1 level up in the PCI bus hierarchy, which would explain why cbb was
: rejecting drivers downstream asking for IRQ 6 ("my function interrupt is
: IRQ 11, I have no idea what IRQ 6 is, so I'll reject the allocation").
:
: However, it looks as though this doesn't do the right thing just yet, because
: drivers panic on detach when calling bus_release_resource() for their IRQ.

I think that you have to get pccbb to give you the right resource,
rather than kludge around it. The more you kludge, the more you'll
find that you get panics... :-)

: > : I had also thought of passing down a 'cold' flag, for pcibX to indicate to
: > : pciY that this is a 'cold attach' (the BIOS hasn't been anywhere near the
: > : devices behind this bridge -- it is as fresh as after a RST# assert).
: >
: > I don't think that's a wise idea.
:
: Currently, in pcib_attach(), after the call to pcib_attach_common(), I check
: to see if sc->secbus is 0. If it is, I call a new function,
: pcib_attach_cold(), which tries to initialize the bridge as if the BIOS
: had never touched it.

That's closer to ehright thing.

: I imagine some of the code from this effort could be cleaned up and pushed
: back into the tree to support other forms of PCI hot-plug in future.

Some of it sounds like the right thing to do, other parts sound less
wise to push back in :-)

Warner
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

• Previous message: Bruce M Simpson: "Re: A question about hot-pluggable PCI."
• In reply to: Bruce M Simpson: "Re: A question about hot-pluggable PCI."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]