PCI hotplug broken on IA64
Quoted 5 lines
I don't think the current way of accessing PCI configuration space with temporary
pci_devandpci_busis definitive answer but we are depending on it now.
Could someone enlighten me?
Any ideas?
All pci config space access before pci_dev/pci_bus are built should be able to make direct call to pci_config_{read|write}(seg, bus, dev, func, offset, size, value).
Thanks,
J.I.
Quoted 10 lines · Jung-Ik
Quoted 6 lines
I don't think the current way of accessing PCI configuration space with temporary
pci_devandpci_busis definitive answer but we are depending on it now.
Could someone enlighten me?
Any ideas?All pci config space access before pci_dev/pci_bus are built should be able to make direct call to pci_config_{read|write}(seg, bus, dev, func, offset, size, value).
Um, where are these functions exported? I don't see them in the 2.4 tree :)
thanks,
greg k-h
Quoted 6 lines · Takayoshi
Hi,
The PCI segment support which was introduced at 2.4.19-020821 ia64 patch broke PCI hotplug core driver. The way ia64 port does is using ia64 specific '
pci_controller' structure, embedding a segment number in it and makingpci_bus->sysdatapoint to the structure.
Yes, Chris McDermott just sent me a patch much like this one a few days ago.
Quoted 10 lines
All config space access functions refer to the structure so if
pci_controllerstructures are not setup correctly, all pci configuration space acesss will fail.I don't think the current way of accessing PCI configuration space with temporary
pci_devandpci_busis definitive answer but we are depending on it now.Could someone enlighten me?
Any ideas?
The correct thing to do is do what we did in 2.5. There is no more *_nodev functions, as we changed the pci_ops structure. Even when segment support goes into 2.5, the pci hotplug code should not care at all.
That being said, I don't think the huge pci_ops change would be a good thing to do right now in 2.4. I also do not want to be forced to add the segment value to the *_nodev functions, as that is just getting too messy.
Maybe a backport of the pci_ops changes is the best thing to do...
Any other ideas?
thanks,
greg k-h
Quoted 8 lines · Greg KH
Quoted 7 lines · Jung-Ik
Quoted 6 lines
I don't think the current way of accessing PCI configuration space with temporary
pci_devandpci_busis definitive answer but we are depending on it now.
Could someone enlighten me?
Any ideas?
Quoted 6 lines
Quoted 3 lines
All pci config space access before pci_dev/pci_bus are built should be able to make direct call to pci_config_{read|write}(seg, bus, dev, func, offset, size, value).
Um, where are these functions exported? I don't see them in the 2.4 tree :)
Ok, just to make myself clear, yes I know the functions are there, but no, they are not explicitly exported, or supported on all archs.
thanks,
greg k-h
Quoted 14 lines · Greg KH
Quoted 3 lines · Jung-Ik
Quoted 2 lines
Quoted 2 lines
I don't think the current way of accessing PCI
configuration space
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
with temporary
pci_devandpci_busis definitive answer but we are depending on it now.
Could someone enlighten me?
Any ideas?All pci config space access before pci_dev/pci_bus are built should be able to make direct call to pci_config_{read|write}(seg, bus, dev, func, offset, size, value).
Quoted 6 lines
Quoted 2 lines
Um, where are these functions exported? I don't see them in the 2.4 tree :)
Ok, just to make myself clear, yes I know the functions are there, but no, they are not explicitly exported, or supported on all archs.
Hotplug drivers in drivers/hotplug are for Intel architecture, and the above APIs are available as global for both i386 and ia64. Actually, acpi driver uses them for ACPI/PCI population before pci_dev is built for the hierarchy.
thanks,
J.I.
Quoted 3 lines · Jung-Ik
Hotplug drivers in
drivers/hotplugare for Intel architecture, and the above APIs are available as global for both i386 and ia64.
Right now they are, but I have seen drivers for other architectures, and can not change the pci hotplug core to rely on a ia64 and i386 only solution, sorry. Hopefully those other drivers will be in the main tree soon.
Quoted 2 lines
Actually, acpi driver uses them for ACPI/PCI population before
pci_devis built for the hierarchy.
Yes, but acpi is only on ia64 and i386 platforms right now. And for 2.5 I got rid of that usage :)
thanks,
greg k-h
Quoted 9 lines · Greg KH
Quoted 3 lines · Jung-Ik
Hotplug drivers in
drivers/hotplugare for Intel architecture, and the above APIs are available as global for both i386 and ia64.Right now they are, but I have seen drivers for other architectures, and can not change the pci hotplug core to rely on a ia64 and i386 only solution, sorry. Hopefully those other drivers will be in the main tree soon.
I'm hopeful we'll see a bunch of drivers for various non-x86 CompactPCI CPU boards appear if my CompactPCI driver goes in. If I get the time, I'll probably take the required bits for the Motorola PowerPC boards from the code MontaVista released a while back and build something for them myself.
By the way, Greg, are you interested in patches against 2.5.45, even with the device unregistration stuff still up in the air? Barring that and waiting to see what Russell and Alan are cooking up for PCI resource reservation, I'm kind of doneish my port to 2.5.
Scott
Signature · 4 lines
Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: [email protected]
Quoted 6 lines · Scott Murray
I'm hopeful we'll see a bunch of drivers for various non-x86 CompactPCI CPU boards appear if my CompactPCI driver goes in. If I get the time, I'll probably take the required bits for the Motorola PowerPC boards from the code MontaVista released a while back and build something for them myself.
Sounds good, further reinforcement of the "no i386 and ia64 only" restrictions on the pci hotplug core :)
Quoted 4 lines
By the way, Greg, are you interested in patches against 2.5.45, even with the device unregistration stuff still up in the air? Barring that and waiting to see what Russell and Alan are cooking up for PCI resource reservation, I'm kind of doneish my port to 2.5.
Yes I am, please send them on.
thanks,
greg k-h
Quoted 10 lines · Greg KH
Quoted 6 lines · Scott Murray
I'm hopeful we'll see a bunch of drivers for various non-x86 CompactPCI CPU boards appear if my CompactPCI driver goes in. If I get the time, I'll probably take the required bits for the Motorola PowerPC boards from the code MontaVista released a while back and build something for them myself.
Sounds good, further reinforcement of the "no i386 and ia64 only" restrictions on the pci hotplug core :)
Considering the wide variety of cPCI CPU boards that are floating around, and the non-zero chance that someone here at SOMA will decide out of the blue they want us to use a non-x86 one, I'm keen to hedge my bets. :)
Quoted 6 lines
Quoted 4 lines
By the way, Greg, are you interested in patches against 2.5.45, even with the device unregistration stuff still up in the air? Barring that and waiting to see what Russell and Alan are cooking up for PCI resource reservation, I'm kind of doneish my port to 2.5.
Yes I am, please send them on.
There are a couple of things I want to test at the office tomorrow, I'll send something on after I'm sure they work.
Scott
Signature · 4 lines
Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: [email protected]
Quoted 4 lines · Greg KH
Right now they are, but I have seen drivers for other architectures, and can not change the pci hotplug core to rely on a ia64 and i386 only solution, sorry. Hopefully those other drivers will be in the main tree soon.
yep, at some point i hope to find docs on Elroy's hotplug controller for PA-RISC.
Signature · 1 line
Revolutions do not require corporate support.