From: Grant Edwards <grante@visi.com>
To: linux-serial@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Subject: Re: Suggested patch for linux
Date: Thu, 10 Jul 2008 14:47:56 +0000 (UTC) [thread overview]
Message-ID: <g557er$c32$1@ger.gmane.org> (raw)
In-Reply-To: 20080710095904.16dfdb08@the-village.bc.nu
On 2008-07-10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Stimulated by the RTS signal, the DCE will then engage the
>> channel for transmission and release it, after the RTS has
>> been deasserted when the buffer had been sent. This behaviour
>> is up to now not supported by the linux serial drivers.
>
> Actually you can drive this behaviour from user space
That doesn't generally work. You often can't respond quickly
enough in user space. You need to turn the line around within
as little as a few bit-times. At high baud rates, you simply
can't do that from user space (especially when the UART is
attached via something like USB or Ethernet).
> which is what software like scarabd has done for many years.
>
>> If you see a chance, to add this functionality for future
>> linux kernels, I would be interested in further discussions
>> about this patch.
>
> The big problem is that the kernel does not know what is a
> "transmission" it just sees a series of writes to the device.
"Transmission" is when the UART is sending data (when the shift
register is not empty).
> In many cases the multi-drop or radio systems also need the
> caller to wait for a transmission slot either by beacon, by
> timing or by monitoring the carrier detect to avoid
> collisions.
That's obviously beyond the scope of the serial driver.
Controlling RTS in half-duplex mode isn't.
> That seems to best be done in user space as the algorithms are
> quite variable and some are complex.
>
> Do we really benefit from having this in kernel ?
People who do industrial communications sure would. I maintain
a couple serial drivers that support half-duplex mode exactly
as described by the OP, and we have to control that feature via
non-standard hacks.
In the past, I added half-duplex mode support into the standard
Linux 16x50 driver, but could never get it to work reliably
across various chipsets (PC motherboard UART designs don't all
seem to set the shift register empty bit at the same time).
If there was at least a standard way to enable half-duplex
mode, it would be easier to support on hardware that correctly
implements RTS control for half-duplex operation.
--
Grant Edwards grante Yow! Here we are in America
at ... when do we collect
visi.com unemployment?
next prev parent reply other threads:[~2008-07-10 14:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 23:16 Suggested patch for linux Axel Hosemann
[not found] ` <487546D5.8050908-3sKltW3hOZofv37vnLkPlQ@public.gmane.org>
2008-07-10 8:59 ` Alan Cox
2008-07-10 14:16 ` Matt Schulte
2008-07-12 21:49 ` Axel Hosemann
2008-07-12 22:33 ` Alan Cox
2008-07-15 20:43 ` Matt Schulte
[not found] ` <1860bbce0807151343rf5cf4apecdc422ba747dd7d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-15 20:46 ` Alan Cox
2008-07-18 10:19 ` Laurent Pinchart
2008-07-18 13:55 ` Grant Edwards
2008-07-10 14:47 ` Grant Edwards [this message]
2008-08-04 13:28 ` Tosoni
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='g557er$c32$1@ger.gmane.org' \
--to=grante@visi.com \
--cc=linux-serial@vger.kernel.org \
--cc=linux-usb@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;
as well as URLs for NNTP newsgroup(s).