From: Greg KH <gregkh@linuxfoundation.org>
To: "Tomáš Mudruňka" <tomas.mudrunka@gmail.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: Precise timing in ldisc? tty_put_char() in hrtimer context?
Date: Tue, 7 Jan 2025 19:20:55 +0100 [thread overview]
Message-ID: <2025010732-creation-confound-d3fa@gregkh> (raw)
In-Reply-To: <CAH2-hcJVhxubEsRciMSrp2x4WyDrmmYNe0Db9-LzXkiRpBQ0iQ@mail.gmail.com>
On Tue, Jan 07, 2025 at 07:07:42PM +0100, Tomáš Mudruňka wrote:
> Hello,
> i am implementing niche rs485-based serial protocol as a tty line
> discipline linux module. Requirement is to hit transmission window
> with precision in low hundreds of microseconds (eg. +-200 uS).
> Transmit window starts 500 uS after message is received.
>
> It seems that hardware driver calls tty_receive_buf2() with sufficient
> latency, so my idea was to start hrtimer using hrtimer_start() inside
> of tty_receive_buf2(). And then in hrtimer handler call
> for(...){tty_put_char(tty,...)} or tty->ops->write(), but it seems not
> to be a good practice according to my online research. They say it's
> recommended to call tty_put_char() from workqueue, but documentation
> also says that calling a workqueue might introduce latency of couple
> milliseconds, since it's scheduled thread context.
>
> What would you suggest to handle such a strict timing requirements
> between RX and TX data?
Use a different protocol or hardware implementation as having to be
forced to ensure that UART flows actually work that fast is going to be
very difficult for you to guarantee. Just think, how do you know that
once the UART gets your byte, that it will not just sit around and wait
before it actually sends it out (hint, there is no such guarantee).
good luck!
greg k-h
next prev parent reply other threads:[~2025-01-07 18:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 18:07 Precise timing in ldisc? tty_put_char() in hrtimer context? Tomáš Mudruňka
2025-01-07 18:20 ` Greg KH [this message]
2025-01-07 18:44 ` Tomáš Mudruňka
2025-01-08 12:56 ` Theodore Ts'o
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=2025010732-creation-confound-d3fa@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-serial@vger.kernel.org \
--cc=tomas.mudrunka@gmail.com \
/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