From: Claudiu Beznea <claudiu.beznea@tuxon.dev>
To: Jiri Slaby <jirislaby@kernel.org>,
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,
p.zabel@pengutronix.de, g.liakhovetski@gmx.de,
lethal@linux-sh.org
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>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 2/8] serial: sh-sci: Check if TX data was written to device in .tx_empty()
Date: Thu, 14 Nov 2024 10:11:27 +0200 [thread overview]
Message-ID: <20138ae9-ce35-40a5-be10-d0c6da23f5d1@tuxon.dev> (raw)
In-Reply-To: <b3f67cd7-056a-43c2-98dc-e983649124ed@kernel.org>
Hi, Jiri,
On 14.11.2024 08:26, Jiri Slaby wrote:
> Hi,
>
> On 08. 11. 24, 13:19, Claudiu Beznea wrote:
>> On 08.11.2024 12:57, Jiri Slaby wrote:
>>> On 08. 11. 24, 11:05, Claudiu wrote:
> ...
>>>> --- a/drivers/tty/serial/sh-sci.c
>>>> +++ b/drivers/tty/serial/sh-sci.c
>>>> @@ -157,6 +157,7 @@ struct sci_port {
>>>> bool has_rtscts;
>>>> bool autorts;
>>>> + bool first_time_tx;
>>>
>>> This is a misnomer. It suggests to be set only during the first TX.
>>
>> I chose this naming as this was the scenario I discovered it didn't work.
>> Reproducible though these steps:
>>
>> 1/ open the serial device (w/o running any TX/RX)
>> 2/ call tx_empty()
>>
>> What
>>> about ::did_tx, ::performed_tx, ::transmitted, or alike?
>>
>> I have nothing against any of these. Can you please let me know if you have
>> a preferred one?
>
> No, you choose, or invent even better one :). Or let AI do it for you.
>
>>>> @@ -885,6 +887,7 @@ static void sci_transmit_chars(struct uart_port *port)
>>>> }
>>>> sci_serial_out(port, SCxTDR, c);
>>>> + s->first_time_tx = true;
>>>> port->icount.tx++;
>>>> } while (--count > 0);
>>>> @@ -1241,6 +1244,8 @@ static void sci_dma_tx_complete(void *arg)
>>>> if (kfifo_len(&tport->xmit_fifo) < WAKEUP_CHARS)
>>>> uart_write_wakeup(port);
>>>> + s->first_time_tx = true;
>>>
>>> This is too late IMO. The first in-flight dma won't be accounted in
>>> sci_tx_empty(). From DMA submit up to now.
>>
>> If it's in-flight we can't determine it's status anyway with one variable.
>> We can set this variable later but it wouldn't tell the truth as the TX
>> might be in progress anyway or may have been finished?
>>
>> The hardware might help with this though the TEND bit. According to the HW
>> manual, the TEND bit has the following meaning:
>>
>> 0: Transmission is in the waiting state or in progress.
>> 1: Transmission is completed.
>>
>> But the problem, from my point of view, is that the 0 has double meaning.
>>
>> I noticed the tx_empty() is called in kernel multiple times before
>> declaring TX is empty or not. E.g., uart_suspend_port() call it 3 times,
>> uart_wait_until_sent() call it in a while () look with a timeout. There is
>> the uart_ioctl() which calls it though uart_get_lsr_info() only one time
>> but I presumed the user space might implement the same multiple trials
>> approach before declaring it empty.
>>
>> Because of this I considered it wouldn't be harmful for the scenario you
>> described "The first in-flight dma won't be accounted in sci_tx_empty()"
>> as the user may try again later to check the status. For this reason I also
>> chose to have no extra locking around this variable.
>
> What about the below?
>
>>>> @@ -2076,6 +2081,10 @@ static unsigned int sci_tx_empty(struct uart_port
>>>> *port)
>>>> {
>>>> unsigned short status = sci_serial_in(port, SCxSR);
>>>> unsigned short in_tx_fifo = sci_txfill(port);
>>>> + struct sci_port *s = to_sci_port(port);
>>>> +
>>>> + if (!s->first_time_tx)
>>>> + return TIOCSER_TEMT;
>>>
>>> So perhaps check if there is a TX DMA running here too?
>
> This ^^^? Like dmaengine_tx_status()?
I missed that I can use this ^. Thanks for pointing it.
Claudiu
>
>>>
>>>> return (status & SCxSR_TEND(port)) && !in_tx_fifo ? TIOCSER_TEMT
>>>> : 0;
>>>> }
>>>
>>> thanks,
next prev parent reply other threads:[~2024-11-14 8:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 10:05 [PATCH v2 0/8] Add support for the rest of Renesas RZ/G3S serial interfaces Claudiu
2024-11-08 10:05 ` [PATCH v2 1/8] clk: renesas: r9a08g045: Add clock, reset and power domain for the remaining SCIFs Claudiu
2024-11-08 10:05 ` [PATCH v2 2/8] serial: sh-sci: Check if TX data was written to device in .tx_empty() Claudiu
2024-11-08 10:57 ` Jiri Slaby
2024-11-08 12:19 ` Claudiu Beznea
2024-11-12 8:35 ` Claudiu Beznea
2024-11-14 6:26 ` Jiri Slaby
2024-11-14 6:29 ` Jiri Slaby
2024-11-14 8:11 ` Claudiu Beznea [this message]
2024-11-08 10:05 ` [PATCH v2 3/8] serial: sh-sci: Update the suspend/resume support Claudiu
2024-11-08 10:05 ` [PATCH v2 4/8] arm64: dts: renesas: r9a08g045: Add the remaining SCIF interfaces Claudiu
2024-11-08 10:05 ` [PATCH v2 5/8] arm64: dts: renesas: rzg3s-smarc: Fix the debug serial alias Claudiu
2024-11-08 10:05 ` [PATCH v2 6/8] arm64: dts: renesas: rzg3s-smarc-switches: Add a header to describe different switches Claudiu
2024-11-08 10:05 ` [PATCH v2 7/8] arm64: dts: renesas: rzg3s-smarc: Enable SCIF3 Claudiu
2024-11-08 10:05 ` [PATCH v2 8/8] arm64: dts: renesas: r9a08g045s33-smarc-pmod: Add overlay for SCIF1 Claudiu
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=20138ae9-ce35-40a5-be10-d0c6da23f5d1@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 \
--cc=stable@vger.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