* Sudeep Holla <sudeep.ho...@arm.com> [151203 11:00]: > On 03/12/15 18:13, Tony Lindgren wrote: > >At least on omaps, this controller is always powered and we never want to > >suspend it as it handles wake-up events for all the IO pins. And that > >usecase sounds exactly like what you're describing above. > > > > Understood, but I assume this is a generic driver that can be used by > any pinmux.
Right no question about that, but we need to keep things working. I just pasted the output to this thread what happens coming back up from suspend. > >I don't quite follow what your suggested alternative for an interrupt > >controller is? > > Why can't we use enable_irq_wake even for parent/interrupt controller as > they can be considered as parent wakeup irq. I agree the interrupt > controller may not be powered down, but still it's part of wakeup and > the irq core needs to identify that. By just marking IRQF_NO_SUSPEND, > you are saying that you can handle interrupt in the suspend path but not > informing that it's a wakeup interrupt. > > With this change, the wakeup handler (including the parent handler) is > called when it's safe as the irq core maintains the state machine. Maybe paste a suggested patch and I can try it. I guess you mean call that from pinctrl-single.c. > >At least we need to have the alternative patched in with this chage before > >just removing IRQF_NO_SUSPEND. > > > > I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake > which ensures it's marked for wakeup. Hmm well see the error I pasted in this thread, maybe that provides more clues. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
