>-----Original Message----- >From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >owner@xxxxxxxxxxxxxxx] On Behalf Of David Brownell >Sent: Tuesday, September 09, 2008 10:56 AM >To: Li, Shaohua >Cc: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; >stern@xxxxxxxxxxxxxxxxxxx >Subject: Re: [RFC 1/5] devcore introduce wakeup_event callback > >On Monday 08 September 2008, shaohua.li@xxxxxxxxx wrote: >> --- linux.orig/include/linux/pm.h 2008-09-08 13:55:57.000000000 >+0800 >> +++ linux/include/linux/pm.h 2008-09-08 13:56:51.000000000 +0800 >> @@ -125,6 +125,8 @@ typedef struct pm_message { >> * make ANY assumptions about the hardware state right prior to >@restore(). >> * On most platforms, there are no restrictions on availability of >> * resources like clocks during @restore(). >> + * @wakeup_event: Checks if a wakeup event occurs. If yes, wakeup event >should >> + * be disabled. > >And ... what else?? What does the return value indicate? >Should anything be done with it other than printing it out >if it's nonzero and we're debugging? Return 0 if the device invokes a wakeup event. In this case, driver should clear/disable wakeup event. Return < 0 if device didn't invoke wakeup. If device follows standard wakeup mechanism which bus level can handle, driver isn't required to provide this callback. >> * >> * All of the above callbacks, except for @complete(), return error >codes. >> * However, the error codes returned by the resume operations, @resume(), >> @@ -151,6 +153,7 @@ struct pm_ops { >> int (*thaw)(struct device *dev); >> int (*poweroff)(struct device *dev); >> int (*restore)(struct device *dev); >> + int (*wakeup_event)(struct device *dev); > >My reaction to adding this method is: why do it here rather >than at the bus level? > >In my particular experience there are two basic types of wakeup >event: > > - Regular IRQs. Common on SOC systems; the IRQ comes in, > the driver knows it must wake up. Does not need any > driver model hook; enable_irq_wake()/disable_irq_wake() > suffice. > > I've seen USB remote wakeup working just fine on several > different embedded Linuxes using only regular IRQ hooks. Ok, in such case, driver can just ignore the callback. > - Side-band signaling. Think of this as an IRQ mechanism > that's not used for "normal" driver operation, and you > won't be far off. Examples: > > * PCI PME# (and its PCIE analogue). Bus-specific; it's > pretty much a kind of shared IRQ line coupled with a > special config-space register protocol. Right, in this case, device doesn't require .wakeup_event too. > > * ACPI GPEs. Bus-specific ... and similar to GPIO IRQs. > Also sharable; bytecode is used to map the GPE and > some register state to the ACPI device(s) which > issued that GPE. This isn't bus specific. ACPI devices can map to any physical devices, like PCI, IDE drive, PNP device. In this case, a bus specific mechanism can't handle all. For example the UHCI case. A GPE is fired, we need to clear/disable the wakeup event. PCI bus can't handle it, as UHCI has special registers for this, so we need call into device specific handling. > * Pin-change events. Not quite isomorphic with (GPIO) > IRQs; sometimes used with pins that aren't used for > events (or even GPIOs!) during normal operation. > Device-specific. > >That is, I don't see why these events should expect to be >filtered through the driver core. If there's a reason to >do that, please enlighten me! The UHCI case. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
