* Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> [160825 04:53]: > On Wed, 2016-08-24 at 08:43 -0700, Tony Lindgren wrote: > > > > PM runtime with UARTs has been working for me just fine for quite some > > time now. I'm mostly using omap-serial still and have not checked with > > 8250-omap recently. > > Yeah, they both are using irq_safe flag. Actually they two out of only > 15 users in entire kernel. > > Looks like OMAP code is main user of the flag. Yeah and we've seen that using irq_safe is not a good solution. > > But yeah I agree that PM runtime should be improved and simplified for > > 8250. > > Why not to do this once for all in serial_core.c directly? > > > We should not use irq_safe at all and instead fix up things so > > runtime_resume wakes up things with pm_runtime_get without get_sync. > > This adds latency only to the first wake-up event which can already > > take a long time at least on omaps as things are getting powered back > > on. > > > No idea how to implement that though for cases when there's no > > dedicated wakeirq.. Maybe change the irq to a threaded irq for the > > duration of idle for 8250 irq? > > I have no ideas either, but irq_safe should be not used if we are doing > pm_runtime_get_sync(). Right. How about try something like this to play with: 1. Configure an external wakeup source as a wakeirq, could be whatever GPIO pin you can trigger for testing too 2. Then in 8250 pm_runtime_suspend do disable_irq on the 8250 irq 3. Trigger a wakeirq event 4. In 8250 pm_runtime_resume, enable_irq on the 8250 irq And then no irq_safe needed and we can get rid of all the pm_runtime calls in interrupt handlers :) Regards, Tony -- 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
