| Message ID | 1250666651.23178.116.camel@sli10-desk.sh.intel.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Wed, Aug 19, 2009 at 03:24:11PM +0800, Shaohua Li wrote: > Usually driver should does nothing in the op as bus can handle it. But in some > cases, like pci bus, UHCI controller doesn't use standard PME registers for > wakeup, instead of using special approach. In this case, UHCI controller driver > should implement this op. I'm not averse to the general concept, but I'm not entirely sold on it being necessary. All the hardware I'm aware of will send non-PME events as a notification on a specific device. Under what circumstances will we get a wakeup GPE for a non-PME device without knowing which device should be woken?
On Wed, 19 Aug 2009, Shaohua Li wrote: > Introduce .wakeup_event(). When a device gets a wakeup event, > the callback is called. The callback usually should check if the device > really invokes wakeup event and disable wakeup event if yes. > > Usually driver should does nothing in the op as bus can handle it. But in some > cases, like pci bus, UHCI controller doesn't use standard PME registers for > wakeup, instead of using special approach. In this case, UHCI controller driver > should implement this op. I don't understand the reason behind this. Doesn't this sort of thing belong in the bus and platform code, not in the PM core? (In the case of UHCI, it should be handled by the platform, in the same way as remote wakeup gets enabled before the suspend.) Drivers don't have to be involved at all. When a wakeup signal is detected, the driver's runtime_resume method should get called -- nothing more is needed. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 19, 2009 at 10:49:30PM +0800, Alan Stern wrote: > On Wed, 19 Aug 2009, Shaohua Li wrote: > > > Introduce .wakeup_event(). When a device gets a wakeup event, > > the callback is called. The callback usually should check if the device > > really invokes wakeup event and disable wakeup event if yes. > > > > Usually driver should does nothing in the op as bus can handle it. But in some > > cases, like pci bus, UHCI controller doesn't use standard PME registers for > > wakeup, instead of using special approach. In this case, UHCI controller driver > > should implement this op. > > I don't understand the reason behind this. Doesn't this sort of thing > belong in the bus and platform code, not in the PM core? (In the case > of UHCI, it should be handled by the platform, in the same way as > remote wakeup gets enabled before the suspend.) > > Drivers don't have to be involved at all. When a wakeup signal is > detected, the driver's runtime_resume method should get called -- > nothing more is needed. The only case is UHCI in my mind. Because UHCI has non-standard wakeup event register. If BIOS doesn't handle it correctly (for example, not clear the wakeup event after a GPE), we will keep see the wakeup event. And the bus/platform level has no knowledge to handle such event. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 19, 2009 at 07:52:10PM +0800, Matthew Garrett wrote: > On Wed, Aug 19, 2009 at 03:24:11PM +0800, Shaohua Li wrote: > > > Usually driver should does nothing in the op as bus can handle it. But in some > > cases, like pci bus, UHCI controller doesn't use standard PME registers for > > wakeup, instead of using special approach. In this case, UHCI controller driver > > should implement this op. > > I'm not averse to the general concept, but I'm not entirely sold on it > being necessary. All the hardware I'm aware of will send non-PME events > as a notification on a specific device. Under what circumstances will we > get a wakeup GPE for a non-PME device without knowing which device > should be woken? Below code is gotten from a laptop (samsung-x10), the PCIB is the PCI bridge. We can't guarantee the device which gets a wakeup event notification is really the device which invokes the wakeup event. Device (PCIB) { Name (_ADR, 0x001E0000) Device (CDB0) { Name (_ADR, 0x00030000) } Device (CDB1) { Name (_ADR, 0x00030001) } } Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.PCIB, 0x02) Notify (\_SB.PWRB, 0x02) Store (0x01, \_SB.PCI0.PCIB.CDB0.PMES) Store (0x01, \_SB.PCI0.PCIB.CDB1.PMES) } Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 20, 2009 at 11:24:50AM +0800, Shaohua Li wrote: > On Wed, Aug 19, 2009 at 07:52:10PM +0800, Matthew Garrett wrote: > > I'm not averse to the general concept, but I'm not entirely sold on it > > being necessary. All the hardware I'm aware of will send non-PME events > > as a notification on a specific device. Under what circumstances will we > > get a wakeup GPE for a non-PME device without knowing which device > > should be woken? > Below code is gotten from a laptop (samsung-x10), the PCIB is the PCI bridge. > We can't guarantee the device which gets a wakeup event notification is really > the device which invokes the wakeup event. _L0B will only be triggered if a PME is generated, so we'll be able to determine which device generated the wakeup by looking at the PME registers.
On Thu, 20 Aug 2009, Shaohua Li wrote: > > I don't understand the reason behind this. Doesn't this sort of thing > > belong in the bus and platform code, not in the PM core? (In the case > > of UHCI, it should be handled by the platform, in the same way as > > remote wakeup gets enabled before the suspend.) > > > > Drivers don't have to be involved at all. When a wakeup signal is > > detected, the driver's runtime_resume method should get called -- > > nothing more is needed. > The only case is UHCI in my mind. Because UHCI has non-standard wakeup event > register. That's an oversimplification. _Some_ (I think) of _Intel's_ UHCI implementations have a non-standard wakeup event register. > If BIOS doesn't handle it correctly (for example, not clear the wakeup > event after a GPE), we will keep see the wakeup event. And the bus/platform > level has no knowledge to handle such event. How is the wakeup event received? Maybe for this one type of device a PCI quirk will solve the problem. Or if that doesn't work, code can be added to uhci-hcd to turn off the non-standard wakeup register as part of the resume routine. (The problem here is that the resume routine runs in process context so it has to be called after the wakeup event handler has returned.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 20, 2009 at 10:11:19AM -0400, Alan Stern wrote: > How is the wakeup event received? Maybe for this one type of device a > PCI quirk will solve the problem. Pretty much the same as PME events on PCI - a GPE is generated, an SCI raised, the ACPI interpreter executes the code that's in the ACPI tables, that generates a notification event on the appropriate UHCI device, we live happily ever after.
On Thu, 20 Aug 2009, Matthew Garrett wrote: > On Thu, Aug 20, 2009 at 10:11:19AM -0400, Alan Stern wrote: > > > How is the wakeup event received? Maybe for this one type of device a > > PCI quirk will solve the problem. > > Pretty much the same as PME events on PCI - a GPE is generated, an SCI > raised, the ACPI interpreter executes the code that's in the ACPI > tables, that generates a notification event on the appropriate UHCI > device, we live happily ever after. What happens after the notification event is generated? That is, what functions get called? I'm not at all familiar with this part of the kernel. If the wakeup signal isn't squelched at the source, as part of the event handling, will we get an interrupt storm? Will the uhci-hcd resume routine be able to handle this or does it need to be done earlier? In other words, do we need special-purpose code in the PCI layer to handler it? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 20, 2009 at 10:38:15AM -0400, Alan Stern wrote: > On Thu, 20 Aug 2009, Matthew Garrett wrote: > > Pretty much the same as PME events on PCI - a GPE is generated, an SCI > > raised, the ACPI interpreter executes the code that's in the ACPI > > tables, that generates a notification event on the appropriate UHCI > > device, we live happily ever after. > > What happens after the notification event is generated? That is, what > functions get called? I'm not at all familiar with this part of the > kernel. The notification will be sent to whichever code has registered a notification handler for that device. In my patches that means it'll arrive in the PCI layer (if it's a PCI device) and then call pci_runtime_resume on the appropriate device. > If the wakeup signal isn't squelched at the source, as part of the > event handling, will we get an interrupt storm? Will the uhci-hcd > resume routine be able to handle this or does it need to be done > earlier? In other words, do we need special-purpose code in the PCI > layer to handler it? No, nothing special needs to be done at the PCI level. It seems that (for Intel at least) there's no need to do anything special at the UHCI level either.
On Thu, 20 Aug 2009, Matthew Garrett wrote: > > If the wakeup signal isn't squelched at the source, as part of the > > event handling, will we get an interrupt storm? Will the uhci-hcd > > resume routine be able to handle this or does it need to be done > > earlier? In other words, do we need special-purpose code in the PCI > > layer to handler it? > > No, nothing special needs to be done at the PCI level. It seems that > (for Intel at least) there's no need to do anything special at the UHCI > level either. This contradicts what Shaohua wrote: "The only case is UHCI in my mind. Because UHCI has non-standard wakeup event register. If BIOS doesn't handle it correctly (for example, not clear the wakeup event after a GPE), we will keep see the wakeup event." What code would be responsible for setting and clearing the non-standard wakeup register? Are you assuming that ACPI will always handle it? I guess that's a reasonable assumption -- if ACPI wasn't aware of the register then it never would get enabled, and conversely, if ACPI was aware and could enable the register, then ACPI ought to disable it when necessary. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 20 August 2009, Alan Stern wrote: > On Thu, 20 Aug 2009, Matthew Garrett wrote: > > > > If the wakeup signal isn't squelched at the source, as part of the > > > event handling, will we get an interrupt storm? Will the uhci-hcd > > > resume routine be able to handle this or does it need to be done > > > earlier? In other words, do we need special-purpose code in the PCI > > > layer to handler it? > > > > No, nothing special needs to be done at the PCI level. It seems that > > (for Intel at least) there's no need to do anything special at the UHCI > > level either. > > This contradicts what Shaohua wrote: > > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup > event register. If BIOS doesn't handle it correctly (for example, not > clear the wakeup event after a GPE), we will keep see the wakeup > event." I'm not sure what the phrase "we will keep see the wakeup event" is supposed to mean. For us to "see" any events there has to be a GPE set up or PCIe PME enabled on the right root port. Otherwise I don't see how we can receive the event at all. The bus type wakeup code won't know how to clear the register to acknowledge the wakeup, but the driver's ->runtime_resume() callback surely can do that. > What code would be responsible for setting and clearing the > non-standard wakeup register? Are you assuming that ACPI will always > handle it? I guess that's a reasonable assumption -- if ACPI wasn't > aware of the register then it never would get enabled, and conversely, > if ACPI was aware and could enable the register, then ACPI ought to > disable it when necessary. In any case the event has to be raised in one of the standard ways. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 20 Aug 2009, Rafael J. Wysocki wrote: > On Thursday 20 August 2009, Alan Stern wrote: > > On Thu, 20 Aug 2009, Matthew Garrett wrote: > > > > > > If the wakeup signal isn't squelched at the source, as part of the > > > > event handling, will we get an interrupt storm? Will the uhci-hcd > > > > resume routine be able to handle this or does it need to be done > > > > earlier? In other words, do we need special-purpose code in the PCI > > > > layer to handler it? > > > > > > No, nothing special needs to be done at the PCI level. It seems that > > > (for Intel at least) there's no need to do anything special at the UHCI > > > level either. > > > > This contradicts what Shaohua wrote: > > > > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup > > event register. If BIOS doesn't handle it correctly (for example, not > > clear the wakeup event after a GPE), we will keep see the wakeup > > event." > > I'm not sure what the phrase "we will keep see the wakeup event" is supposed to > mean. For us to "see" any events there has to be a GPE set up or PCIe PME > enabled on the right root port. Otherwise I don't see how we can receive the > event at all. > > The bus type wakeup code won't know how to clear the register to acknowledge > the wakeup, but the driver's ->runtime_resume() callback surely can do that. > > > What code would be responsible for setting and clearing the > > non-standard wakeup register? Are you assuming that ACPI will always > > handle it? I guess that's a reasonable assumption -- if ACPI wasn't > > aware of the register then it never would get enabled, and conversely, > > if ACPI was aware and could enable the register, then ACPI ought to > > disable it when necessary. > > In any case the event has to be raised in one of the standard ways. I'm still not clear on this. Does the non-standard wakeup register have to be set and cleared by the suspend and resume routines in uhci-hcd, or will it be handled by other code? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 20 August 2009, Alan Stern wrote: > On Thu, 20 Aug 2009, Rafael J. Wysocki wrote: > > > On Thursday 20 August 2009, Alan Stern wrote: > > > On Thu, 20 Aug 2009, Matthew Garrett wrote: > > > > > > > > If the wakeup signal isn't squelched at the source, as part of the > > > > > event handling, will we get an interrupt storm? Will the uhci-hcd > > > > > resume routine be able to handle this or does it need to be done > > > > > earlier? In other words, do we need special-purpose code in the PCI > > > > > layer to handler it? > > > > > > > > No, nothing special needs to be done at the PCI level. It seems that > > > > (for Intel at least) there's no need to do anything special at the UHCI > > > > level either. > > > > > > This contradicts what Shaohua wrote: > > > > > > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup > > > event register. If BIOS doesn't handle it correctly (for example, not > > > clear the wakeup event after a GPE), we will keep see the wakeup > > > event." > > > > I'm not sure what the phrase "we will keep see the wakeup event" is supposed to > > mean. For us to "see" any events there has to be a GPE set up or PCIe PME > > enabled on the right root port. Otherwise I don't see how we can receive the > > event at all. > > > > The bus type wakeup code won't know how to clear the register to acknowledge > > the wakeup, but the driver's ->runtime_resume() callback surely can do that. > > > > > What code would be responsible for setting and clearing the > > > non-standard wakeup register? Are you assuming that ACPI will always > > > handle it? I guess that's a reasonable assumption -- if ACPI wasn't > > > aware of the register then it never would get enabled, and conversely, > > > if ACPI was aware and could enable the register, then ACPI ought to > > > disable it when necessary. > > > > In any case the event has to be raised in one of the standard ways. > > I'm still not clear on this. Does the non-standard wakeup register > have to be set and cleared by the suspend and resume routines in > uhci-hcd, or will it be handled by other code? I'm not sure if anyone can answer this 100% accurately without doing any testing. Best, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 20, 2009 at 03:40:51PM +0800, Matthew Garrett wrote: > On Thu, Aug 20, 2009 at 11:24:50AM +0800, Shaohua Li wrote: > > On Wed, Aug 19, 2009 at 07:52:10PM +0800, Matthew Garrett wrote: > > > I'm not averse to the general concept, but I'm not entirely sold on it > > > being necessary. All the hardware I'm aware of will send non-PME events > > > as a notification on a specific device. Under what circumstances will we > > > get a wakeup GPE for a non-PME device without knowing which device > > > should be woken? > > Below code is gotten from a laptop (samsung-x10), the PCIB is the PCI bridge. > > We can't guarantee the device which gets a wakeup event notification is really > > the device which invokes the wakeup event. > > _L0B will only be triggered if a PME is generated, so we'll be able to > determine which device generated the wakeup by looking at the PME > registers. Right, but the event is sent to a bridge. The devices under the bridge invoke wakeup event, not the bridge itself. So you must scan all devices under the bridge to check which device has its PME registers set. So the bridge case isn't what you said (notification always sent to a specific device which invokes the wakeup event) Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 21, 2009 at 05:27:10AM +0800, Rafael J. Wysocki wrote: > On Thursday 20 August 2009, Alan Stern wrote: > > On Thu, 20 Aug 2009, Rafael J. Wysocki wrote: > > > > > On Thursday 20 August 2009, Alan Stern wrote: > > > > On Thu, 20 Aug 2009, Matthew Garrett wrote: > > > > > > > > > > If the wakeup signal isn't squelched at the source, as part of the > > > > > > event handling, will we get an interrupt storm? Will the uhci-hcd > > > > > > resume routine be able to handle this or does it need to be done > > > > > > earlier? In other words, do we need special-purpose code in the PCI > > > > > > layer to handler it? > > > > > > > > > > No, nothing special needs to be done at the PCI level. It seems that > > > > > (for Intel at least) there's no need to do anything special at the UHCI > > > > > level either. > > > > > > > > This contradicts what Shaohua wrote: > > > > > > > > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup > > > > event register. If BIOS doesn't handle it correctly (for example, not > > > > clear the wakeup event after a GPE), we will keep see the wakeup > > > > event." > > > > > > I'm not sure what the phrase "we will keep see the wakeup event" is supposed to > > > mean. For us to "see" any events there has to be a GPE set up or PCIe PME > > > enabled on the right root port. Otherwise I don't see how we can receive the > > > event at all. > > > > > > The bus type wakeup code won't know how to clear the register to acknowledge > > > the wakeup, but the driver's ->runtime_resume() callback surely can do that. > > > > > > > What code would be responsible for setting and clearing the > > > > non-standard wakeup register? Are you assuming that ACPI will always > > > > handle it? I guess that's a reasonable assumption -- if ACPI wasn't > > > > aware of the register then it never would get enabled, and conversely, > > > > if ACPI was aware and could enable the register, then ACPI ought to > > > > disable it when necessary. > > > > > > In any case the event has to be raised in one of the standard ways. > > > > I'm still not clear on this. Does the non-standard wakeup register > > have to be set and cleared by the suspend and resume routines in > > uhci-hcd, or will it be handled by other code? > > I'm not sure if anyone can answer this 100% accurately without doing any > testing. As far as I know, when the pci trys to enable pme, we will call corresponding ACPI methods. In that methods, the non-starndard wakeup registers will be set/clear. The issue is we must relay on correct BIOS. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 21, 2009 at 02:33:50PM +0800, Shaohua Li wrote: > On Thu, Aug 20, 2009 at 03:40:51PM +0800, Matthew Garrett wrote: > > _L0B will only be triggered if a PME is generated, so we'll be able to > > determine which device generated the wakeup by looking at the PME > > registers. > Right, but the event is sent to a bridge. The devices under the bridge invoke > wakeup event, not the bridge itself. So you must scan all devices under the > bridge to check which device has its PME registers set. > So the bridge case isn't what you said (notification always sent to a specific > device which invokes the wakeup event) Yes, but that's fine because the PME state tells us exactly which device caused the wakeup. We'll never get a bus notification if the wakeup is triggered by UHCI on Intel.
On Fri, 21 Aug 2009, Shaohua Li wrote: > > > I'm still not clear on this. Does the non-standard wakeup register > > > have to be set and cleared by the suspend and resume routines in > > > uhci-hcd, or will it be handled by other code? > > > > I'm not sure if anyone can answer this 100% accurately without doing any > > testing. > As far as I know, when the pci trys to enable pme, we will call corresponding > ACPI methods. In that methods, the non-starndard wakeup registers will be > set/clear. The issue is we must relay on correct BIOS. If the BIOS doesn't know about the non-standard register then it won't set the wakeup bits. Therefore the fact that it won't clear them doesn't matter. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 21, 2009 at 05:23:16PM +0800, Matthew Garrett wrote: > On Fri, Aug 21, 2009 at 02:33:50PM +0800, Shaohua Li wrote: > > On Thu, Aug 20, 2009 at 03:40:51PM +0800, Matthew Garrett wrote: > > > _L0B will only be triggered if a PME is generated, so we'll be able to > > > determine which device generated the wakeup by looking at the PME > > > registers. > > Right, but the event is sent to a bridge. The devices under the bridge invoke > > wakeup event, not the bridge itself. So you must scan all devices under the > > bridge to check which device has its PME registers set. > > So the bridge case isn't what you said (notification always sent to a specific > > device which invokes the wakeup event) > > Yes, but that's fine because the PME state tells us exactly which device > caused the wakeup. We'll never get a bus notification if the wakeup is > triggered by UHCI on Intel. Hmm, but here what we are talking about is if notification is always sent to the device which invokes wakeup event. I pointed out this isn't true because BIOS might sent notification to a pci bridge and OS should scan devices under the bridge to check which devices invokes it by looking at PME state. Looks you are talking about other things. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 24, 2009 at 09:50:46AM +0800, Shaohua Li wrote: > On Fri, Aug 21, 2009 at 05:23:16PM +0800, Matthew Garrett wrote: > > Yes, but that's fine because the PME state tells us exactly which device > > caused the wakeup. We'll never get a bus notification if the wakeup is > > triggered by UHCI on Intel. > Hmm, but here what we are talking about is if notification is always sent to the device > which invokes wakeup event. > I pointed out this isn't true because BIOS might sent notification to a pci bridge and > OS should scan devices under the bridge to check which devices invokes it by looking at > PME state. Looks you are talking about other things. There are two cases: 1) Notification is sent to a device. Since we know the device that generated the event, we don't need .wakeup_event. 2) Notification is sent to a bus. This will only happen if the device supports PME, so we don't need .wakeup_event.
On Mon, 2009-08-24 at 10:48 +0800, Matthew Garrett wrote: > On Mon, Aug 24, 2009 at 09:50:46AM +0800, Shaohua Li wrote: > > On Fri, Aug 21, 2009 at 05:23:16PM +0800, Matthew Garrett wrote: > > > Yes, but that's fine because the PME state tells us exactly which device > > > caused the wakeup. We'll never get a bus notification if the wakeup is > > > triggered by UHCI on Intel. > > Hmm, but here what we are talking about is if notification is always sent to the device > > which invokes wakeup event. > > I pointed out this isn't true because BIOS might sent notification to a pci bridge and > > OS should scan devices under the bridge to check which devices invokes it by looking at > > PME state. Looks you are talking about other things. > > There are two cases: > > 1) Notification is sent to a device. Since we know the device that > generated the event, we don't need .wakeup_event. > > 2) Notification is sent to a bus. This will only happen if the device > supports PME, so we don't need .wakeup_event. This depends on where you put the ACPI GPE code. If you put it to ACPI directory, then we need a .wakeup_event at least in bus level. ACPI is a generic framework, it can send wakeup event to any bus. It's definitely better to put the wakeup GPE handling into ACPI directory. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 24, 2009 at 04:01:02PM +0800, Shaohua Li wrote: > On Mon, 2009-08-24 at 10:48 +0800, Matthew Garrett wrote: > > 1) Notification is sent to a device. Since we know the device that > > generated the event, we don't need .wakeup_event. > > > > 2) Notification is sent to a bus. This will only happen if the device > > supports PME, so we don't need .wakeup_event. > This depends on where you put the ACPI GPE code. If you put it to ACPI directory, then > we need a .wakeup_event at least in bus level. > ACPI is a generic framework, it can send wakeup event to any bus. It's > definitely better to put the wakeup GPE handling into ACPI directory. I don't agree - the wakeup GPE will generate a standard notify, and the notification handler has to be at the device or bus layer to handle device-specific requests.
On Mon, 2009-08-24 at 16:09 +0800, Matthew Garrett wrote: > On Mon, Aug 24, 2009 at 04:01:02PM +0800, Shaohua Li wrote: > > On Mon, 2009-08-24 at 10:48 +0800, Matthew Garrett wrote: > > > 1) Notification is sent to a device. Since we know the device that > > > generated the event, we don't need .wakeup_event. BTW, Alan thought we should trust BIOS can handle wakeup event correctly here, so device don't need .wakeup_event. I have no strong objection currently, but from my experience in ACPI side, BIOS is always not able to be trusted. > > > 2) Notification is sent to a bus. This will only happen if the device > > > supports PME, so we don't need .wakeup_event. > > This depends on where you put the ACPI GPE code. If you put it to ACPI directory, then > > we need a .wakeup_event at least in bus level. > > ACPI is a generic framework, it can send wakeup event to any bus. It's > > definitely better to put the wakeup GPE handling into ACPI directory. > > I don't agree - the wakeup GPE will generate a standard notify, and the > notification handler has to be at the device or bus layer to handle > device-specific requests. Then we will have duplicate code at each device or bus. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 24, 2009 at 04:21:50PM +0800, Shaohua Li wrote: > On Mon, 2009-08-24 at 16:09 +0800, Matthew Garrett wrote: > > I don't agree - the wakeup GPE will generate a standard notify, and the > > notification handler has to be at the device or bus layer to handle > > device-specific requests. > Then we will have duplicate code at each device or bus. I think that's inevitable, unless the notification infrastructure is made more fine grained.
On Mon, 2009-08-24 at 16:27 +0800, Matthew Garrett wrote: > On Mon, Aug 24, 2009 at 04:21:50PM +0800, Shaohua Li wrote: > > On Mon, 2009-08-24 at 16:09 +0800, Matthew Garrett wrote: > > > I don't agree - the wakeup GPE will generate a standard notify, and the > > > notification handler has to be at the device or bus layer to handle > > > device-specific requests. > > Then we will have duplicate code at each device or bus. > > I think that's inevitable, unless the notification infrastructure is > made more fine grained. At least we need some check and maybe gpe handling and we need some "ifdef ACPI" staff at each device or bus. There isn't big difference device/bus register a notification handler or register a .wakeup_event. And .wakeup_event is more simple in device/bus level. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 24, 2009 at 04:46:12PM +0800, Shaohua Li wrote: > On Mon, 2009-08-24 at 16:27 +0800, Matthew Garrett wrote: > > I think that's inevitable, unless the notification infrastructure is > > made more fine grained. > At least we need some check and maybe gpe handling and we need some > "ifdef ACPI" staff at each device or bus. > There isn't big difference device/bus register a notification handler or > register a .wakeup_event. And .wakeup_event is more simple in device/bus > level. Yes there is - .wakeup_event will only be called if a wakeup notification is received, whereas a notification handler will be called for other notifications as well such as bus check or eject request. If the core registers notifiers for all devices then you'll break dock handling, for instance. We'd need to add callbacks for all the notifications <0x80.
On Monday 24 August 2009, Shaohua Li wrote: > On Mon, 2009-08-24 at 16:27 +0800, Matthew Garrett wrote: > > On Mon, Aug 24, 2009 at 04:21:50PM +0800, Shaohua Li wrote: > > > On Mon, 2009-08-24 at 16:09 +0800, Matthew Garrett wrote: > > > > I don't agree - the wakeup GPE will generate a standard notify, and the > > > > notification handler has to be at the device or bus layer to handle > > > > device-specific requests. > > > Then we will have duplicate code at each device or bus. > > > > I think that's inevitable, unless the notification infrastructure is > > made more fine grained. > At least we need some check and maybe gpe handling and we need some > "ifdef ACPI" staff at each device or bus. Why would we need that? > There isn't big difference device/bus register a notification handler or > register a .wakeup_event. And .wakeup_event is more simple in device/bus > level. As Matthew said, there is. To make things clear, we're not going to add .wakeup_event(). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux/include/linux/pm.h =================================================================== --- linux.orig/include/linux/pm.h 2009-08-19 11:44:41.000000000 +0800 +++ linux/include/linux/pm.h 2009-08-19 13:44:03.000000000 +0800 @@ -191,6 +191,13 @@ typedef struct pm_message { * power state if all of the necessary conditions are satisfied. Check * these conditions and handle the device as appropriate, possibly queueing * a suspend request for it. + * + * @wakeup_event: Checks if a wakeup event occurs. In bus level, the op might + * check all devices under the bus and call device_receive_wakeup_event() + * for devices which invoke wakeup event. In device level, the op just + * returns if a wakeup event occurs. Note, if device follows standard + * mechanism for wakeup which bus level can handle, device level op can be + * empty. */ struct dev_pm_ops { @@ -211,6 +218,7 @@ struct dev_pm_ops { int (*runtime_suspend)(struct device *dev); int (*runtime_resume)(struct device *dev); void (*runtime_idle)(struct device *dev); + bool (*wakeup_event)(struct device *dev); }; /**