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?
> *
> * 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.
- 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.
* 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.
* 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!
- Dave
p.s. Related to this, I don't see the point behind
patch 2/5 ...
> };
>
> /**
--
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
