Re: A question about hot-pluggable PCI.
In message: <[EMAIL PROTECTED]>
Bruce M Simpson <[EMAIL PROTECTED]> 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 "[EMAIL PROTECTED]"
Re: A question about hot-pluggable PCI.
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]"
Re: A question about hot-pluggable PCI.
In message: <[EMAIL PROTECTED]> Bruce M Simpson <[EMAIL PROTECTED]> writes: : On Mon, Apr 11, 2005 at 07:25:07AM -0600, Scott Long wrote: : > Asking for 'hotplug support' is pretty generic and non-descriptive. Are : > you asking for device level hotplug support, where we carefully drain : > transactions out of a device, device driver, and whatever I/O or network : > or whatever layers are above it? Or are you talking about PCI hotplug : > support? If so, which de-facto standard? Compaq? IBM? ACPI? : > PCI-SIG? Something else? : : Sorry, I thought my original post was quite clear; in order to support : my hot-pluggable PCI chassis, FreeBSD needs to grow the ability to manage : PCI resources without any firmware support (other than possibly the ability : to route interrupts). Since I sent that mail I looked at the requirements : list for 5-STABLE and realized this is in fact on it. The trouble is that 'Hot Plug' pci is a semi-standardized thing. That's why people are confused. :-) You want to plug in a new PCI bus, while most people consider hot-plug PCI a way to replace cards in a running system. : I looked in src/sys/dev/cardbus/cardbus_cis.c, and Linux's ACPI-based PCI : hotplug driver, and realised that at the lowest level, they are all in fact : pretty much doing the same thing -- that is, setting all bits in a BAR, and : then figuring out the desired aperture size for each BAR, allocating the : appropriate resources using rman, figuring out base addresses, etc. Yup. : We currently rely on the BIOS to do this. The bit I've been discussing with : Warner is how to deal with the problem of setting subordinate bus numbers, : though because I can get away without doing that for the 'pcib is an immediate : child of cardbus' case, I haven't done it. 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. : 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. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A question about hot-pluggable PCI.
On Mon, Apr 11, 2005 at 07:25:07AM -0600, Scott Long wrote: > Asking for 'hotplug support' is pretty generic and non-descriptive. Are > you asking for device level hotplug support, where we carefully drain > transactions out of a device, device driver, and whatever I/O or network > or whatever layers are above it? Or are you talking about PCI hotplug > support? If so, which de-facto standard? Compaq? IBM? ACPI? > PCI-SIG? Something else? Sorry, I thought my original post was quite clear; in order to support my hot-pluggable PCI chassis, FreeBSD needs to grow the ability to manage PCI resources without any firmware support (other than possibly the ability to route interrupts). Since I sent that mail I looked at the requirements list for 5-STABLE and realized this is in fact on it. I think there's a fair chance that any other PCI hotplug standard is going to need the same changes I need to make my split bridge work. I looked in src/sys/dev/cardbus/cardbus_cis.c, and Linux's ACPI-based PCI hotplug driver, and realised that at the lowest level, they are all in fact pretty much doing the same thing -- that is, setting all bits in a BAR, and then figuring out the desired aperture size for each BAR, allocating the appropriate resources using rman, figuring out base addresses, etc. We currently rely on the BIOS to do this. The bit I've been discussing with Warner is how to deal with the problem of setting subordinate bus numbers, though because I can get away without doing that for the 'pcib is an immediate child of cardbus' case, I haven't done it. 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). That's enough for me to be getting on with just now, though it would be nice to have some general architectural advice on where exactly this logic should go, because it's something cardbus is using to mop up the edge cases where device resources are not fully described in the CIS. I am undecided as to whether I should try to separate out my changes to src/sys/dev/pci/pci_pci.c into a new driver or not. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A question about hot-pluggable PCI.
Bruce M Simpson wrote: Hi, I have acquired a Mobility Electronics EasiDock 5000. As some of you may already know, this is a device which allows you to connect regular PCI cards to your laptop, using a device called a 'Split Bridge'. (*) Ok. Cool toy, you may be thinking. Indeed. But I want to make it work with FreeBSD. (+) I'd love to hear from anyone who has plans to implement hot-plug in a BSD, because this is the missing piece of the puzzle currently. It seems that this device is known to work with Linux, with some further hacking of support which Magma (who acquired Mobility a few years back) provide on a 'as is' basis. So I've begun hacking the pci and pcib drivers from RELENG_5_4 to support this device. So far, I've been able to probe configuration space. I see all the devices on the PCI bus inside the expansion chassis. However I cannot get drivers to attach properly, because resources have not been assigned to the cards. Normally the BIOS would do this. But because BIOSes do not normally explore beyond the CardBus bridges, none of the devices have had their I/O, memory, or interrupt registers set to non-default values; everything is the same as a pristine bus reset, even when I boot with the bridge card in a CardBus slot. In order to get this far I've had to add NEWBUS detach methods to both pci and pcib, as well as some cleanup in pci_pci.c, and some downright dirty hacks to deal with subordinate bus numbering which rely on the current behaviour of our CardBus driver. I'll post diffs if anyone else is interested; but right now it's pretty trivial stuff. Asking for 'hotplug support' is pretty generic and non-descriptive. Are you asking for device level hotplug support, where we carefully drain transactions out of a device, device driver, and whatever I/O or network or whatever layers are above it? Or are you talking about PCI hotplug support? If so, which de-facto standard? Compaq? IBM? ACPI? PCI-SIG? Something else? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A question about hot-pluggable PCI.
Hi, I have acquired a Mobility Electronics EasiDock 5000. As some of you may already know, this is a device which allows you to connect regular PCI cards to your laptop, using a device called a 'Split Bridge'. (*) Ok. Cool toy, you may be thinking. Indeed. But I want to make it work with FreeBSD. (+) I'd love to hear from anyone who has plans to implement hot-plug in a BSD, because this is the missing piece of the puzzle currently. It seems that this device is known to work with Linux, with some further hacking of support which Magma (who acquired Mobility a few years back) provide on a 'as is' basis. So I've begun hacking the pci and pcib drivers from RELENG_5_4 to support this device. So far, I've been able to probe configuration space. I see all the devices on the PCI bus inside the expansion chassis. However I cannot get drivers to attach properly, because resources have not been assigned to the cards. Normally the BIOS would do this. But because BIOSes do not normally explore beyond the CardBus bridges, none of the devices have had their I/O, memory, or interrupt registers set to non-default values; everything is the same as a pristine bus reset, even when I boot with the bridge card in a CardBus slot. In order to get this far I've had to add NEWBUS detach methods to both pci and pcib, as well as some cleanup in pci_pci.c, and some downright dirty hacks to deal with subordinate bus numbering which rely on the current behaviour of our CardBus driver. I'll post diffs if anyone else is interested; but right now it's pretty trivial stuff. Cheers, BMS [(*) It is so called because unlike a normal PCI-PCI bridge, the bridge is 'split' in two; there is a CardBus card which goes into your laptop, to which is connected a proprietary high-speed serial bus cable. At the other end is a PCI chassis which looks much like any other desktop PC, which has a jack for the proprietary connector out of the back, wired up to the other half of the 'split bridge'; this sits on a passive PCI backplane with several ordinary 33Mhz 32-bit-wide PCI slots.] [(+) Yes, I know, if OpenCores.org had a PCI IEEE 1394 cell which could just tunnel arbitrary PCI I/O and configuration transactions, we could implement this thing using $20 cards from a chain store. If only.] pgpQ9Kdjbhr1U.pgp Description: PGP signature
