LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Ivan Šištík - 3K Solutions, s. r. o." <firstname.lastname@example.org>
To: Lukas Wunner <email@example.com>
Cc: Russell King <firstname.lastname@example.org>,
Florian Fainelli <email@example.com>,
Ray Jui <firstname.lastname@example.org>,
Scott Branden <email@example.com>,
Eric Anholt <firstname.lastname@example.org>,
Stefan Wahren <email@example.com>,
Greg Kroah-Hartman <firstname.lastname@example.org>,
Jiri Slaby <email@example.com>,
Nicolas Saenz Julienne <firstname.lastname@example.org>
Subject: Re: [PATCH] tty: serial: amba-pl011: added RS485 support
Date: Fri, 17 Jan 2020 01:58:57 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 16. 1. 2020 at 14:29 Lukas Wunner wrote:
> So I've implemented rs485 support for amba-pl011.c two years ago
> but the patches need a little more polishing before they can be
> upstreamed and I haven't gotten around to that yet. I apologize
> that it meant you had to reinvent the wheel.
> You can find my implementation on this branch:
> Specifically this commit:
The wheel with octagonal shape is still not perfect. I made it more
smoother. Your implementation in recommended commit use an active
waiting (pl011_rs485_tx_start, pl011_rs485_tx_stop) and that could
cause lots of problems in upper layers of tty driver or application.
I think you forgot to implement possibility to start TX during
"delay after send", too.
> You've used hrtimers in case delays are necessary after assertion
> or before deassertion of RTS. Note that 8250_port.c already contains
> code for that. If one wants to go that route, it would probably be
> best to move that code into serial_core.c to make it available to
> non-8250 ports.
The 8250_port.c use DMA. Do you thin that it shoud be moved to
serial_core.c? If there will be default implementation of handling
RTS by serial_core.c using timers, than I will refactor this driver
to use it.
> I took a completely different approach: I converted amba-pl011.c
> to threaded interrupt handling using two kthreads, one for sending,
> one for receiving. This allows simultaneous writing to and reading
> from the FIFO. The driver keeps track of the FIFO fill level,
> which allows writing to the FIFO blindly. The hardirq handler
> updates the fill level counter and wakes either of the IRQ threads.
I do not see any used thread in link:
I am not kernel thread expert but I think that thread is not as
lightweight as hrtimer. According to my knowledge the hrtimer use some
kind of interrupt. Compare to this the kthread is created as thread
with all its scheduling structures. Did you implemented proper thread
shutdown? Has the thread right priority? There are many questions
> Once the driver was converted to threaded interrupts, it became
> possible to sleep in the IRQ handler, so I just used msleep()
> for the RTS delays.
I think that thread with main purpose to wait is waist of resources.
This kind of task should be handled by timers. I saw this passion for
threads in Windows CE 6 drivers. Did you read some of them?
> The tty layer lets you know when there's nothing more to transmit by
> calling the ->stop_tx() hook. Then you just busy-wait for the FIFO
> to empty before you deassert RTS.
This would be wasting of CPU time and as I mentioned above it can cause
problems in above layers. Busy-wait in any method require deep
knowledge of "caller".
> Another idea would be to set TXIFLSEL (TX interrupt FIFO level select)
> in the UARTIFLS register to the lowest possible setting. Then you'll
> get an interrupt when the TX FIFO only contains 2 bytes (on a PL011
> with 16 byte FIFOs), thus minimizing the busy-wait duration.
TX interrupt is used by other parts of driver. I would not recommend to
change this behavior without complete analysis of buffer refill timing.
There can be some devices which can be "IDLE" sensitive. This devices
would not work properly on higher baud rates.
I do not use busy-wait in timer tick. If there is data in FIFO I do not
stop timer and let it tick one more time.
next prev parent reply other threads:[~2020-01-17 0:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-06 23:52 Ivan Sistik
2020-01-07 7:27 ` Greg Kroah-Hartman
2020-01-17 0:31 ` Ivan Sistik - 3K Solutions, s. r. o.
2020-01-07 7:28 ` Greg Kroah-Hartman
2020-01-16 13:29 ` Lukas Wunner
2020-01-17 0:58 ` Ivan Šištík - 3K Solutions, s. r. o. [this message]
2020-01-21 8:49 ` Lukas Wunner
2020-12-21 23:18 Ivan Sistik
2020-12-28 15:13 ` Greg Kroah-Hartman
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH] tty: serial: amba-pl011: added RS485 support' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).