* Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> [161114 08:32]: > On Mon, 2016-11-14 at 11:54 +0100, Sebastian Andrzej Siewior wrote: > > On 2016-11-10 15:58:54 [+0200], Andy Shevchenko wrote: > > > > > > I grepped code and found no driver under 8250 which is using > > > > > > threaded > > > > > > IRQ handler. What did I miss? > > > > > > > > > > Documentation/kernel-parameters.txt: threadirqs [KNL] > > > > > > Okay, so, the scenario you perhaps concerned is: > > > 1. HW generates interrupt. > > > 2. It's queued to be handled by threads. > > > 3. Meanwhile the HW might be powered off (automatic suspend > > > assumed). Tx > > > can't be for sure, Rx side then. But I barely imagine how it is > > > possible. Even if we get it powered off it should wake the system > > > again > > > (via wake source, which is RxD/CTS or out-of-bound one). > > > 4. In the handler we check if the device suspended. So, return to > > > the > > > question below. > > > > > > Where is the issue in my logic? > > > > I am not an expert here. By the time I did this, I've been told to > > always issue a pm_get() before touching any registers - even in > > interrupt handlers. > > If the interrupt fires, does it reset any PM timers which put the > > device > > down? > > UART interrupt doesn't reset any PM timers. We have a separate always on interrupt controller now. That uses Linux generic wakeirq support and just calls the PM runtime resume on interrupt if the UART is (runtime) suspended. So Andy's patch works for me as tested on omap3 with the wakeirq. > > In the "threaded" handler you check whether or not the device is > > suspended. Can or can not the timer fire after the check? > > Nothing prevents it to fire after the check. > > Basically it means we need synchronization between IRQ handler and > ->runtime_suspend() hook. > > There is a few paragraphs at the end of > Documentation/power/runtime_pm.txt related to the topic. OK 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
