UPSTREAM: serial: 8250_mtk: Simplify clock sequencing and runtime PM
When testing deep suspend/resume we could observe some issues when getting back the secondary CPUS online:
[ 51.848362] PM: suspend entry (deep)
[ 51.977044] Filesystems sync: 0.128 seconds
[ 53.995078] Freezing user space processes ... (elapsed 0.005 seconds) done.
[ 54.001618] OOM killer disabled.
[ 54.002032] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[ 54.005610] printk: Suspending console(s) (use no_console_suspend to debug)
)3dڷitializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot
[ 54.009019] Bluetooth: hci0: status (0) return ownership to device
[ 54.182590] Disabling non-boot CPUs ...
[ 54.184062] psci: CPU1 killed (polled 4 ms)
[ 54.188114] psci: CPU2 killed (polled 4 ms)
[ 54.192112] psci: CPU3 killed (polled 4 ms)
[ 54.194418] PM: pm_system_irq_wakeup: 46 triggered volume_up
[ 54.194524] Enabling non-boot CPUs ...
[ 59.370478] CPU1: failed to come online
[ 59.370487] CPU1: failed in unknown state : 0x0
[ 59.371150] Error taking CPU1 up: -5
[ 64.490566] CPU2: failed to come online
[ 64.490574] CPU2: failed in unknown state : 0x0
[ 64.491254] Error taking CPU2 up: -5
[ 69.610662] CPU3: failed to come online
[ 69.610669] CPU3: failed in unknown state : 0x0
[ 69.611291] Error taking CPU3 up: -5
By disabling the uart, or letting console enabled during suspend, issue was not observed.
Fix it by applying upstream patch.
The 8250_mtk driver's runtime PM support has some issues:
- The bus clock is enabled (through runtime PM callback) later than a register write
- runtime PM resume callback directly called in probe, but no pm_runtime_set_active() call is present
- UART PM function calls the callbacks directly, and calls runtime PM API
- runtime PM callbacks try to do reference counting, adding yet another count between runtime PM and clocks
This fragile setup worked in a way, but broke recently with runtime PM support added to the serial core. The system would hang when the UART console was probed and brought up.
Tony provided some potential fixes [1][2], though they were still a bit complicated. The 8250_dw driver, which the 8250_mtk driver might have been based on, has a similar structure but simpler runtime PM usage.
Simplify clock sequencing and runtime PM support in the 8250_mtk driver. Specifically, the clock is acquired enabled and assumed to be active, unless toggled through runtime PM suspend/resume. Reference counting is removed and left to the runtime PM core. The serial pm function now only calls the runtime PM API.
[1] https://lore.kernel.org/linux-serial/20230602092701.GP14287@atomide.com/ [2] https://lore.kernel.org/linux-serial/20230605061511.GW14287@atomide.com/
Fixes: 84a9582f ("serial: core: Start managing serial controllers to enable runtime PM") Suggested-by: Tony Lindgren tony@atomide.com Signed-off-by: Chen-Yu Tsai wenst@chromium.org Reviewed-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Reviewed-by: Tony Lindgren tony@atomide.com Message-ID: 20230606091747.2031168-1-wenst@chromium.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org (cherry picked from commit b6c7ff26) Signed-off-by: Vitor Sato Eschholz vsatoes@baylibre.com