Re: [RFC 1/5] devcore introduce wakeup_event callback

[David Brownell <david-b@pacbell.net>]

On Monday 08 September 2008, shaohua.li@intel.com 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html