On Wed, 2018-05-16 at 12:47 +0200, Sebastian Andrzej Siewior wrote: > On 2018-05-16 13:17:36 [+0300], Andy Shevchenko wrote: > > > The output is usually short so there > > > shouldn't be much benefit from using it. > > > I remember Tony wanted runtime-pm on the kernel console, too. And > > > he > > > told me explicit how to test it so that it works. Once the UART > > > goes > > > into PM (down), the whole IP block can go into power save mode. > > > The > > > board can be woken up by sending a character via the UART. The > > > first few > > > (incoming / read) characters are lost until the IP block is up > > > again the > > > frequency stable. This is known / expected. > > > > Don't consider world the OMAP only. The things more complicated if > > we > > go out of it. Which I tried to explain in the commit message of > > patch > > 2. > > I am not saying the world is OMAP only. I just tried to explain how > any > why it got there and its purpose. I haven't NACKed it. I would believe > that with that information and Tony not defending his use case or > possible change it somehow so it is not standing in your way, Greg > would > have enough information to go your way.
Yes, I got it. > But since I am on it. You have to enable runtime-PM for the UART. So > what is the problem if you simply don't enable it for the UART which > used as the kernel console? How do I know at the ->probe() time that device in question is going to be kernel console? Maybe I missed simple way of it. > From reading the description of #2, my understanding is that you are > afraid that enabling the UART (bringing it from power-down mode) might > take too long because it requires (or might require) an ACPI function > call. This brings me again to: why bother and enable it in the first > place? Because this might not work from NMI context. > From looking at #2. You remove put/get in console_write() ...which must be removed in any case... > and avoid > runtime PM by pm_runtime_get_noresume() and need the extra hook on > console exit. I wasn't aware that you can remove the console at > runtime > (and assumed you have to stick to what said in console= at bootime). > Because if that is the case, you could simply strip UART_CAP_RPM and > then there is no more runtime-PM for you. Or is it too simple and I > miss something here? See above question. IIRC it's either too early or too late to decide on per port basis. > > > > In order to achieve the same thing you would have to disable the > > > kernel > > > console on that UART. I leave this to Tony. > > > > Precisely the point of the series. Besides above this would be needed _at least_ for several 8250 glue drivers, so, I decide to go once for all. > > Sebastian -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy
