PCI Hotplug Drivers for 2.5
Quoted 8 lines · Greg KH
Quoted 7 lines · Jeff Garzik
Quoted 4 lines · Greg KH
I think we now all agree that resource management should move into a place where it can be shared by all pci hotplug drivers, right?
If so, anyone want to propose some common code?
Quoted 7 lines
Quoted 3 lines
drivers/pci/setup*is not enough?I am surprised that anything needed to be added here...
There was some reason that code would not work out when I looked at it over a year ago. But I don't remember why, so I'll go look at it again, thanks for pointing it out.
I don't know if you looked at my cPCI driver patch in detail, but it uses the setup-*.c code for all of its resource management. The only things that were really missing in 2.4.x were:
- exports of a few things, most notably pci_scan_bridge
- code to update the resource windows of a newly added bridge (recursively)
- a pci_write_bridge_bases
- PCI resource reservation to allow hot insertion on dumb cPCI hardware
- on x86, the smarts to work back to the root PCI bus to figure out the IRQ pin to use when looking in the pirq table
Since I've been swamped with other stuff, I just started finally porting my cPCI stuff to 2.5 yesterday. :( I think I can get it up and running relatively quickly, but figuring out Ivan's newer hotplug helper code and how to take advantage of it might take me a couple of days.
Scott
Signature · 4 lines
Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: [email protected]
Quoted 3 lines · Scott Murray
I don't know if you looked at my cPCI driver patch in detail, but it uses the setup-*.c code for all of its resource management.
I'm sorry, but I only glanced at it and missed this point.
Quoted 8 lines
The only things that were really missing in 2.4.x were:
- exports of a few things, most notably
pci_scan_bridge
- code to update the resource windows of a newly added bridge (recursively)
- apci_write_bridge_bases
- PCI resource reservation to allow hot insertion on dumb cPCI hardware
- on x86, the smarts to work back to the root PCI bus to figure out the IRQ pin to use when looking in the pirq table
All of these seem like things that should belong in the setup-*.c files for others to use.
Quoted 4 lines
Since I've been swamped with other stuff, I just started finally porting my cPCI stuff to 2.5 yesterday. :( I think I can get it up and running relatively quickly, but figuring out Ivan's newer hotplug helper code and how to take advantage of it might take me a couple of days.
Nice, I was wondering what happened. I'll go dig up your older patch and take a closer look at it.
thanks,
greg k-h
Quoted 6 lines · Greg KH
Quoted 3 lines · Scott Murray
I don't know if you looked at my cPCI driver patch in detail, but it uses the setup-*.c code for all of its resource management.
I'm sorry, but I only glanced at it and missed this point.
No problemo, I kind of vanished off the face of the earth after my last mention of releasing a 2.5 patch, which was over a month and a half ago. Now that we've got our new hardware platform up and running here at SOMA, I'm back in a position to work on hotplug stuff again.
Quoted 11 lines
Quoted 8 lines
The only things that were really missing in 2.4.x were:
- exports of a few things, most notably
pci_scan_bridge
- code to update the resource windows of a newly added bridge (recursively)
- apci_write_bridge_bases
- PCI resource reservation to allow hot insertion on dumb cPCI hardware
- on x86, the smarts to work back to the root PCI bus to figure out the IRQ pin to use when looking in the pirq tableAll of these seem like things that should belong in the setup-*.c files for others to use.
I think Ivan's new code in setup-bus.c (pbus_size_bridges and friends) removes the need for a pci_write_bridge_bases and my code to update the bridge resource windows. I hope so, since I've changed my driver to use it! ;)
Quoted 7 lines
Quoted 4 lines
Since I've been swamped with other stuff, I just started finally porting my cPCI stuff to 2.5 yesterday. :( I think I can get it up and running relatively quickly, but figuring out Ivan's newer hotplug helper code and how to take advantage of it might take me a couple of days.
Nice, I was wondering what happened. I'll go dig up your older patch and take a closer look at it.
I hopefully will have something working against 2.5.44 tomorrow. I think the only potentially contentious piece that I'd like to get reviewed and maybe integrated before the feature freeze is the resource reservation stuff. There seemed to be no serious objections to the 2.4.x version I posted a while back, so maybe this won't be a big deal. Everything else is either __devinit/export tweaks or driver code.
Scott
Signature · 4 lines
Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: [email protected]
Quoted 6 lines · Scott Murray
I hopefully will have something working against 2.5.44 tomorrow. I think the only potentially contentious piece that I'd like to get reviewed and maybe integrated before the feature freeze is the resource reservation stuff. There seemed to be no serious objections to the 2.4.x version I posted a while back, so maybe this won't be a big deal. Everything else is either __devinit/export tweaks or driver code.
The setup-bus code already does resource reservation, but only for cardbus. It can be easily extended for any type of hotplug controller though. Other enhancements (like configurable amount of reserved IO/memory) also shouldn't be a problem.
Also I have a patch (appended) that allows to use pbus_size_bridges() for cardbus bridges (which have different resource layout vs. PCI-to-PCI ones).
BTW, 2.5 setup-* stuff went into 2.4 recently. :-)
Ivan.
drivers/pci/setup-res.c +1 -1
@@ -137,7 +137,7 @@ pci_assign_resource(struct pci_dev *dev, }/* Sort resources by alignment */ -void __init +void __devinit pdev_sort_resources (struct pci_dev *dev,struct resource_list *head) {int i;
drivers/pci/setup-bus.c +45 -21
142 lines not on this page · raw message
Quoted 8 lines · Ivan Kokshaysky
Quoted 6 lines · Scott Murray
I hopefully will have something working against 2.5.44 tomorrow. I think the only potentially contentious piece that I'd like to get reviewed and maybe integrated before the feature freeze is the resource reservation stuff. There seemed to be no serious objections to the 2.4.x version I posted a while back, so maybe this won't be a big deal. Everything else is either __devinit/export tweaks or driver code.
Quoted 4 lines
The setup-bus code already does resource reservation, but only for cardbus. It can be easily extended for any type of hotplug controller though. Other enhancements (like configurable amount of reserved IO/memory) also shouldn't be a problem.
Unfortunately, my take on the scheme used to reserve space for CardBus bridges was that it only works on platforms that use the setup-*.c code to do their complete PCI subsystem initialization. On platforms like x86, where the BIOS configures all the devices, something like my patch is needed to fixup things to handle the desired reservation. I'm not finished getting things ported to 2.5 yet, I'll post a patch ASAP once I've got everything workin. If you're keen on devising an alternative method, check put my old patch against 2.4.19 at:
http://marc.theaimsgroup.com/?l=linux-kernel&m2866931731553&w=2
[snip]
Quoted 1 line
BTW, 2.5 setup-* stuff went into 2.4 recently. :-)
Cool, that definitely will make my life easier.
Thanks,
Scott
Signature · 4 lines
Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: [email protected]
Quoted 8 lines · Scott Murray
Unfortunately, my take on the scheme used to reserve space for CardBus bridges was that it only works on platforms that use the setup-*.c code to do their complete PCI subsystem initialization. On platforms like x86, where the BIOS configures all the devices, something like my patch is needed to fixup things to handle the desired reservation. I'm not finished getting things ported to 2.5 yet, I'll post a patch ASAP once I've got everything workin. If you're keen on devising an alternative method, check put my old patch against 2.4.19 at:
I've been working on this in 2.5 this week - I've got something working, Alan's happy with the concept as far as the resource allocation goes.
The cardbus reservation method is actually flawed in setup-*.c if you want to get rid of the stuff in yenta.c - again, I've fixed this lot in my 2.5 tree already, and the patch is pending an update to the x86 code to do what yenta.c was doing (only setup bridge resources of the ones already programmed are bad/wrong.)
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 10 lines · Russell King
Quoted 8 lines · Scott Murray
Unfortunately, my take on the scheme used to reserve space for CardBus bridges was that it only works on platforms that use the setup-*.c code to do their complete PCI subsystem initialization. On platforms like x86, where the BIOS configures all the devices, something like my patch is needed to fixup things to handle the desired reservation. I'm not finished getting things ported to 2.5 yet, I'll post a patch ASAP once I've got everything workin. If you're keen on devising an alternative method, check put my old patch against 2.4.19 at:
Quoted 8 lines
I've been working on this in 2.5 this week - I've got something working, Alan's happy with the concept as far as the resource allocation goes.
The cardbus reservation method is actually flawed in setup-*.c if you want to get rid of the stuff in
yenta.c- again, I've fixed this lot in my 2.5 tree already, and the patch is pending an update to the x86 code to do whatyenta.cwas doing (only setup bridge resources of the ones already programmed are bad/wrong.)
This sounds like it could remove the need for my manually specified resource reservation scheme, does your code currently support arbitrary bridges, i.e. non-CardBus?
Thanks,
Scott
Signature · 4 lines
Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: [email protected]