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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
