2024-04-25 07:09:57

by claudiu beznea

[permalink] [raw]
Subject: [RFT PATCH v2] serial: core: Call device_set_awake_path() for console port

From: Claudiu Beznea <[email protected]>

In case the UART port is used as a console, no_console_suspend is
available in bootargs and UART port is part of a software-controlled power
domain we need to call device_set_awake_path(). This lets the power
domain core code know that this domain should not be powered off
during system suspend. Otherwise, the UART port power domain is turned off,
nothing is printed while suspending and the suspend/resume process is
blocked. This was detected on the Renesas RZ/G3S SoC while adding support
for power domains.

Based on code investigation, this issue is present on other SoCs (e.g.,
Renesas R-Mobile A1 [1], IMX8QXP [2]) and different SoCs have particular
implementation to handle it. Due to this the patch added the call of
device_set_awake_path() in uart_suspend_port() instead of having it in
the platform specific UART driver.

[1] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/renesas/rmobile-sysc.c#L116
[2] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/imx/scu-pd.c#L357

Suggested-by: Ulf Hansson <[email protected]>
Suggested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Claudiu Beznea <[email protected]>
---

Changes in v2:
- used device_set_awake_path() instead of device_set_wakeup_path()
- moved the support in uart_suspend_port() to make it generic for
other drivers
- fixed typos in commit description
- updated the commit description to reflect the new changes and the fact
that support may be applied to other SoCs
- added Suggested-by tag; this was initially proposed by Ulf to move it
in the serial driver then Geert propose to have it more generic in
uart_suspend_port()


drivers/tty/serial/serial_core.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index d8d797a7a1e3..6270baab668c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2409,6 +2409,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
uport->ops->stop_rx(uport);
uart_port_unlock_irq(uport);
}
+ device_set_awake_path(uport->dev);
goto unlock;
}

--
2.39.2



2024-04-25 07:49:11

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [RFT PATCH v2] serial: core: Call device_set_awake_path() for console port

On Thu, Apr 25, 2024 at 9:09 AM Claudiu <[email protected]> wrote:
> From: Claudiu Beznea <[email protected]>
>
> In case the UART port is used as a console, no_console_suspend is
> available in bootargs and UART port is part of a software-controlled power
> domain we need to call device_set_awake_path(). This lets the power
> domain core code know that this domain should not be powered off
> during system suspend. Otherwise, the UART port power domain is turned off,
> nothing is printed while suspending and the suspend/resume process is
> blocked. This was detected on the Renesas RZ/G3S SoC while adding support
> for power domains.
>
> Based on code investigation, this issue is present on other SoCs (e.g.,
> Renesas R-Mobile A1 [1], IMX8QXP [2]) and different SoCs have particular
> implementation to handle it. Due to this the patch added the call of
> device_set_awake_path() in uart_suspend_port() instead of having it in
> the platform specific UART driver.
>
> [1] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/renesas/rmobile-sysc.c#L116
> [2] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/imx/scu-pd.c#L357
>
> Suggested-by: Ulf Hansson <[email protected]>
> Suggested-by: Geert Uytterhoeven <[email protected]>
> Signed-off-by: Claudiu Beznea <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

Works fine on R-Mobile APE6 with console suspend support removed from
rmobile-sysc.c
Tested-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2024-04-25 09:50:50

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [RFT PATCH v2] serial: core: Call device_set_awake_path() for console port

On Thu, Apr 25, 2024 at 10:09:36AM +0300, Claudiu wrote:
> From: Claudiu Beznea <[email protected]>
>
> In case the UART port is used as a console, no_console_suspend is
> available in bootargs and UART port is part of a software-controlled power
> domain we need to call device_set_awake_path(). This lets the power
> domain core code know that this domain should not be powered off
> during system suspend. Otherwise, the UART port power domain is turned off,
> nothing is printed while suspending and the suspend/resume process is
> blocked. This was detected on the Renesas RZ/G3S SoC while adding support
> for power domains.
>
> Based on code investigation, this issue is present on other SoCs (e.g.,
> Renesas R-Mobile A1 [1], IMX8QXP [2]) and different SoCs have particular
> implementation to handle it. Due to this the patch added the call of
> device_set_awake_path() in uart_suspend_port() instead of having it in
> the platform specific UART driver.

> [1] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/renesas/rmobile-sysc.c#L116
> [2] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/imx/scu-pd.c#L357

No need to have the HTTP links into the kernel sources, you may simply refer to
the files in the source tree.

[1] drivers/pmdomain/renesas/rmobile-sysc.c:L116
[2] drivers/pmdomain/imx/scu-pd.c:L357

> Suggested-by: Ulf Hansson <[email protected]>
> Suggested-by: Geert Uytterhoeven <[email protected]>
> Signed-off-by: Claudiu Beznea <[email protected]>

The rest makes sense to me as we also have an internal hack to achieve
something similar in the case of Intel LPSS (8250_dw).

But I like Tony to comment on this, from my perspective it's good:
Reviewed-by: Andy Shevchenko <[email protected]>

--
With Best Regards,
Andy Shevchenko



2024-04-25 09:52:06

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [RFT PATCH v2] serial: core: Call device_set_awake_path() for console port

On Thu, Apr 25, 2024 at 12:50:16PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 25, 2024 at 10:09:36AM +0300, Claudiu wrote:
> > From: Claudiu Beznea <[email protected]>

..

> > [1] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/renesas/rmobile-sysc.c#L116
> > [2] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/imx/scu-pd.c#L357
>
> No need to have the HTTP links into the kernel sources, you may simply refer to
> the files in the source tree.
>
> [1] drivers/pmdomain/renesas/rmobile-sysc.c:L116
> [2] drivers/pmdomain/imx/scu-pd.c:L357

Should be without 'L' to follow the `git grep -n` output format.

--
With Best Regards,
Andy Shevchenko



2024-04-25 16:59:26

by Ulf Hansson

[permalink] [raw]
Subject: Re: [RFT PATCH v2] serial: core: Call device_set_awake_path() for console port

On Thu, 25 Apr 2024 at 09:09, Claudiu <[email protected]> wrote:
>
> From: Claudiu Beznea <[email protected]>
>
> In case the UART port is used as a console, no_console_suspend is
> available in bootargs and UART port is part of a software-controlled power
> domain we need to call device_set_awake_path(). This lets the power
> domain core code know that this domain should not be powered off
> during system suspend. Otherwise, the UART port power domain is turned off,
> nothing is printed while suspending and the suspend/resume process is
> blocked. This was detected on the Renesas RZ/G3S SoC while adding support
> for power domains.
>
> Based on code investigation, this issue is present on other SoCs (e.g.,
> Renesas R-Mobile A1 [1], IMX8QXP [2]) and different SoCs have particular
> implementation to handle it. Due to this the patch added the call of
> device_set_awake_path() in uart_suspend_port() instead of having it in
> the platform specific UART driver.
>
> [1] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/renesas/rmobile-sysc.c#L116
> [2] https://elixir.bootlin.com/linux/v6.9-rc5/source/drivers/pmdomain/imx/scu-pd.c#L357
>
> Suggested-by: Ulf Hansson <[email protected]>
> Suggested-by: Geert Uytterhoeven <[email protected]>
> Signed-off-by: Claudiu Beznea <[email protected]>

At least conceptually this makes perfect sense to me. If it's the
correct place to put it, I trust others to know. Nevertheless, feel
free to add:

Reviewed-by: Ulf Hansson <[email protected]>

Kind regards
Uffe

> ---
>
> Changes in v2:
> - used device_set_awake_path() instead of device_set_wakeup_path()
> - moved the support in uart_suspend_port() to make it generic for
> other drivers
> - fixed typos in commit description
> - updated the commit description to reflect the new changes and the fact
> that support may be applied to other SoCs
> - added Suggested-by tag; this was initially proposed by Ulf to move it
> in the serial driver then Geert propose to have it more generic in
> uart_suspend_port()
>
>
> drivers/tty/serial/serial_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index d8d797a7a1e3..6270baab668c 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -2409,6 +2409,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
> uport->ops->stop_rx(uport);
> uart_port_unlock_irq(uport);
> }
> + device_set_awake_path(uport->dev);
> goto unlock;
> }
>
> --
> 2.39.2
>

2024-04-26 20:06:51

by Tony Lindgren

[permalink] [raw]
Subject: Re: [RFT PATCH v2] serial: core: Call device_set_awake_path() for console port

On Thu, Apr 25, 2024 at 12:50:16PM +0300, Andy Shevchenko wrote:
> The rest makes sense to me as we also have an internal hack to achieve
> something similar in the case of Intel LPSS (8250_dw).
>
> But I like Tony to comment on this, from my perspective it's good:
> Reviewed-by: Andy Shevchenko <[email protected]>

Yes nice, makes sense to me too:

Reviewed-by: Tony Lindgren <[email protected]>