On Fri, Feb 14, 2020 at 09:13:48AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> [200214 13:40]: > > On Fri, Feb 14, 2020 at 01:43:36PM +0200, Andy Shevchenko wrote: > > > Doing any kind of power management for kernel console is really bad idea. > > > > > > First of all, it runs in poll and atomic mode. This fact attaches a limitation > > > on the functions that might be called. For example, pm_runtime_get_sync() might > > > sleep and thus can't be used. This call needs, for example, to bring the device > > > to powered on state on the system, where the power on sequence may require > > > on-atomic operations, such as Intel Cherrytrail with ACPI enumerated UARTs. > > > That said, on ACPI enabled platforms it might even call firmware for a job. > > > > > > On the other hand pm_runtime_get() doesn't guarantee that device will become > > > powered on fast enough. > > > > > > Besides that, imagine the case when console is about to print a kernel Oops and > > > it's powered off. In such an emergency case calling the complex functions is > > > not the best what we can do, taking into consideration that user wants to see > > > at least something of the last kernel word before it passes away. > > > > > > Here we modify the 8250 console code to prevent runtime power management. > > > > It's probably also worth noting (and documenting) that this will likely > > cause a PM regression for OMAP platforms since the serial port will no > > longer be idled, and therefore the power domains will not hit retention > > state. Please wait for Tony to confirm. > > Well with patch 4 in this series we can now attach and detach the serial > console as we've discussed earlier. > > This should remove the need for PM during serial console use hopefully :) > > I'll try to test this series ASAP. Tony, I have realized that last patch (two patches) makes a regression. So, I'll drop them in next version, please do not include them in your testing bucket. -- With Best Regards, Andy Shevchenko
