From: Claudiu Beznea <claudiu.beznea@tuxon.dev>
To: Philipp Zabel <p.zabel@pengutronix.de>,
geert+renesas@glider.be, magnus.damm@gmail.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, mturquette@baylibre.com,
sboyd@kernel.org, gregkh@linuxfoundation.org,
jirislaby@kernel.org, lethal@linux-sh.org, g.liakhovetski@gmx.de
Cc: linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
linux-serial@vger.kernel.org,
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Subject: Re: [PATCH v3 3/8] serial: sh-sci: Update the suspend/resume support
Date: Mon, 18 Nov 2024 11:47:39 +0200 [thread overview]
Message-ID: <3153fbd0-189a-4cfc-92cd-a1cc23928d73@tuxon.dev> (raw)
In-Reply-To: <81e131554a34c7b2f795a904f2b561f3c86e0baf.camel@pengutronix.de>
Hi, Philipp,
On 15.11.2024 17:40, Philipp Zabel wrote:
> On Fr, 2024-11-15 at 15:43 +0200, Claudiu wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The Renesas RZ/G3S supports a power saving mode where power to most of the
>> SoC components is turned off. When returning from this power saving mode,
>> SoC components need to be re-configured.
>>
>> The SCIFs on the Renesas RZ/G3S need to be re-configured as well when
>> returning from this power saving mode. The sh-sci code already configures
>> the SCIF clocks, power domain and registers by calling uart_resume_port()
>> in sci_resume(). On suspend path the SCIF UART ports are suspended
>> accordingly (by calling uart_suspend_port() in sci_suspend()). The only
>> missing setting is the reset signal. For this assert/de-assert the reset
>> signal on driver suspend/resume.
>>
>> In case the no_console_suspend is specified by the user, the registers need
>> to be saved on suspend path and restore on resume path. To do this the
>> sci_console_setup() function was added. There is no need to cache/restore
>> the status or FIFO registers. Only the control registers. To differentiate
>> b/w these, the struct sci_port_params::regs was updated with a new member
>> that specifies if the register needs to be chached on suspend. Only the
>> RZ_SCIFA instances were updated with this new support as the hardware for
>> the rest of variants was missing for testing.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>
>> Changes in v3:
>> - none
>>
>> Changes in v2:
>> - rebased on top of the update version of patch 2/8 from
>> this series
>>
>> drivers/tty/serial/sh-sci.c | 53 ++++++++++++++++++++++++++++++-------
>> 1 file changed, 44 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index ade151ff39d2..e53496d2708e 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -101,7 +101,7 @@ enum SCI_CLKS {
>> if ((_port)->sampling_rate_mask & SCI_SR((_sr)))
>>
>> struct plat_sci_reg {
>> - u8 offset, size;
>> + u8 offset, size, suspend_cacheable;
>> };
>>
>> struct sci_port_params {
>> @@ -134,6 +134,8 @@ struct sci_port {
>> struct dma_chan *chan_tx;
>> struct dma_chan *chan_rx;
>>
>> + struct reset_control *rstc;
>> +
>> #ifdef CONFIG_SERIAL_SH_SCI_DMA
>> struct dma_chan *chan_tx_saved;
>> struct dma_chan *chan_rx_saved;
>> @@ -153,6 +155,7 @@ struct sci_port {
>> int rx_trigger;
>> struct timer_list rx_fifo_timer;
>> int rx_fifo_timeout;
>> + unsigned int console_cached_regs[SCIx_NR_REGS];
>> u16 hscif_tot;
>>
>> bool has_rtscts;
>> @@ -298,17 +301,17 @@ static const struct sci_port_params sci_port_params[SCIx_NR_REGTYPES] = {
>> */
>> [SCIx_RZ_SCIFA_REGTYPE] = {
>> .regs = {
>> - [SCSMR] = { 0x00, 16 },
>> - [SCBRR] = { 0x02, 8 },
>> - [SCSCR] = { 0x04, 16 },
>> + [SCSMR] = { 0x00, 16, 1 },
>> + [SCBRR] = { 0x02, 8, 1 },
>> + [SCSCR] = { 0x04, 16, 1 },
>> [SCxTDR] = { 0x06, 8 },
>> [SCxSR] = { 0x08, 16 },
>> [SCxRDR] = { 0x0A, 8 },
>> - [SCFCR] = { 0x0C, 16 },
>> + [SCFCR] = { 0x0C, 16, 1 },
>> [SCFDR] = { 0x0E, 16 },
>> - [SCSPTR] = { 0x10, 16 },
>> + [SCSPTR] = { 0x10, 16, 1 },
>> [SCLSR] = { 0x12, 16 },
>> - [SEMR] = { 0x14, 8 },
>> + [SEMR] = { 0x14, 8, 1 },
>> },
>> .fifosize = 16,
>> .overrun_reg = SCLSR,
>> @@ -3380,6 +3383,7 @@ static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
>> }
>>
>> sp = &sci_ports[id];
>> + sp->rstc = rstc;
>> *dev_id = id;
>>
>> p->type = SCI_OF_TYPE(data);
>> @@ -3507,13 +3511,34 @@ static int sci_probe(struct platform_device *dev)
>> return 0;
>> }
>>
>> +static void sci_console_setup(struct sci_port *s, bool save)
>> +{
>> + for (u16 i = 0; i < SCIx_NR_REGS; i++) {
>> + struct uart_port *port = &s->port;
>> +
>> + if (!s->params->regs[i].suspend_cacheable)
>> + continue;
>> +
>> + if (save)
>> + s->console_cached_regs[i] = sci_serial_in(port, i);
>> + else
>> + sci_serial_out(port, i, s->console_cached_regs[i]);
>> + }
>> +}
>> +
>> static __maybe_unused int sci_suspend(struct device *dev)
>> {
>> struct sci_port *sport = dev_get_drvdata(dev);
>>
>> - if (sport)
>> + if (sport) {
>> uart_suspend_port(&sci_uart_driver, &sport->port);
>>
>> + if (!console_suspend_enabled && uart_console(&sport->port))
>> + sci_console_setup(sport, true);
>> + else
>> + return reset_control_assert(sport->rstc);
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -3521,8 +3546,18 @@ static __maybe_unused int sci_resume(struct device *dev)
>> {
>> struct sci_port *sport = dev_get_drvdata(dev);
>>
>> - if (sport)
>> + if (sport) {
>> + if (!console_suspend_enabled && uart_console(&sport->port)) {
>> + sci_console_setup(sport, false);
>> + } else {
>> + int ret = reset_control_deassert(sport->rstc);
>
> With this, is the reset_control_deassert() in sci_parse_dt() still
> needed?
If I'm not wrongly understanding your question, yes, the
reset_control_deassert() is still needed in the sci_parse_dt() as the
sci_parse_dt() is called on probe path. After resume the sci_parse_dt() is
not called unless the driver is unbinded and then re-binded.
In case the reset_control_dessert() here fails (or not) and an
unbind/re-bind will be requested, the unbind will call
reset_control_assert() (though the devm action) and then the re-bind will
call reset_control_deassert() though sci_parse_dt(). That should be safe,
AFAICT.
>
> Likewise, does the reset_control_assert() in sci_suspend() remove the
> need for the sci_reset_control_assert() devm action?
No, the sci_reset_control_assert() is still needed as explained above,
unless I missed your point.
Please let me know if missed your point and/or answered your question?
Thank you,
Claudiu Beznea
>
> regards
> Philipp
next prev parent reply other threads:[~2024-11-18 9:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 13:43 [PATCH v3 0/8] Add support for the rest of Renesas RZ/G3S serial interfaces Claudiu
2024-11-15 13:43 ` [PATCH v3 1/8] clk: renesas: r9a08g045: Add clock, reset and power domain for the remaining SCIFs Claudiu
2024-11-27 14:48 ` Geert Uytterhoeven
2024-11-15 13:43 ` [PATCH v3 2/8] serial: sh-sci: Check if TX data was written to device in .tx_empty() Claudiu
2024-11-21 21:32 ` Greg KH
2024-11-22 8:17 ` Claudiu Beznea
2024-11-27 13:47 ` Geert Uytterhoeven
2024-11-27 13:52 ` Claudiu Beznea
2024-11-15 13:43 ` [PATCH v3 3/8] serial: sh-sci: Update the suspend/resume support Claudiu
2024-11-15 15:40 ` Philipp Zabel
2024-11-18 9:47 ` Claudiu Beznea [this message]
2024-11-18 11:51 ` Philipp Zabel
2024-11-15 13:43 ` [PATCH v3 4/8] arm64: dts: renesas: r9a08g045: Add the remaining SCIF interfaces Claudiu
2024-12-06 14:30 ` Geert Uytterhoeven
2024-11-15 13:43 ` [PATCH v3 5/8] arm64: dts: renesas: rzg3s-smarc: Fix the debug serial alias Claudiu
2024-12-06 14:57 ` Geert Uytterhoeven
2024-11-15 13:43 ` [PATCH v3 6/8] arm64: dts: renesas: rzg3s-smarc-switches: Add a header to describe different switches Claudiu
2024-11-19 16:23 ` Rob Herring
2024-12-09 10:09 ` Geert Uytterhoeven
2024-12-09 12:10 ` Claudiu Beznea
2024-11-15 13:44 ` [PATCH v3 7/8] arm64: dts: renesas: rzg3s-smarc: Enable SCIF3 Claudiu
2024-12-09 10:13 ` Geert Uytterhoeven
2024-11-15 13:44 ` [PATCH v3 8/8] arm64: dts: renesas: r9a08g045s33-smarc-pmod: Add overlay for SCIF1 Claudiu
2024-12-09 10:44 ` Geert Uytterhoeven
2024-12-09 12:19 ` Claudiu Beznea
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3153fbd0-189a-4cfc-92cd-a1cc23928d73@tuxon.dev \
--to=claudiu.beznea@tuxon.dev \
--cc=claudiu.beznea.uj@bp.renesas.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=g.liakhovetski@gmx.de \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lethal@linux-sh.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).