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 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.
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 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 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.
So far this 'kinda' appears to do the right thing; the onboard OHCI controller
gets its resources OK.
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.
BMS
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
