Re: [Pcihpd-discuss] RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Thu, 2005-03-31 at 14:03 -0800, Rajesh Shah wrote: > Does this patch help? YES! I can now power down the slot, see it gone from pci list, reenable it, etc. Awesome. Thank you. [EMAIL PROTECTED] ~]# lspci -s 08:00 08:00.0 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03) 08:00.1 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03) [EMAIL PROTECTED] ~]# cd /sys/bus/pci/slots/4/ [EMAIL PROTECTED] 4]# cat power 1 [EMAIL PROTECTED] 4]# echo 0 > power [EMAIL PROTECTED] 4]# lspci -s 08:00 [EMAIL PROTECTED] 4]# cat power 0 [EMAIL PROTECTED] 4]# echo 1 > power [EMAIL PROTECTED] 4]# lspci -s 08:00 08:00.0 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03) 08:00.1 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03) signature.asc Description: This is a digitally signed message part
Re: [Pcihpd-discuss] RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Wed, Mar 23, 2005 at 03:03:16PM -0800, Tom Duffy wrote:
>
> I have updated to Wilcox's rewrite, Rajesh's stuff, and Dely's latest
> patch. Still seeing these:
>
> [EMAIL PROTECTED] ~]# modprobe acpiphp
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> acpiphp: Slot [4] registered
> acpiphp: Slot [3] registered
>
> [EMAIL PROTECTED] ~]# cd /sys/bus/pci/slots/4
>
> [EMAIL PROTECTED] 4]# echo 0 > power
>
> This *does* take this slot off line. Before, I see in lscpi
Note that the current code also attempts to physically eject the
card when you power it off like this.
> After, these are gone.
>
> [EMAIL PROTECTED] 4]# cat power
> 1
>
> Hrm, this should be 0.
>
The code invokes an ACPI _STAtus method to report the power state.
It can get confused if that reports that the device is still
present. The code does keep internal info about the power state
of each slot, but it doesn't use it to report power state.
> [EMAIL PROTECTED] 4]# echo 1 > power
> acpiphp_glue: No new device found
>
If the firmware had a working _EJ0 method for this slot, the
card has been physically ejected.
Does this patch help? It decouples power changes from physical
ejection. With this, you can use the sysfs power control file
to repeatedly power a device on and off. You have to use an
acpi button press to actually physically eject it. Patch
applies on 2.6.12-rc1-mm4 on top of the acpiphp re-write
plus all the other new patches.
---
Current acpiphp code does not distinguish between the physical
presence and power state of a device/slot. That is, if a device
has to be disabled, it also tries to physically ejects the device.
This patch decouples power state from physical presence. You can
now echo to the corresponding sysfs power control file to
repeatedly enable and disable a device without having to
physically re-insert it.
Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---
linux-2.6.12-rc1-mm4-rshah1/drivers/pci/hotplug/acpiphp_glue.c | 69
+-
1 files changed, 38 insertions(+), 31 deletions(-)
diff -puN drivers/pci/hotplug/acpiphp_glue.c~acpiphp-decouple-power-eject
drivers/pci/hotplug/acpiphp_glue.c
---
linux-2.6.12-rc1-mm4/drivers/pci/hotplug/acpiphp_glue.c~acpiphp-decouple-power-eject
2005-03-31 13:10:24.846754032 -0800
+++ linux-2.6.12-rc1-mm4-rshah1/drivers/pci/hotplug/acpiphp_glue.c
2005-03-31 13:12:20.483471366 -0800
@@ -592,8 +592,6 @@ static int power_off_slot(struct acpiphp
acpi_status status;
struct acpiphp_func *func;
struct list_head *l;
- struct acpi_object_list arg_list;
- union acpi_object arg;
int retval = 0;
@@ -615,27 +613,6 @@ static int power_off_slot(struct acpiphp
}
}
- list_for_each (l, &slot->funcs) {
- func = list_entry(l, struct acpiphp_func, sibling);
-
- /* We don't want to call _EJ0 on non-existing functions. */
- if (func->flags & FUNC_HAS_EJ0) {
- /* _EJ0 method take one argument */
- arg_list.count = 1;
- arg_list.pointer = &arg;
- arg.type = ACPI_TYPE_INTEGER;
- arg.integer.value = 1;
-
- status = acpi_evaluate_object(func->handle, "_EJ0",
&arg_list, NULL);
- if (ACPI_FAILURE(status)) {
- warn("%s: _EJ0 failed\n", __FUNCTION__);
- retval = -1;
- goto err_exit;
- } else
- break;
- }
- }
-
/* TBD: evaluate _STA to check if the slot is disabled */
slot->flags &= (~SLOT_POWEREDON);
@@ -782,6 +759,39 @@ static unsigned int get_slot_status(stru
}
/**
+ * acpiphp_eject_slot - physically eject the slot
+ */
+static int acpiphp_eject_slot(struct acpiphp_slot *slot)
+{
+ acpi_status status;
+ struct acpiphp_func *func;
+ struct list_head *l;
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+
+ list_for_each (l, &slot->funcs) {
+ func = list_entry(l, struct acpiphp_func, sibling);
+
+ /* We don't want to call _EJ0 on non-existing functions. */
+ if ((func->flags & FUNC_HAS_EJ0)) {
+ /* _EJ0 method take one argument */
+ arg_list.count = 1;
+ arg_list.pointer = &arg;
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = 1;
+
+ status = acpi_evaluate_object(func->handle, "_EJ0",
&arg_list, NULL);
+ if (ACPI_FAILURE(status)) {
+ warn("%s: _EJ0 failed\n", __FUNCTION__);
+ return -1;
+ } else
+ break;
+ }
+ }
+ return 0
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Mon, 2005-03-21 at 13:27, Greg KH wrote: > On Mon, Mar 21, 2005 at 10:04:57AM -0800, Rajesh Shah wrote: > > > - Are you wanting the acpi specific patches to go into the > tree > > > through the acpi developers? How about the ia64 specific > > > patches? > > > > I honestly don't know what the best approach is here - what do you > > recommend? I did receive an email from Andrew indicating he wants > > to pick these up for the next mm. Perhaps the best thing is to > > let Andrew include the whole series after I've addressed all > > feedback and you, Tony, Len etc. all agree these are OK to go in. > > That sounds like a fine plan to me. Me too. And I don't see any issues with the ACPI specific changes. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pcihpd-discuss] RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Tue, 2005-03-22 at 19:13 -0800, Dely Sy wrote: > I just did a test of Rajesh's latest patch on 2.6.11.5 with > Wilcox's acpiphp rewrite and the following patch. Hot-plug of > PCI Express card worked fine on my i386 system I have updated to Wilcox's rewrite, Rajesh's stuff, and Dely's latest patch. Still seeing these: [EMAIL PROTECTED] 4]# uname -a Linux intlhotp-1 2.6.11andro #5 SMP Wed Mar 23 12:00:56 PST 2005 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]# modprobe acpiphp acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 acpiphp: Slot [4] registered acpiphp: Slot [3] registered [EMAIL PROTECTED] ~]# cd /sys/bus/pci/slots/4 [EMAIL PROTECTED] 4]# echo 0 > power This *does* take this slot off line. Before, I see in lscpi 08:00.0 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03) 08:00.1 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03) After, these are gone. [EMAIL PROTECTED] 4]# cat power 1 Hrm, this should be 0. [EMAIL PROTECTED] 4]# echo 1 > power acpiphp_glue: No new device found There is a card plugged into that slot. Here is some info from the BIOS: [EMAIL PROTECTED] 4]# dmidecode # dmidecode 2.2 SMBIOS 2.3 present. 91 structures occupying 3496 bytes. Table at 0x000FCA80. Handle 0x DMI type 0, 20 bytes. BIOS Information Vendor: American Megatrends Inc. Version: SE7520AF20.86B.P.03.00.0085.092420041113 Release Date: 09/24/2004 Handle 0x0002 DMI type 2, 15 bytes. Base Board Information Manufacturer: Intel Product Name: SE7520AF2HP Version: FRU Ver 0.3 Handle 0x0034 DMI type 9, 13 bytes. System Slot Information Designation: Slot 4 (PCI_Express x8) Type: 64-bit PCI Current Usage: Available Length: Short ID: 3 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Any ideas? Thanks, -tduffy signature.asc Description: This is a digitally signed message part
RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Monday, March 21, 2005 5:07 PM, Dely Sy wrote:
> On Monday, March 21, 2005 10:05 AM, Rajesh Shah wrote:
> > On Fri, Mar 18, 2005 at 09:13:32PM -0800, Greg KH wrote:
> > > - Does this break the i386 acpiphp functionality?
> > Dely Sy had tested hotplug with an earlier version of my patches
> > (with minor differences from the current series) on i386 and it
> > worked fine. She probably hasn't tested the latest one. Dely,
> > could you check that please?
> I tested an earlier version of this patch on my i386 system with
> PCI Express hot-plug slots. The i386 acpiphp functionality worked
> fine - i.e. I was able to do hot-plug of single- & multi-function
> cards.
> I'll check this new patch on my system.
Earlier I reported that Matthew's acpiphp rewrite had problem in
powering down slot on my i386 system. The following patch is
needed to get the acpiphp rewrite properly powering down the slot.
A similar patch was sent out to Matthew for comment and Rajesh
had tested the patch on Tiger4.
I just did a test of Rajesh's latest patch on 2.6.11.5 with
Wilcox's acpiphp rewrite and the following patch. Hot-plug of
PCI Express card worked fine on my i386 system
Thanks,
Dely
Signed-off-by: Dely Sy <[EMAIL PROTECTED]>
diff -urpN linux-2.6.11.5rbha/drivers/pci/hotplug/acpiphp_glue.c
linux-2.6.11.5rbhatst/drivers/pci/hotplug/acpiphp_glue.c
--- linux-2.6.11.5rbha/drivers/pci/hotplug/acpiphp_glue.c 2005-03-22
00:56:04.0 -0800
+++ linux-2.6.11.5rbhatst/drivers/pci/hotplug/acpiphp_glue.c2005-03-22
23:21:23.0 -0800
@@ -586,7 +586,7 @@ static int power_off_slot(struct acpiphp
list_for_each (l, &slot->funcs) {
func = list_entry(l, struct acpiphp_func, sibling);
- if (func->pci_dev && (func->flags & FUNC_HAS_PS3)) {
+ if (func->flags & FUNC_HAS_PS3) {
status = acpi_evaluate_object(func->handle, "_PS3",
NULL, NULL);
if (ACPI_FAILURE(status)) {
warn("%s: _PS3 failed\n", __FUNCTION__);
@@ -601,7 +601,7 @@ static int power_off_slot(struct acpiphp
func = list_entry(l, struct acpiphp_func, sibling);
/* We don't want to call _EJ0 on non-existing functions. */
- if (func->pci_dev && (func->flags & FUNC_HAS_EJ0)) {
+ if (func->flags & FUNC_HAS_EJ0) {
/* _EJ0 method take one argument */
arg_list.count = 1;
arg_list.pointer = &arg;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Monday, March 21, 2005 10:05 AM, Rajesh Shah wrote: > On Fri, Mar 18, 2005 at 09:13:32PM -0800, Greg KH wrote: > > - Does this break the i386 acpiphp functionality? > Dely Sy had tested hotplug with an earlier version of my patches > (with minor differences from the current series) on i386 and it > worked fine. She probably hasn't tested the latest one. Dely, > could you check that please? I tested an earlier version of this patch on my i386 system with PCI Express hot-plug slots. The i386 acpiphp functionality worked fine - i.e. I was able to do hot-plug of single- & multi-function cards. I'll check this new patch on my system. > > - Have you tested other pci hotplug systems with this patch > > series? Like pci express hotplug, standard pci hotplug, > > cardbus, etc? > No, because I the one system I have access to isn't doing any > hot-plug. I'm working on fixing that but was also hoping to hear > from others who surely have access to more machines than I do. PCI Express hot-plug has been tried (see above). The original acpiphp driver won't detect hot-pluggable slots that locate on the p2p bridge (PCI Express to PCI/PCI-X bridge) behind another p2p bridge (root port). Therefore, the acpiphp can't be used for standard PCI hot-plug in my system. Thanks, Dely - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Mon, Mar 21, 2005 at 12:34:07PM -0800, Paul Ionescu wrote: > > --- Rajesh Shah <[EMAIL PROTECTED]> wrote: > > > > No. The current patches only trigger when a _root_ bridge is > > hot-added, not a PCI to PCI bridge (which is what the docking > > station is). The code to support p2p bridge hotplug will benefit > > from these patches but more code is needed to support that. > > > > Thanks for the info. > Is p2p hotplug in your roadmap (for i386) ? > Can you please give me an example of a root bridge ? > I believe others are already working on it. I expect to free up a bit more in a couple of weeks. If I don't see any patches or indication of activity by then, I'll work on adding this support too. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
Hi Rajesh, --- Rajesh Shah <[EMAIL PROTECTED]> wrote: > On Sat, Mar 19, 2005 at 03:50:16PM +0200, Paul Ionescu wrote: > > > > Does this mean that when it will be ported for i386, I will be able to > > really use my Docking Station ? > > No. The current patches only trigger when a _root_ bridge is > hot-added, not a PCI to PCI bridge (which is what the docking > station is). The code to support p2p bridge hotplug will benefit > from these patches but more code is needed to support that. > Thanks for the info. Is p2p hotplug in your roadmap (for i386) ? Can you please give me an example of a root bridge ? Thanks, Paul __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Sat, Mar 19, 2005 at 03:50:16PM +0200, Paul Ionescu wrote: > > Does this mean that when it will be ported for i386, I will be able to > really use my Docking Station ? No. The current patches only trigger when a _root_ bridge is hot-added, not a PCI to PCI bridge (which is what the docking station is). The code to support p2p bridge hotplug will benefit from these patches but more code is needed to support that. > Does it rescan the DSDT to find new additions to ACPI devices ? > It scans the ACPI namespace under the root bridge that was added. Any pci devices underneath are scanned and added, but there isn't any code to look for non-PCI devices there. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Mon, Mar 21, 2005 at 10:04:57AM -0800, Rajesh Shah wrote: > > - Are you wanting the acpi specific patches to go into the tree > > through the acpi developers? How about the ia64 specific > > patches? > > I honestly don't know what the best approach is here - what do you > recommend? I did receive an email from Andrew indicating he wants > to pick these up for the next mm. Perhaps the best thing is to > let Andrew include the whole series after I've addressed all > feedback and you, Tony, Len etc. all agree these are OK to go in. That sounds like a fine plan to me. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Fri, Mar 18, 2005 at 09:13:32PM -0800, Greg KH wrote: > > This all looks very good, nice job. I only had one minor comment on the > patches, which I'll reply to directly. > > But I did have a few questions: > - This series relys on Mathew's rewrite of the acpiphp driver. > Is that acceptable? Is that patch necessary for your work? > And if so, can you include it in the whole series? The last patch (12) in the series is the only one that depends on Matthew's acpiphp rewrite. I do have a really old version of my patch that worked with the original acpiphp code base but this version is cleaner. I could probably resurrect my old patch if you want, but I'd rather prefer to work on and fix any other objections you or others may have with Matthew's re-write, since that's the better overall approach. > - Does this break the i386 acpiphp functionality? Dely Sy had tested hotplug with an earlier version of my patches (with minor differences from the current series) on i386 and it worked fine. She probably hasn't tested the latest one. Dely, could you check that please? The i386 hotplug capable box I have doesn't seem to have the right firmware, so I haven't been able to test hotplug on that (I'm working on fixing that). Of course, I tested my patches on i386 (ACPI as well as non-ACPI) and x86_64 machines to make sure I didn't break boot on those. > - Have you tested other pci hotplug systems with this patch > series? Like pci express hotplug, standard pci hotplug, > cardbus, etc? No, because I the one system I have access to isn't doing any hot-plug. I'm working on fixing that but was also hoping to hear from others who surely have access to more machines than I do. > - Are you wanting the acpi specific patches to go into the tree > through the acpi developers? How about the ia64 specific > patches? I honestly don't know what the best approach is here - what do you recommend? I did receive an email from Andrew indicating he wants to pick these up for the next mm. Perhaps the best thing is to let Andrew include the whole series after I've addressed all feedback and you, Tony, Len etc. all agree these are OK to go in. > - Have the acpi developers agreed with your acpi patches? > This is the first time I sent the patches to the acpi list, so I do need to give them a few days to weigh in. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Fri, 18 Mar 2005 13:38:57 -0800, Rajesh Shah wrote: > Here is a series of patches to support ACPI hot-add of a root bridge > hierarchy. The added hierarchy may contain other p2p bridges and end/leaf > I/O devices too. The root bridge itself is assumed to have been assigned > resource ranges, but the p2p bridges and end devices are not required to > be initialized by firmware. Most of the code changes are to make the > existing code flows suitable for such a hierarchy of bridges & devices. > > This code supports hot-add on ia64 only for now.It does not yet support > I/O APIC hot-add, which is needed to make this fully functional. The > patches are against 2.6.11-mm4 (plus the patch needed for ia64 to boot). > I've tested to make sure this does not break end/leaf device hotplug on > the hotplug capable ia64 box I have. > > Thanks, > Rajesh Does this mean that when it will be ported for i386, I will be able to really use my Docking Station ? Does it rescan the DSDT to find new additions to ACPI devices ? I have an IBM docking station with a PCI bus inside and some other devices, and when I hot plug my IBM ThinkPad T41 in it, it does not recognize those devices. Only if I boot in dock they are usable. And the DSDT is different if I boot in dock or not. So I wander if this patch would help me to hot plug my T41 in the dock and all devices will be recognized. (when the patch will be for i386 too) Thx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Fri, Mar 18, 2005 at 01:38:57PM -0800, Rajesh Shah wrote: > Here is a series of patches to support ACPI hot-add of a root > bridge hierarchy. The added hierarchy may contain other p2p > bridges and end/leaf I/O devices too. The root bridge itself is > assumed to have been assigned resource ranges, but the p2p > bridges and end devices are not required to be initialized by > firmware. Most of the code changes are to make the existing code > flows suitable for such a hierarchy of bridges & devices. > > This code supports hot-add on ia64 only for now.It does not yet > support I/O APIC hot-add, which is needed to make this fully > functional. The patches are against 2.6.11-mm4 (plus the patch > needed for ia64 to boot). I've tested to make sure this does not > break end/leaf device hotplug on the hotplug capable ia64 box I have. This all looks very good, nice job. I only had one minor comment on the patches, which I'll reply to directly. But I did have a few questions: - This series relys on Mathew's rewrite of the acpiphp driver. Is that acceptable? Is that patch necessary for your work? And if so, can you include it in the whole series? - Does this break the i386 acpiphp functionality? - Have you tested other pci hotplug systems with this patch series? Like pci express hotplug, standard pci hotplug, cardbus, etc? - Are you wanting the acpi specific patches to go into the tree through the acpi developers? How about the ia64 specific patches? - Have the acpi developers agreed with your acpi patches? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/Patch 0/12] ACPI based root bridge hot-add
Here is a series of patches to support ACPI hot-add of a root bridge hierarchy. The added hierarchy may contain other p2p bridges and end/leaf I/O devices too. The root bridge itself is assumed to have been assigned resource ranges, but the p2p bridges and end devices are not required to be initialized by firmware. Most of the code changes are to make the existing code flows suitable for such a hierarchy of bridges & devices. This code supports hot-add on ia64 only for now.It does not yet support I/O APIC hot-add, which is needed to make this fully functional. The patches are against 2.6.11-mm4 (plus the patch needed for ia64 to boot). I've tested to make sure this does not break end/leaf device hotplug on the hotplug capable ia64 box I have. Thanks, Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
