On Sunday, March 08, 2015 11:43:34 AM Alan Stern wrote:
> On Sat, 7 Mar 2015, Rafael J. Wysocki wrote:
>
> > But this is part of a bigger picture. Namely, if a separete wakeup interrupt
> > is required for a device, the device's power.can_wakeup flag cannot be set
> > until that interrupt has been successfully requested. Also for devices that
> > can signal wakeup via their own IO interrupts, it would make sense to allow
> > those interrupts to be registered somehow as "wakeup interrupts".
> >
> > So I wonder if we can define a new struct along the lines of your
> > struct wakeirq_source, but call it struct wake_irq and make it look
> > something like this:
> >
> > struct wake_irq {
> > struct device *dev;
> > int irq;
> > irq_handler_t handler;
> > };
> >
> > Then, add a struct wake_irq pointer to struct dev_pm_info *and* to
> > struct wakeup_source. Next, make dev_pm_request_wake_irq() allocate the
> > structure and request the interrupt and only set the pointer to it from
> > struct dev_pm_info *along* *with* power.can_wakeup if all that was
> > successful.
> >
> > For devices that use their own IO IRQ for wakeup, we can add something
> > like dev_pm_set_wake_irq() that will work analogously, but without requesting
> > the interrupt. It will just set the dev and irq members of struct wake_irq
> > and point struct dev_pm_info to it and set its power.can_wakeup flag.
> >
> > Then, device_wakeup_enable() will be able to see that the device has a
> > wakeup IRQ and it may then point its own struct wake_irq pointer to that.
> > The core may then use that pointer to trigger enable_irq_wake() for the
> > IRQ in question and it will cover the devices that don't need separate
> > wakeup interrupts too.
> >
> > Does that make sense to you?
>
> Can we back up a little? What is the basic problem the two of you are
> trying to solve?
Essentially, code duplication between drivers that all need to do the same
thing which can be moved to the core quite easily.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
