On 17/09/15 12:01, Zhaoyang Huang wrote:
On 17 September 2015 at 18:39, Sudeep Holla <sudeep.holla@xxxxxxx <mailto:sudeep.holla@xxxxxxx>> wrote: On 17/09/15 09:31, Zhaoyang Huang wrote: the commit use the latest dev_pm_set_wake_irq API instead of the enable_irq_wake and IRQF_NO_SUSPEND to configure the ttyAMA device to work as the wakeup source As I mentioned earlier[1], if this a based on Juno platform, then it gets NACK. Please add this feature when it's needed on a real platform on which hardware supports UART/PL011 as a wake source. Do you have any such platform to test ? On Juno, it can't be used as wakeup source. Regards, Sudeep [1] https://www.marc.info/?l=linux-pm&m=144239396227080&w=2 Hi Sudeep, I think the wakeup source you mean is restricted to the device which can wake S2R. However, I think the S2I should be also considered, which need not the hardware support for powering the core up, but just need the isr to be keep active etc.
Hmm, I disagree as we have single control for wakeup and what if you have enabled PL011 as wakeup and S2R is entered assuming there's one active wakeup anyway. IMO w.r.t wakeup source we *must* assume it also wakes up from S2R state always. You didn't answer to my earlier query, why didn't you choose other interrupts like ethernet, gpio or just pick one from the lot of interrupts on Juno as wakeup from S2I. What was the rationale behind your choice especially on Juno ? Just because you can send and receive chars via the tty/console, what if I don't have access to console. We need much better and hardware supported wakeup source like RTC or GPIO. Also a SoC can enter deeper idle states in S2I where UART can't wakeup. How would you know that ? I re-iterate that hardware should have support to ensure it can wakeup the system. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
