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. > 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. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- 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
