[PATCH/RFC] 8250: Auto RS485 direction control

[PATCH/RFC] 8250: Auto RS485 direction control

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

This patch adds support for the automatic RS485 direction control feature
present in 16850 UARTs.

A new termios c_cflag, CARTS, is introduced to configure automatic direction
control from userspace.

This is a first proposal. I'm open to suggestions regarding the CARTS name.
I assume the CARTS flag will have to be added to all asm/termbits.h headers.
Why are the termios bits definitions platform specific ?

---
 drivers/serial/8250.c          |   14 ++++++++++++++
 include/asm-powerpc/termbits.h |    1 +
 include/linux/serial_reg.h     |    1 +
 3 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 62a2e49..a1351d5 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2071,6 +2071,20 @@ serial8250_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (up->port.type == PORT_16750)
 		serial_outp(up, UART_FCR, fcr);
 
+#ifdef CARTS
+	/* Auto RS485 Direction Control on 16850 UARTs */
+	if (up->port.type == PORT_16850) {
+		unsigned char fctr;
+
+		serial_outp(up, UART_LCR, 0xbf);
+		fctr = serial_inp(up, UART_FCTR) & ~UART_FCTR_RS485;
+		if (termios->c_cflag & CARTS)
+			fctr |= UART_FCTR_RS485;
+		serial_outp(up, UART_FCTR, fctr);
+		serial_outp(up, UART_LCR, 0);
+	}
+#endif
+
 	serial_outp(up, UART_LCR, cval);		/* reset DLAB */
 	up->lcr = cval;					/* Save LCR */
 	if (up->port.type != PORT_16750) {
diff --git a/include/asm-powerpc/termbits.h b/include/asm-powerpc/termbits.h
index 5e79198..7b7ee27 100644
--- a/include/asm-powerpc/termbits.h
+++ b/include/asm-powerpc/termbits.h
@@ -166,6 +166,7 @@ struct ktermios {
 #define HUPCL	00040000
 
 #define CLOCAL	00100000
+#define CARTS	  004000000000		/* auto RTS control */
 #define CMSPAR	  010000000000		/* mark or space (stick) parity */
 #define CRTSCTS	  020000000000		/* flow control */
 
diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index 3c8a6aa..3db78cc 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -188,6 +188,7 @@
 #define UART_FCTR_RTS_8DELAY	0x03
 #define UART_FCTR_IRDA		0x04  /* IrDa data encode select */
 #define UART_FCTR_TX_INT	0x08  /* Tx interrupt type select */
+#define UART_FCTR_RS485		0x08  /* Auto RS485 direction control */
 #define UART_FCTR_TRGA		0x00  /* Tx/Rx 550 trigger table select */
 #define UART_FCTR_TRGB		0x10  /* Tx/Rx 650 trigger table select */
 #define UART_FCTR_TRGC		0x20  /* Tx/Rx 654 trigger table select */
-- 
1.5.0

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Alan Cox]

On Thu, 24 Jul 2008 13:47:29 +0200
Laurent Pinchart <laurentp@cse-semaphore.com> wrote:

> This patch adds support for the automatic RS485 direction control feature
> present in 16850 UARTs.
> 
> A new termios c_cflag, CARTS, is introduced to configure automatic direction
> control from userspace.
> 
> This is a first proposal. I'm open to suggestions regarding the CARTS name.
> I assume the CARTS flag will have to be added to all asm/termbits.h headers.
> Why are the termios bits definitions platform specific ?

Because many of them are made to match up with the existing previous
OS on those systems (eg to match with Alpha OSF).

I've no fundamental objection to this but I do wonder whether this
feature belongs in setserial rather than termios as it is so chip
specific ?

Alan

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Russell King]

On Thu, Jul 24, 2008 at 12:57:06PM +0100, Alan Cox wrote:
> On Thu, 24 Jul 2008 13:47:29 +0200
> Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
> 
> > This patch adds support for the automatic RS485 direction control feature
> > present in 16850 UARTs.
> > 
> > A new termios c_cflag, CARTS, is introduced to configure automatic direction
> > control from userspace.
> > 
> > This is a first proposal. I'm open to suggestions regarding the CARTS name.
> > I assume the CARTS flag will have to be added to all asm/termbits.h headers.
> > Why are the termios bits definitions platform specific ?
> 
> Because many of them are made to match up with the existing previous
> OS on those systems (eg to match with Alpha OSF).
> 
> I've no fundamental objection to this but I do wonder whether this
> feature belongs in setserial rather than termios as it is so chip
> specific ?

It may be specific to certain chips, but of those drivers which support
hardware RS485 modes to date, everyone has invented their own ioctl to
switch to RS485 mode.  There's no unification between any of the serial
drivers for this.

On devices which don't support hardware RS485, what should be done is
the termios bit remains clear, so that programs can tell if the port
doesn't support it (as per POSIX.)

I would also stress that this feature should be limited to enabling
_hardware_ RS485 support, and not software emulation of that.  The
reason being is that with plain 16550 UARTs, the best you can do 
with interrupts is to know when the last character is transferred out
of the transmit holding register into the transmit shift register - in
other words, before the last character has finished transmission.

Knowing when that character has been transmitted involves polling the
LSR - and having the kernel sit in a loop waiting for that event is
extremely wasteful.  Scheduling to other processes... well, you don't
know if there's some timing constraint - eg, must deassert RTS 1us
after the stop bit of the last character.

Basically, software RS485 is very yucky, and we've always resisted
having that support in the kernel.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Alan Cox]

> On devices which don't support hardware RS485, what should be done is
> the termios bit remains clear, so that programs can tell if the port
> doesn't support it (as per POSIX.)

Or the serial layer should do it in software.

> I would also stress that this feature should be limited to enabling
> _hardware_ RS485 support, and not software emulation of that.  The
> reason being is that with plain 16550 UARTs, the best you can do 
> with interrupts is to know when the last character is transferred out
> of the transmit holding register into the transmit shift register - in
> other words, before the last character has finished transmission.

So the 16550 sucks, that's not true of everyone elses uarts.

> Basically, software RS485 is very yucky, and we've always resisted
> having that support in the kernel.

Agreed entirely. Which takes us more and more to the setserial path even
if it means standardising some setserial bit to get everyone back in line.

Alan

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Russell King]

On Thu, Jul 24, 2008 at 01:27:46PM +0100, Alan Cox wrote:
> > On devices which don't support hardware RS485, what should be done is
> > the termios bit remains clear, so that programs can tell if the port
> > doesn't support it (as per POSIX.)
> 
> Or the serial layer should do it in software.
> 
> > I would also stress that this feature should be limited to enabling
> > _hardware_ RS485 support, and not software emulation of that.  The
> > reason being is that with plain 16550 UARTs, the best you can do 
> > with interrupts is to know when the last character is transferred out
> > of the transmit holding register into the transmit shift register - in
> > other words, before the last character has finished transmission.
> 
> So the 16550 sucks, that's not true of everyone elses uarts.

It's true of all 8250 compatibles which don't have hardware RS485
support.  I think that's all of them except 16850 and 16960.

> > Basically, software RS485 is very yucky, and we've always resisted
> > having that support in the kernel.
> 
> Agreed entirely. Which takes us more and more to the setserial path even
> if it means standardising some setserial bit to get everyone back in line.

I don't have a problem with that, except one question: CRTSCTS.

A while back, there were people asking for:
1. handshaking on DTR/DSR rather than RTS/CTS.
2. a different handshaking method for RTS/CTS (where you assert
   RTS to ask for permission to send when you actually have something
   to send.)

Should CRTSCTS be a global "enable some kind of flow control" bit and
setserial be used to configure the actual flow control method
(conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
RS485 on DTR) ?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Alan Cox]

> > So the 16550 sucks, that's not true of everyone elses uarts.
> 
> It's true of all 8250 compatibles which don't have hardware RS485
> support.  I think that's all of them except 16850 and 16960.

Its not true of a lot of other uart devices however.

> A while back, there were people asking for:
> 1. handshaking on DTR/DSR rather than RTS/CTS.
> 2. a different handshaking method for RTS/CTS (where you assert
>    RTS to ask for permission to send when you actually have something
>    to send.)
> 
> Should CRTSCTS be a global "enable some kind of flow control" bit and
> setserial be used to configure the actual flow control method
> (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
> RS485 on DTR) ?

I've actually been trying to find out how other Unixen handle DTR/DSR and
not had any luck finding a sensible common interface for it.

Alan

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

On Thursday 24 July 2008, Russell King wrote:
> On Thu, Jul 24, 2008 at 01:27:46PM +0100, Alan Cox wrote:
> > > On devices which don't support hardware RS485, what should be done is
> > > the termios bit remains clear, so that programs can tell if the port
> > > doesn't support it (as per POSIX.)
> > 
> > Or the serial layer should do it in software.
> > 
> > > I would also stress that this feature should be limited to enabling
> > > _hardware_ RS485 support, and not software emulation of that.  The
> > > reason being is that with plain 16550 UARTs, the best you can do 
> > > with interrupts is to know when the last character is transferred out
> > > of the transmit holding register into the transmit shift register - in
> > > other words, before the last character has finished transmission.
> > 
> > So the 16550 sucks, that's not true of everyone elses uarts.
> 
> It's true of all 8250 compatibles which don't have hardware RS485
> support.  I think that's all of them except 16850 and 16960.
> 
> > > Basically, software RS485 is very yucky, and we've always resisted
> > > having that support in the kernel.

I agree as well. Implementing various type of flow control emulation would require some kind of real-time support and lots of hacks to work around hardware issues. The serial core is complex enough as it is today.

> > Agreed entirely. Which takes us more and more to the setserial path even
> > if it means standardising some setserial bit to get everyone back in line.
> 
> I don't have a problem with that, except one question: CRTSCTS.
> 
> A while back, there were people asking for:
> 1. handshaking on DTR/DSR rather than RTS/CTS.
> 2. a different handshaking method for RTS/CTS (where you assert
>    RTS to ask for permission to send when you actually have something
>    to send.)
> 
> Should CRTSCTS be a global "enable some kind of flow control" bit and
> setserial be used to configure the actual flow control method
> (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
> RS485 on DTR) ?

That sounds nice, although the CRTSCTS will not mean much anymore. I suppose the new setserial option will have a 'RTS/CTS handshake' default value, so that current drivers will exhibit the correct behaviour.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Matt Schulte]

Russell King wrote:
> 
> It's true of all 8250 compatibles which don't have hardware RS485
> support.  I think that's all of them except 16850 and 16960.
> 

Just for the sake of completeness, the Oxford Semi 16c950 also has 
hardare 485 control, as do Exar's PCI based 17d15x UARTs.


Matt Schulte
Commtech, Inc.

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Russell King]

On Thu, Jul 24, 2008 at 09:13:34AM -0500, Matt Schulte wrote:
> Russell King wrote:
> >
> >It's true of all 8250 compatibles which don't have hardware RS485
> >support.  I think that's all of them except 16850 and 16960.
> >
> 
> Just for the sake of completeness, the Oxford Semi 16c950 also has 
> hardare 485 control, as do Exar's PCI based 17d15x UARTs.

For the elimination of confusion, that '960' was a typo - it should've
been 950, since it was the set of Oxford 950 devices I was referring to.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Russell King]

On Thu, Jul 24, 2008 at 01:47:29PM +0200, Laurent Pinchart wrote:
> This patch adds support for the automatic RS485 direction control feature
> present in 16850 UARTs.
> 
> A new termios c_cflag, CARTS, is introduced to configure automatic direction
> control from userspace.
> 
> This is a first proposal. I'm open to suggestions regarding the CARTS name.

I think CARTS is a bad name - if you look at other 8250 ports, they have
auto-flow control for normal communications which not only includes
stopping the transmitter when CTS deasserts, but also allows the device
to deassert RTS when the receive FIFO reaches a certain level.

That means that the name "auto RTS" is confusing.

Maybe a better name would be CRS485 to enable RS485 direction control?
Then we can use CRTSCTS to mean "on the RTS signal".  If/when a
CDTRDSR for DTR/DSR flow control is introduced, we could then use
that to switch to DTR RS485 direction control instead.

> I assume the CARTS flag will have to be added to all asm/termbits.h
> headers.

Yes...

> Why are the termios bits definitions platform specific ?

... though if you can find a free bit in the cflag on all platforms,
creating an asm-generic/termbits.h might be a good idea?

Alan should probably comment on that first though.

> diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
> index 3c8a6aa..3db78cc 100644
> --- a/include/linux/serial_reg.h
> +++ b/include/linux/serial_reg.h
> @@ -188,6 +188,7 @@
>  #define UART_FCTR_RTS_8DELAY	0x03
>  #define UART_FCTR_IRDA		0x04  /* IrDa data encode select */
>  #define UART_FCTR_TX_INT	0x08  /* Tx interrupt type select */
> +#define UART_FCTR_RS485		0x08  /* Auto RS485 direction control */

Please include in the comment which device this refers to (as the entries
below do.)

>  #define UART_FCTR_TRGA		0x00  /* Tx/Rx 550 trigger table select */
>  #define UART_FCTR_TRGB		0x10  /* Tx/Rx 650 trigger table select */
>  #define UART_FCTR_TRGC		0x20  /* Tx/Rx 654 trigger table select */

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Tosoni]

About the flags names -- CARTS, UART_FCTR_RS485

May I suggest CRTSTOGGLE since it is known by that kind of name in other
OS's :-)

And further, it says was RTS will do, instead of why. Maybe someone could
use it for something other than RS485 ?

Regards

JP Tosoni

> -----Original Message-----
> From: linux-serial-owner@vger.kernel.org
> [mailto:linux-serial-owner@vger.kernel.org]On Behalf Of
> Laurent Pinchart
> Sent: Thursday, July 24, 2008 1:47 PM
> To: linux-serial@vger.kernel.org
> Cc: Alan Cox; rmk@arm.linux.org.uk
> Subject: [PATCH/RFC] 8250: Auto RS485 direction control
>
>
> This patch adds support for the automatic RS485 direction
> control feature
> present in 16850 UARTs.
>
> A new termios c_cflag, CARTS, is introduced to configure
> automatic direction
> control from userspace.
>
> This is a first proposal. I'm open to suggestions regarding
> the CARTS name.
> I assume the CARTS flag will have to be added to all
> asm/termbits.h headers.
> Why are the termios bits definitions platform specific ?
>
> ---
>  drivers/serial/8250.c          |   14 ++++++++++++++
>  include/asm-powerpc/termbits.h |    1 +
>  include/linux/serial_reg.h     |    1 +
>  3 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 62a2e49..a1351d5 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -2071,6 +2071,20 @@ serial8250_set_termios(struct
> uart_port *port, struct ktermios *termios,
>  	if (up->port.type == PORT_16750)
>  		serial_outp(up, UART_FCR, fcr);
>
> +#ifdef CARTS
> +	/* Auto RS485 Direction Control on 16850 UARTs */
> +	if (up->port.type == PORT_16850) {
> +		unsigned char fctr;
> +
> +		serial_outp(up, UART_LCR, 0xbf);
> +		fctr = serial_inp(up, UART_FCTR) & ~UART_FCTR_RS485;
> +		if (termios->c_cflag & CARTS)
> +			fctr |= UART_FCTR_RS485;
> +		serial_outp(up, UART_FCTR, fctr);
> +		serial_outp(up, UART_LCR, 0);
> +	}
> +#endif
> +
>  	serial_outp(up, UART_LCR, cval);		/* reset DLAB */
>  	up->lcr = cval;					/* Save LCR */
>  	if (up->port.type != PORT_16750) {
> diff --git a/include/asm-powerpc/termbits.h
> b/include/asm-powerpc/termbits.h
> index 5e79198..7b7ee27 100644
> --- a/include/asm-powerpc/termbits.h
> +++ b/include/asm-powerpc/termbits.h
> @@ -166,6 +166,7 @@ struct ktermios {
>  #define HUPCL	00040000
>
>  #define CLOCAL	00100000
> +#define CARTS	  004000000000		/* auto RTS control */
>  #define CMSPAR	  010000000000		/* mark or
> space (stick) parity */
>  #define CRTSCTS	  020000000000		/* flow control */
>
> diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
> index 3c8a6aa..3db78cc 100644
> --- a/include/linux/serial_reg.h
> +++ b/include/linux/serial_reg.h
> @@ -188,6 +188,7 @@
>  #define UART_FCTR_RTS_8DELAY	0x03
>  #define UART_FCTR_IRDA		0x04  /* IrDa data
> encode select */
>  #define UART_FCTR_TX_INT	0x08  /* Tx interrupt type select */
> +#define UART_FCTR_RS485		0x08  /* Auto RS485
> direction control */
>  #define UART_FCTR_TRGA		0x00  /* Tx/Rx 550
> trigger table select */
>  #define UART_FCTR_TRGB		0x10  /* Tx/Rx 650
> trigger table select */
>  #define UART_FCTR_TRGC		0x20  /* Tx/Rx 654
> trigger table select */
> --
> 1.5.0
>
> --
> Laurent Pinchart
> CSE Semaphore Belgium
>
> Chaussee de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
>

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Grant Edwards]

On 2008-08-04, Tosoni <jp.tosoni@acksys.fr> wrote:
> About the flags names -- CARTS, UART_FCTR_RS485
>
> May I suggest CRTSTOGGLE since it is known by that kind of name in other
> OS's :-)

RTS toggle is what the feature is called in the products I work
on.  I assume that's a microsoftism, but it seems to be in
commmon usage.

> And further, it says was RTS will do, instead of why. Maybe
> someone could use it for something other than RS485?

Sure.  It's also used for half-duplex modems (e.g. Bell-202,
various RF comm modules) and other sorts of line drivers (e.g.
optical stuff).

-- 
Grant Edwards                   grante             Yow! I want to kill
                                  at               everyone here with a cute
                               visi.com            colorful Hydrogen Bomb!!

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Monday 04 August 2008, Tosoni wrote:
> About the flags names -- CARTS, UART_FCTR_RS485
> 
> May I suggest CRTSTOGGLE since it is known by that kind of name in other
> OS's :-)

I like Russell's proposal of sticking to CRTSCTS and adding options to setserial:

> Should CRTSCTS be a global "enable some kind of flow control" bit and
> setserial be used to configure the actual flow control method
> (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
> RS485 on DTR) ?

Any opinion on that ?

> And further, it says was RTS will do, instead of why. Maybe someone could
> use it for something other than RS485 ?

I agree with you here. The name should reflect that RTS is used in 'envelope' mode (asserted during data transmission, idle between frames).

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Grant Edwards]

On 2008-08-04, Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
> On Monday 04 August 2008, Tosoni wrote:
>> About the flags names -- CARTS, UART_FCTR_RS485
>> 
>> May I suggest CRTSTOGGLE since it is known by that kind of name in other
>> OS's :-)
>
> I like Russell's proposal of sticking to CRTSCTS and adding options to setserial:
>
>> Should CRTSCTS be a global "enable some kind of flow control" bit and
>> setserial be used to configure the actual flow control method
>> (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
>> RS485 on DTR) ?
>
> Any opinion on that ?

Opposed.

 1) CRTSCTS means something quite specific.  Rather than
    overload that name for something unrelated, create a new
    mode bit for the new mode.

 2) Most of what's in setserial is useless and irrelevent to
    non-PC-motherboard-16550-uart serial ports (the drivers for
    which often don't support setserial).

Let's just suck it up and do it the right way.
    
>> And further, it says was RTS will do, instead of why. Maybe
>> someone could use it for something other than RS485 ?
>
> I agree with you here. The name should reflect that RTS is
> used in 'envelope' mode (asserted during data transmission,
> idle between frames).

I don't really care what the name is.  "RTS toggle" or
"half-duplex" is what everybody I know calls it.

-- 
Grant Edwards                   grante             Yow! Used staples are good
                                  at               with SOY SAUCE!
                               visi.com            

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Grant Edwards]

On 2008-08-04, Grant Edwards <grante@visi.com> wrote:
> On 2008-08-04, Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
>> On Monday 04 August 2008, Tosoni wrote:
>>> About the flags names -- CARTS, UART_FCTR_RS485
>>> 
>>> May I suggest CRTSTOGGLE since it is known by that kind of name in other
>>> OS's :-)
>>
>> I like Russell's proposal of sticking to CRTSCTS and adding options to setserial:
>>
>>> Should CRTSCTS be a global "enable some kind of flow control" bit and
>>> setserial be used to configure the actual flow control method
>>> (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
>>> RS485 on DTR) ?
>>
>> Any opinion on that ?
>
> Opposed.
>
>  1) CRTSCTS means something quite specific.  Rather than
>     overload that name for something unrelated, create a new
>     mode bit for the new mode.

Besides, there are often times when you want _both_ RTS toggle
and CTS flow control.  If both RTS toggle and RTSCTS flow
control are set, the "toggle" function would have priority
control of the RTS pin.

-- 
Grant Edwards                   grante             Yow! Was my SOY LOAF left
                                  at               out in th'RAIN?  It tastes
                               visi.com            REAL GOOD!!

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

On Monday 04 August 2008, Grant Edwards wrote:
> On 2008-08-04, Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
> > On Monday 04 August 2008, Tosoni wrote:
> >> About the flags names -- CARTS, UART_FCTR_RS485
> >> 
> >> May I suggest CRTSTOGGLE since it is known by that kind of name in other
> >> OS's :-)
> >
> > I like Russell's proposal of sticking to CRTSCTS and adding options to
> > setserial:
> >
> >> Should CRTSCTS be a global "enable some kind of flow control" bit and
> >> setserial be used to configure the actual flow control method
> >> (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
> >> RS485 on DTR) ?
> >
> > Any opinion on that ?
> 
> Opposed.
> 
>  1) CRTSCTS means something quite specific.

That's right, and this is my main concern.

>     Rather than overload that name for something unrelated, create a new
>     mode bit for the new mode.

We already have 3 distinct modes for RTS/CTS (see my mail from today 11:23:36 in this thread). If we add DSR/DTR hardware support we can easily get 5 or 6 modes. We will run out of bits in c_cflags.

>  2) Most of what's in setserial is useless and irrelevent to
>     non-PC-motherboard-16550-uart serial ports (the drivers for
>     which often don't support setserial).
> 
> Let's just suck it up and do it the right way.

As the number of bits in c_cflags is not infinite we will need an ioctl to configure the desired hardware handshake mode (as most modes don't control the data flow I'd rather talk about hardware handshake which is a more generic name). We can either use one of the struct serial_struct reserved fields with TIOCSSERIAL, or create another ioctl.

> >> And further, it says was RTS will do, instead of why. Maybe
> >> someone could use it for something other than RS485 ?
> >
> > I agree with you here. The name should reflect that RTS is
> > used in 'envelope' mode (asserted during data transmission,
> > idle between frames).
> 
> I don't really care what the name is.  "RTS toggle" or
> "half-duplex" is what everybody I know calls it.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Tosoni]

> -----Original Message-----
> From: Laurent Pinchart
>
> On Monday 04 August 2008, Grant Edwards wrote:
> > On 2008-08-04, Laurent Pinchart <laurentp@cse-semaphore.com> wrote:

(...)

> We already have 3 distinct modes for RTS/CTS (see my mail
> from today 11:23:36 in this thread). If we add DSR/DTR
> hardware support we can easily get 5 or 6 modes. We will run
> out of bits in c_cflags.
>
The three modes which you identify are
(A) bus direction
(B) send data request (well... RTS=Request To Send :-)) which should be
acknowledged by CTS
(C) input flow control
but, the RTS is widely used for (A)=bus direction BECAUSE it is the same
behaviour than (B)=request to send... because RTS was initially made to set
the "bus direction" in the attached modem.
So the three modes are really 2.

People require the (A+B) usage because is in the RS232 and also in V24
specs. But DTR+DSR handshake, really, it's not standardized in any way nor
in broad use. I don't think this is a real need (my personal opinion). My
company once had a card implementing DTR/DSR flow control, nobody used it
and it has been dropped from newer cards.
If we really want it we could resort to a setserial flag to say "RTS/CTS
flow is implemented with DTR/DSR", but then, why not swapping the pin
cabling on the connector then ?

My conclusion: only one bit is needed in c_cflags.
BUT: think of all the upper APIs (termio, termios, tcset/get... and people
using directly TCSET/TCGET ioctls. I am afraid that changing a single bit in
such a widely used API might break a lot of existing apps.

(...)
>
> As the number of bits in c_cflags is not infinite we will
> need an ioctl to configure the desired hardware handshake
> mode (as most modes don't control the data flow I'd rather
> talk about hardware handshake which is a more generic name).
> We can either use one of the struct serial_struct reserved
> fields with TIOCSSERIAL, or create another ioctl.
>
In the Linux CRIS architecture I've seen an IOCTL doing exactly this, with
extra parameters to set the delays RTS-to-Tx and /Tx-to-/RTS. It sounds like
a non intrusive way of adding the feature.

This would definitely be my preferred way of doing (it's the one which I use
in my 16C950 driver).

JP Tosoni

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Christopher Gibson]

Been a few years since I ran into this issue, but are faced with it
again.  Last time the timing wasn't to critical and I managed to use
user space control of the RTS line to achieve RS485 buffer direction
control.  In this case I had control of the response time of the slave
processor, so got away with it.  This time I haven't got that much
control over the timing of the slave units, and a bit more load on the
Linux system, and a user space solution is just not cutting it.  Have
hacked up a kernel to give me the RTS control I need, but started
working on a more generic (and less CPU wasting) solution.  It was part
of this work that lead me to this mail group, as I was looking for
conventions on how to enable RTS direction control.  It would seem,
looking through this mail list that any convention is yet to be defined
for Linux.

On Tue, 2008-08-05 at 14:55 +0200, Tosoni wrote:
> > -----Original Message-----
> > From: Laurent Pinchart
> (...)
> 
> > We already have 3 distinct modes for RTS/CTS (see my mail
> > from today 11:23:36 in this thread). If we add DSR/DTR
> > hardware support we can easily get 5 or 6 modes. We will run
> > out of bits in c_cflags.
> >
> The three modes which you identify are
> (A) bus direction
> (B) send data request (well... RTS=Request To Send :-)) which should be
> acknowledged by CTS
> (C) input flow control
> but, the RTS is widely used for (A)=bus direction BECAUSE it is the same
> behaviour than (B)=request to send... because RTS was initially made to set
> the "bus direction" in the attached modem.
> So the three modes are really 2.
(--->8---)

The only case above that is actually RS232 is (B), the rest are just
asynchronous serial communications.

Saying that (A) and (B) are the same negates the timing requirements
that (A) may have that are unimportant in (B).

In some situations you can get case (A) from a type (B) implementation
by tying RTS and CTS together, but for other UARTS, this just doesn't
work.  You can end up losing characters that are in the tx shift
register and end of FIFO, or in the other timing extreme, losing the
response from a RS485 slave unit.

I would say that it's important to make the RS485 RTS direction control
mode distinct from the RTS/CTS RS232 hand shaking mode.  I would foresee
that it may be necessary to allow setup of different timing modes, to
allow for example chewing up CPU resources for the sake of fast
direction turn around when using ill conceived UARTS.  (Maybe an ill
conceived UART is just an ART;)  Also if this is to also be useful for
radio communications then it may be necessary to provide a mechanism
where lead in and lead out times can be specified for the control.

As far as IOCTL names go I dislike the CRTSTOGGLE, toggling the RTS line
is an incorrect description of function.  I prefer CARTS as it is not an
incorrect description of function.  CARTS - auto request to send is
rather ambiguous though.  If I was to suggest a name it would be RTSADC
- request to send auto direction control (maybe with a preceding C if it
went into termios cflags).

>From what I can gather through the man pages it seems inappropriate to
add this to termios cflag, though the CRTSCTS flag does set a precedent.
I'm an advocate of the idea of introducing a new IOCTL for setting up
non standard hand-shaking settings.  I would suggest that things that
should be considered in the interface are settings for lead-in and
lead-out timing on the direction line (for the use of radio modems for
example) and means to specify if it's appropriate to have the CPU spin
on the shift register empty flag on the last byte of a block, if RTS
timing really is that critical.

I'm rather excited by the idea that a standard interface for RTS
direction control is going to be introduced.

-- 
Christopher Gibson <chris@toftronix.com.au>

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Tosoni]

> -----Original Message-----
> From: Christopher Gibson
>
> Been a few years since I ran into this issue, but are faced with it
> again.  Last time the timing wasn't to critical and I managed to use
> user space control of the RTS line to achieve RS485 buffer direction
> control.  In this case I had control of the response time of the slave
> processor, so got away with it.  This time I haven't got that much
> control over the timing of the slave units, and a bit more load on the
> Linux system, and a user space solution is just not cutting it.  Have
> hacked up a kernel to give me the RTS control I need, but started
> working on a more generic (and less CPU wasting) solution.
> It was part
> of this work that lead me to this mail group, as I was looking for
> conventions on how to enable RTS direction control.  It would seem,
> looking through this mail list that any convention is yet to
> be defined for Linux.
>
> On Tue, 2008-08-05 at 14:55 +0200, Tosoni wrote:
> > > -----Original Message-----
> > > From: Laurent Pinchart
> > (...)
> >
> > > We already have 3 distinct modes for RTS/CTS (see my mail
> > > from today 11:23:36 in this thread). If we add DSR/DTR
> > > hardware support we can easily get 5 or 6 modes. We will run
> > > out of bits in c_cflags.
> > >
> > The three modes which you identify are
> > (A) bus direction
> > (B) send data request (well... RTS=Request To Send :-))
> which should be
> > acknowledged by CTS
> > (C) input flow control
> > but, the RTS is widely used for (A)=bus direction BECAUSE
> it is the same
> > behaviour than (B)=request to send... because RTS was
> initially made to set
> > the "bus direction" in the attached modem.
> > So the three modes are really 2.
> (--->8---)
>
> The only case above that is actually RS232 is (B), the rest are just
> asynchronous serial communications.
>
> Saying that (A) and (B) are the same negates the timing requirements
> that (A) may have that are unimportant in (B).

In an ideal world I do believe that the standard defined
the CTS signal to provide this timing info (from modems).
So, CTS should always be used as a output flow control.

But in the real world I agree that usually the RS485
does not provide such signaling.

>
> In some situations you can get case (A) from a type (B) implementation
> by tying RTS and CTS together, but for other UARTS, this just doesn't
> work.  You can end up losing characters that are in the tx shift
> register and end of FIFO, or in the other timing extreme, losing the
> response from a RS485 slave unit.
>
> I would say that it's important to make the RS485 RTS
> direction control
> mode distinct from the RTS/CTS RS232 hand shaking mode.  I
> would foresee
> that it may be necessary to allow setup of different timing modes, to
> allow for example chewing up CPU resources for the sake of fast
> direction turn around when using ill conceived UARTS.  (Maybe an ill
> conceived UART is just an ART;)  Also if this is to also be useful for
> radio communications then it may be necessary to provide a mechanism
> where lead in and lead out times can be specified for the control.
>
> As far as IOCTL names go I dislike the CRTSTOGGLE, toggling
> the RTS line
> is an incorrect description of function.

It is incorrect only if you introduce the timings. Please note that Windows
has RTS_TOGGLE, no extra timings, and nobody seems to complain.
Wait wait... I am not saying that you are wrong. Last year I had to write a
(non unix) driver to handle these kinks of timings. But the case is not
usual.

>  I prefer CARTS as it is not an
> incorrect description of function.  CARTS - auto request to send is
> rather ambiguous though.  If I was to suggest a name it would
> be RTSADC
> - request to send auto direction control (maybe with a
> preceding C if it
> went into termios cflags).
>
> >From what I can gather through the man pages it seems
> inappropriate to
> add this to termios cflag, though the CRTSCTS flag does set a
> precedent.
> I'm an advocate of the idea of introducing a new IOCTL for setting up
> non standard hand-shaking settings.  I would suggest that things that
> should be considered in the interface are settings for lead-in and
> lead-out timing on the direction line (for the use of radio modems for
> example) and means to specify if it's appropriate to have the CPU spin
> on the shift register empty flag on the last byte of a block, if RTS
> timing really is that critical.

There would be 2 implementations of this ioctl. One for the
zero-timing case which can be handled by some chips (Ox16C950), and
one for the some-timing or old-uart case.

>
> I'm rather excited by the idea that a standard interface for RTS
> direction control is going to be introduced.
>
> --
> Christopher Gibson <chris@toftronix.com.au>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Christopher Gibson]

On Wed, 2008-08-06 at 18:33 +0200, Tosoni wrote:
> 
> > -----Original Message-----
> > From: Christopher Gibson
> >
--- 8< ---
> 
> S.  (Maybe an ill
> > conceived UART is just an ART;)  Also if this is to also be useful
for
> > radio communications then it may be necessary to provide a mechanism
> > where lead in and lead out times can be specified for the control.
> >
> > As far as IOCTL names go I dislike the CRTSTOGGLE, toggling
> > the RTS line
> > is an incorrect description of function.
> 
> It is incorrect only if you introduce the timings. Please note that
Windows
> has RTS_TOGGLE, no extra timings, and nobody seems to complain.
> Wait wait... I am not saying that you are wrong. Last year I had to
write a
> (non unix) driver to handle these kinks of timings. But the case is
not
> usual.
> 

Sorry was being pedantic about naming.  When I said that CRTSTOGGLE was
an incorrect description of function, I was meaning toggle normally
means (in both electronic and mechanical systems) that something
switches between two stable states on application of a signal or force.
(Like the mechanism on the top of a pen to make the nib poke out or
retract.)  For this reason it seems wrong to me call the RTS direction
control a toggle function.

> >  I prefer CARTS as it is not an
> > incorrect description of function.  CARTS - auto request to send is
> > rather ambiguous though.  If I was to suggest a name it would
> > be RTSADC
> > - request to send auto direction control (maybe with a
> > preceding C if it
> > went into termios cflags).

--- 8< ---

On reflection I think I was getting carried away when I suggested adding
timings to the "lead in" and "lead out".  Will discuss this in greater
detail in reply to another email on this thread.

-- 
Christopher Gibson <chris@toftronix.com.au>

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 5425 bytes --]

On Wednesday 06 August 2008, Christopher Gibson wrote:
> Been a few years since I ran into this issue, but are faced with it
> again.  Last time the timing wasn't to critical and I managed to use
> user space control of the RTS line to achieve RS485 buffer direction
> control.  In this case I had control of the response time of the slave
> processor, so got away with it.  This time I haven't got that much
> control over the timing of the slave units, and a bit more load on the
> Linux system, and a user space solution is just not cutting it.  Have
> hacked up a kernel to give me the RTS control I need, but started
> working on a more generic (and less CPU wasting) solution.  It was part
> of this work that lead me to this mail group, as I was looking for
> conventions on how to enable RTS direction control.  It would seem,
> looking through this mail list that any convention is yet to be defined
> for Linux.

That's right. Hopefully we should achieve a consensus on the API soon.

> On Tue, 2008-08-05 at 14:55 +0200, Tosoni wrote:
> > > -----Original Message-----
> > > From: Laurent Pinchart
> > (...)
> > 
> > > We already have 3 distinct modes for RTS/CTS (see my mail
> > > from today 11:23:36 in this thread). If we add DSR/DTR
> > > hardware support we can easily get 5 or 6 modes. We will run
> > > out of bits in c_cflags.
> > >
> > The three modes which you identify are
> > (A) bus direction
> > (B) send data request (well... RTS=Request To Send :-)) which should be
> > acknowledged by CTS
> > (C) input flow control
> > but, the RTS is widely used for (A)=bus direction BECAUSE it is the same
> > behaviour than (B)=request to send... because RTS was initially made to
> > set the "bus direction" in the attached modem.
> > So the three modes are really 2.
> (--->8---)
> 
> The only case above that is actually RS232 is (B), the rest are just
> asynchronous serial communications.

(C) has actually been standardized in TIA-232-E (formerly RS-232-E). See http://en.wikipedia.org/wiki/RS-232

> Saying that (A) and (B) are the same negates the timing requirements
> that (A) may have that are unimportant in (B).
> 
> In some situations you can get case (A) from a type (B) implementation
> by tying RTS and CTS together, but for other UARTS, this just doesn't
> work.  You can end up losing characters that are in the tx shift
> register and end of FIFO, or in the other timing extreme, losing the
> response from a RS485 slave unit.
> 
> I would say that it's important to make the RS485 RTS direction control
> mode distinct from the RTS/CTS RS232 hand shaking mode.  I would foresee
> that it may be necessary to allow setup of different timing modes, to
> allow for example chewing up CPU resources for the sake of fast
> direction turn around when using ill conceived UARTS.  (Maybe an ill
> conceived UART is just an ART;)  Also if this is to also be useful for
> radio communications then it may be necessary to provide a mechanism
> where lead in and lead out times can be specified for the control.

This is getting more complex than I would have thought, although your point is quite valid :-/ I don't think we should implement any hardware handshake mode in software thought. Drivers should export the capabilities of the hardware. If an UART doesn't support mode (A) it's quite pointless to try to emulate it in the driver. Timing requirements will be violated at some point, users will complain, and developers will point out that the software implementation didn't come with any guarantee. Everybody will be disappointed in the end.

Is there any UART that supports lead in/lead out timing configuration in hardware ?

> As far as IOCTL names go I dislike the CRTSTOGGLE, toggling the RTS line
> is an incorrect description of function.  I prefer CARTS as it is not an
> incorrect description of function.  CARTS - auto request to send is
> rather ambiguous though.  If I was to suggest a name it would be RTSADC
> - request to send auto direction control (maybe with a preceding C if it
> went into termios cflags).

Let's first decide where it should go, then we'll try to find appropriate names. The number of free bits in c_cflags is quite limited, so I think a new ioctl is probably required with a new data structure to pass additional data such as timing information in addition to the handshaking mode.

> From what I can gather through the man pages it seems inappropriate to
> add this to termios cflag, though the CRTSCTS flag does set a precedent.
> I'm an advocate of the idea of introducing a new IOCTL for setting up
> non standard hand-shaking settings.  I would suggest that things that
> should be considered in the interface are settings for lead-in and
> lead-out timing on the direction line (for the use of radio modems for
> example) and means to specify if it's appropriate to have the CPU spin
> on the shift register empty flag on the last byte of a block, if RTS
> timing really is that critical.

I don't think we want to introduce software emulation, but feel free to prove me wrong.

> I'm rather excited by the idea that a standard interface for RTS
> direction control is going to be introduced.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Grant Edwards]

On 2008-08-07, Laurent Pinchart <laurentp@cse-semaphore.com> wrote:

>> From what I can gather through the man pages it seems inappropriate to
>> add this to termios cflag, though the CRTSCTS flag does set a precedent.
>> I'm an advocate of the idea of introducing a new IOCTL for setting up
>> non standard hand-shaking settings.  I would suggest that things that
>> should be considered in the interface are settings for lead-in and
>> lead-out timing on the direction line (for the use of radio modems for
>> example) and means to specify if it's appropriate to have the CPU spin
>> on the shift register empty flag on the last byte of a block, if RTS
>> timing really is that critical.
>
> I don't think we want to introduce software emulation, but
> feel free to prove me wrong.

I think that should be left up to the author of the driver.  It
seems to me that it would be pretty difficult to do a decent
job of it at the line-discipline layer.  If the author of the
driver for a particular UART wants to do SW emulation of
auto-RTS, then I think that's where it belongs.  Only the UART
driver knows whether there's a shift-register empty interrupt
(and whether that interrupt happens before or after that final
stop bit has been transmitted).

-- 
Grant Edwards                   grante             Yow! I KAISER ROLL?!
                                  at               What good is a Kaiser Roll
                               visi.com            without a little COLE SLAW
                                                   on the SIDE?

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Christopher Gibson]

On Thu, 2008-08-07 at 10:50 +0200, Laurent Pinchart wrote:
> On Wednesday 06 August 2008, Christopher Gibson wrote:
> > Been a few years since I ran into this issue, but are faced with it
--- >8 ---
> > conventions on how to enable RTS direction control.  It would seem,
> > looking through this mail list that any convention is yet to be defined
> > for Linux.
> 
> That's right. Hopefully we should achieve a consensus on the API soon.
> 
> > On Tue, 2008-08-05 at 14:55 +0200, Tosoni wrote:
> > > > -----Original Message-----
> > > > From: Laurent Pinchart
> > > (...)
> > > 
> > > > We already have 3 distinct modes for RTS/CTS (see my mail
> > > > from today 11:23:36 in this thread). If we add DSR/DTR
> > > > hardware support we can easily get 5 or 6 modes. We will run
> > > > out of bits in c_cflags.
> > > >
> > > The three modes which you identify are
> > > (A) bus direction
> > > (B) send data request (well... RTS=Request To Send :-)) which should be
> > > acknowledged by CTS
> > > (C) input flow control
> > > but, the RTS is widely used for (A)=bus direction BECAUSE it is the same
> > > behaviour than (B)=request to send... because RTS was initially made to
> > > set the "bus direction" in the attached modem.
> > > So the three modes are really 2.
> > (--->8---)
> > 
> > The only case above that is actually RS232 is (B), the rest are just
> > asynchronous serial communications.
> 
> (C) has actually been standardized in TIA-232-E (formerly RS-232-E). See http://en.wikipedia.org/wiki/RS-232

Sorry I stand corrected.

> 
> > Saying that (A) and (B) are the same negates the timing requirements
> > that (A) may have that are unimportant in (B).
> > 
> > In some situations you can get case (A) from a type (B) implementation
> > by tying RTS and CTS together, but for other UARTS, this just doesn't
> > work.  You can end up losing characters that are in the tx shift
> > register and end of FIFO, or in the other timing extreme, losing the
> > response from a RS485 slave unit.
> > 
> > I would say that it's important to make the RS485 RTS direction control
> > mode distinct from the RTS/CTS RS232 hand shaking mode.  I would foresee
> > that it may be necessary to allow setup of different timing modes, to
> > allow for example chewing up CPU resources for the sake of fast
> > direction turn around when using ill conceived UARTS.  (Maybe an ill
> > conceived UART is just an ART;)  Also if this is to also be useful for
> > radio communications then it may be necessary to provide a mechanism
> > where lead in and lead out times can be specified for the control.
> 
> This is getting more complex than I would have thought, although your point is quite valid :-/ I don't think we should implement any hardware handshake mode in software thought. Drivers should export the capabilities of the hardware. If an UART doesn't support mode (A) it's quite pointless to try to emulate it in the driver. Timing requirements will be violated at some point, users will complain, and developers will point out that the software implementation didn't come with any guarantee. Everybody will be disappointed in the end.
> 
> Is there any UART that supports lead in/lead out timing configuration in hardware ?

Think that I was getting carried away with the suggestion of lead/in
lead out timing implementation.  I have seen it implemented in a
proprietary operating system, and it worked quite well, but it was a
software solution, not hardware.  The product was designed specifically
for radio communications.  With the timings required for radios (decent
fractions of seconds), it's not difficult to implement this in user
space, and hard to justify introducing a kernel interface, to support
it.  Also this form of radio communications is an out-dated technology.

I would say that it would be very hard to justify introducing an
interface for these timing controls.

> 
> > As far as IOCTL names go I dislike the CRTSTOGGLE, toggling the RTS line
> > is an incorrect description of function.  I prefer CARTS as it is not an
> > incorrect description of function.  CARTS - auto request to send is
> > rather ambiguous though.  If I was to suggest a name it would be RTSADC
> > - request to send auto direction control (maybe with a preceding C if it
> > went into termios cflags).
> 
> Let's first decide where it should go, then we'll try to find appropriate names. 
> The number of free bits in c_cflags is quite limited, 
> so I think a new ioctl is probably required with a new data structure to 
> pass additional data such as timing information in addition to the handshaking mode.

Was thinking on this.  There are already two bits allocated to use of
handshaking lines in the c_cflags:  CLOCAL and CRTSCTS.  Introducing a
third flag would give a total of 8 different handshaking line mode
possibilities.  If care is taken to ensure backward compatibility with
the CLOCAL and CRTSCTS states you still have the possibility of 4 new
modes.

eg:

#define CFLOW_EXT (08000000)
#define CFLOW	(CLOCAL | CRTSCTS | CFLOW_EXT)
#define CRTSADC (CFLOW_EXT)		/*RTS auto flow control*/
#define CDTRADC (CFLOW_EXT | CLOCAL)	/*DTR auto flow control*/

I don't know if 08000000 is free in all architectures, just throwing up
possiblities.

> 
> > From what I can gather through the man pages it seems inappropriate to
> > add this to termios cflag, though the CRTSCTS flag does set a precedent.
> > I'm an advocate of the idea of introducing a new IOCTL for setting up
> > non standard hand-shaking settings.  I would suggest that things that
> > should be considered in the interface are settings for lead-in and
> > lead-out timing on the direction line (for the use of radio modems for
> > example) and means to specify if it's appropriate to have the CPU spin
> > on the shift register empty flag on the last byte of a block, if RTS
> > timing really is that critical.
> 
> I don't think we want to introduce software emulation, but feel free to prove me wrong.

I need to  introduce software flow control in my particular case.  This
need not make it into the kernel proper, but will be made available to
anyone interested as a patch.  The important thing here is that we end
up with a consistent interface for enabling these features.

> 
> > I'm rather excited by the idea that a standard interface for RTS
> > direction control is going to be introduced.
> 
> Best regards,
> 
-- 
Christopher Gibson <chris@toftronix.com.au>

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Christopher Gibson]

Oops.  Meant the code snippet to read as follows.
(Comments have changed).


#define CFLOW_EXT (08000000)
#define CFLOW   (CLOCAL | CRTSCTS | CFLOW_EXT)
#define CRTSADC (CFLOW_EXT)             /*RTS auto direction control*/
#define CDTRADC (CFLOW_EXT | CLOCAL)    /*DTR auto direction control*/

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Christopher Gibson]

Looks like I knocked the thread dead with my wacky octals ;)

No looks like the thread continues in
Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

See you there.

On Sun, 2008-08-10 at 13:57 +1000, Christopher Gibson wrote:
> Oops.  Meant the code snippet to read as follows.
> (Comments have changed).
> 
> 
> #define CFLOW_EXT (08000000)
> #define CFLOW   (CLOCAL | CRTSCTS | CFLOW_EXT)
> #define CRTSADC (CFLOW_EXT)             /*RTS auto direction control*/
> #define CDTRADC (CFLOW_EXT | CLOCAL)    /*DTR auto direction control*/
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-- 
Christopher Gibson <chris@toftronix.com.au>

[PATCH/RFC] Auto RS485 direction control

[Christopher Gibson]

Have finally put together a patch for UART direction control utilising
either the RTS, or the DTR handshaking lines, with settable pre and post
delay times.

This patch was tested on a 2.6.27.4 version kernel, on an AMD64 bit
machine.  A previous version was tested on an i486 machine, but there
have been many changes since.

This is a software only solution, requiring no special hardware, but
timing control for delays is only accurate to the next nearest jiffy.

I've allowed for setting the delays to microsecond resolution only to
support future work that utilises special UART features.  (I've found
very fine timing control on handshake line release in the Atmel USART
peripherals, and have also seen references to it in various embedded
controllers).


diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 77cb342..5ca3ba3 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1421,4 +1421,32 @@ config SPORT_BAUD_RATE
 	default 19200 if (SERIAL_SPORT_BAUD_RATE_19200)
 	default 9600 if (SERIAL_SPORT_BAUD_RATE_9600)
 
+comment "serial port extensions"
+        depends on EXPERIMENTAL
+
+config SERIAL_PORT_DIRECTION_CONTROL
+        bool "Allow hand shake line half duplex direction signaling"
+        default n
+        select SERIAL_CORE
+        help
+          Some serial communications devices are half-duplex and
require
+          a signal to give the required direction of communications.  
+          
+          One common example of this is when using a MAX202 - MAX485
chip 
+          pair (or similar) as a bridge between a RS232 interface and
a 
+          RS485 interface.
+          
+          Another example is when using simple radio modems, which may
have a 
+          further requirement that the direction should be asserted for
a 
+          specified time before transmission, and held for a specified
time 
+          after packet transmission.
+
+          Select this option to enable kernel control of the
handshaking
+          lines to give direction control.  This will make a serial
port
+          ioctl (TIOCSRS485) available for enabling this feature as
well as
+          for configuration of handshaking line to use (RTS or DTR), 
+          the sense of the line, and pre and post transmission delays.
+
+          Unless you know that you need this say N.
+
 endmenu
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index f977c98..d691338 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -62,6 +62,7 @@ static void uart_change_speed(struct uart_state
*state,
 					struct ktermios *old_termios);
 static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
 static void uart_change_pm(struct uart_state *state, int pm_state);
+static void direction_control_uart_start(struct tty_struct *tty);
 
 /*
  * This routine is used by the interrupt handler to schedule processing
in
@@ -105,6 +106,12 @@ static void uart_start(struct tty_struct *tty)
 	struct uart_port *port = state->port;
 	unsigned long flags;
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+	if (port->rs485.settings.flags & SER_RS485_MODE) {
+		direction_control_uart_start(tty);
+		return;
+	}
+#endif
 	spin_lock_irqsave(&port->lock, flags);
 	__uart_start(tty);
 	spin_unlock_irqrestore(&port->lock, flags);
@@ -130,8 +137,15 @@ uart_update_mctrl(struct uart_port *port, unsigned
int set, unsigned int clear)
 	spin_unlock_irqrestore(&port->lock, flags);
 }
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+#define uart_set_mctrl(port, set) \
+	uart_update_mctrl(port, (set) & ~port->rs485.mctrl_mask, 0)
+#define uart_clear_mctrl(port, clear) \
+	uart_update_mctrl(port, 0, (clear) & ~port->rs485.mctrl_mask)
+#else
 #define uart_set_mctrl(port, set)	uart_update_mctrl(port, set, 0)
 #define uart_clear_mctrl(port, clear)	uart_update_mctrl(port, 0, clear)
+#endif
 
 /*
  * Startup the port.  This will be called once per open.  All calls
@@ -456,6 +470,169 @@ uart_change_speed(struct uart_state *state, struct
ktermios *old_termios)
 	port->ops->set_termios(port, termios, old_termios);
 }
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+/**
+ * direction_control_init() - initialise direction control state
variables.
+ * @tty:	tty for UART
+ * 
+ * Initialisation call to setup state variables used for the direction
+ * control logic.
+ * Note that the direction control settings themselves have persistence
+ * across device openings.
+ */
+static void direction_control_init(struct tty_struct *tty)
+{
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+
+	init_timer(&rs->pre_post_timer);
+	rs->pre_post_timer.function = NULL;
+	rs->pre_post_timer.data = (unsigned long)tty;
+}
+
+/**
+ * direction_control_timed_post_xmit() - Post transmission delay
callback
+ * @data:	Holds pointer to the tty structure, recorded when timer is 
+ * 		set up.
+ *
+ * This is a kernel timer callback function, that is called after the
post
+ * transmission delay has expired.  It uses a modem control call to set
the
+ * RTS or DTR line for inbound communications.
+ *
+ * Note: This software timing approach limits direction control timing
to
+ * 	granularity to that of the System timer. (Timing is only good to
the 
+ * 	nearest jiffy).  
+ **/
+static void direction_control_timed_post_xmit(unsigned long data)
+{
+	struct tty_struct *tty = (struct tty_struct *)data;
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+	uart_update_mctrl(port,
+			  rs->mctrl_mask & ~rs->mctrl_xmit,
+			  rs->mctrl_mask & rs->mctrl_xmit);
+	rs->pre_post_timer.function = NULL;	/* Back to idle state */
+}
+
+/**
+ * direction_control_timed_xmit_end_detect() - End of transmission
polling
+ * @data:	Holds pointer to the tty structure, recorded when timer is 
+ * 		set up.
+ *
+ * This is a kernel timer callback function, called on every timer tick
until
+ * it is detected that there is no more data to transmit.  The post 
+ * transmission delay is then scheduled.
+ **/
+static void direction_control_timed_xmit_end_detect(unsigned long data)
+{
+	struct tty_struct *tty = (struct tty_struct *)data;
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+
+	if (port->ops->tx_empty(port)) {
+		if (rs->post_jiffies) {
+			/*
+			 * Schedule line turn around after required delay.
+			 */
+			rs->pre_post_timer.function =
+				direction_control_timed_post_xmit;
+			rs->pre_post_timer.expires = jiffies + rs->post_jiffies;
+			add_timer(&rs->pre_post_timer);
+		} else {
+			/*
+			 * No delay required turn line around now.
+			 */
+			direction_control_timed_post_xmit(data);
+		}
+	} else {
+		/* 
+		 * Transmission not finished, so try again next jiffy.
+		 */
+		add_timer(&rs->pre_post_timer);
+	}
+}
+
+/**
+ * direction_control_timed_start_xmit() - Trigger data transmission
+ * @data:	tty pointer for UART type case as unsigned long.
+ * 		(To conform to timer callback function prototype)
+ *
+ * Kicks the UART into transmission mode, and schedules polling of the
+ * UART status for transmission completion once per jiffy.  
+ * Called from a timer if a pre-transmission delay is required or
directly if 
+ * not.
+ */
+static void direction_control_timed_start_xmit(unsigned long data)
+{
+	struct tty_struct *tty = (struct tty_struct *)data;
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+	unsigned long flags;
+
+	rs->pre_post_timer.function = direction_control_timed_xmit_end_detect;
+	rs->pre_post_timer.expires  = jiffies;
+	add_timer(&rs->pre_post_timer);
+	spin_lock_irqsave(&port->lock, flags);
+	__uart_start(tty);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/**
+ * direction_control_uart_start() - UART Tx start, with direction
control
+ * @tty:	tty for UART
+ *
+ * Changes RTS and/or DTR handshaking lines to prepare for data
transmission.
+ * Schedules a delayed transmission if a required, or initiates
immediate
+ * transmission if pre transmission delay not required.
+ */
+static void direction_control_uart_start(struct tty_struct *tty)
+{
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+	if (!rs->pre_post_timer.function) {	/* Was in idle (Rx) state? */
+		/*
+		 * Set RTS or DTR for transmission.
+		 */
+		uart_update_mctrl(port,
+				  rs->mctrl_mask & rs->mctrl_xmit,
+				  rs->mctrl_mask & ~rs->mctrl_xmit);
+
+		if (rs->pre_jiffies) {
+			/*
+			 * Pre transmission delay required, schedule timer.
+			 */
+			rs->pre_post_timer.function =
+			    direction_control_timed_start_xmit;
+			rs->pre_post_timer.expires = jiffies + rs->pre_jiffies;
+			add_timer(&rs->pre_post_timer);
+		} else {
+			/*
+			 * No pre transmission delay required start 
+			 * immediate transmission.
+			 */
+			direction_control_timed_start_xmit((unsigned long)tty);
+		}
+	} else if (rs->pre_post_timer.function ==
+		   direction_control_timed_start_xmit) {
+		/* 
+		 * Nothing to do - already in pre xmit delay.
+		 */
+	} else {
+		/* 
+		 * Transmitting or in post transmit delay, reschedule the end 
+		 * of transmission polling.
+		 */
+		del_timer(&port->rs485.pre_post_timer);
+		direction_control_timed_start_xmit((unsigned long)tty);
+	}
+}
+#endif
+
 static inline int
 __uart_put_char(struct uart_port *port, struct circ_buf *circ, unsigned
char c)
 {
@@ -1082,6 +1259,70 @@ static int uart_get_count(struct uart_state
*state,
 	return copy_to_user(icnt, &icount, sizeof(icount)) ? -EFAULT : 0;
 }
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+/*
+ * Get the current direction control settings.
+ */
+static int rs485_get_settings(struct tty_struct *tty,
+			      struct serial_rs485_settings __user * uarg)
+{
+	struct uart_state *state = tty->driver_data;
+	int ret;
+	ret = copy_to_user(uarg, &state->port->rs485.settings, sizeof(*uarg));
+	ret = ret ? -EFAULT : 0;
+	return ret;
+}
+
+/*
+ * Set the current direction control settings.
+ */
+static int rs485_set_settings(struct tty_struct *tty,
+			      struct serial_rs485_settings __user * uarg)
+{
+	struct uart_state *state = tty->driver_data;
+	struct serial_rs485 *rs = &state->port->rs485;
+
+	/*-- Get requested settings. */
+	if (copy_from_user(&rs->settings, uarg, sizeof(rs->settings))) {
+		return -EFAULT;
+	}
+	/*
+	 * Alter requested settings to match our capabilities.
+	 * The user can query this by reading the setting back.
+	 */
+	rs->settings.delay_before_send =
+		jiffies_to_usecs(usecs_to_jiffies(
+					rs->settings.delay_before_send)); 
+
+	rs->settings.delay_after_send =
+		jiffies_to_usecs(usecs_to_jiffies(
+					rs->settings.delay_after_send)); 
+
+	/*
+	 * Pre-calculate values based on settings, to make interrupt code
+	 * more efficient.
+	 */
+	rs->pre_jiffies = usecs_to_jiffies(rs->settings.delay_before_send);
+	rs->post_jiffies = usecs_to_jiffies(rs->settings.delay_after_send);
+
+	rs->mctrl_mask = 0;
+	rs->mctrl_xmit = 0;
+	if (rs->settings.flags & SER_RS485_MODE_RTS) {
+		rs->mctrl_mask |= TIOCM_RTS;
+		if ( !(rs->settings.flags & SER_RS485_RTS_TX_LOW) ) {
+			rs->mctrl_xmit |= TIOCM_RTS;
+		}
+	}
+	if (rs->settings.flags & SER_RS485_MODE_DTR) {
+		rs->mctrl_mask |= TIOCM_DTR;
+		if ( !(rs->settings.flags & SER_RS485_DTR_TX_LOW) ) {
+			rs->mctrl_xmit |= TIOCM_DTR;
+		}
+	}
+	return 0;
+}
+#endif
+
 /*
  * Called via sys_ioctl.  We can use spin_lock_irq() here.
  */
@@ -1114,6 +1355,14 @@ uart_ioctl(struct tty_struct *tty, struct file
*filp, unsigned int cmd,
 	case TIOCSERSWILD: /* obsolete */
 		ret = 0;
 		break;
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+	case TIOCGRS485:
+		ret = rs485_get_settings(tty, uarg);
+		break;
+	case TIOCSRS485:
+		ret = rs485_set_settings(tty, uarg);
+		break;
+#endif
 	}
 
 	if (ret != -ENOIOCTLCMD)
@@ -1680,6 +1929,9 @@ static int uart_open(struct tty_struct *tty,
struct file *filp)
 		state->info->flags |= UIF_NORMAL_ACTIVE;
 
 		uart_update_termios(state);
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+		direction_control_init(tty);
+#endif
 	}
 
  fail:
diff --git a/include/asm-x86/ioctls.h b/include/asm-x86/ioctls.h
index c0c338b..2cd4775 100644
--- a/include/asm-x86/ioctls.h
+++ b/include/asm-x86/ioctls.h
@@ -51,6 +51,8 @@
 #define TCSETS2		_IOW('T', 0x2B, struct termios2)
 #define TCSETSW2	_IOW('T', 0x2C, struct termios2)
 #define TCSETSF2	_IOW('T', 0x2D, struct termios2)
+#define TIOCGRS485	0x542E
+#define TIOCSRS485	0x542F
 #define TIOCGPTN	_IOR('T', 0x30, unsigned int)
 				/* Get Pty Number (of pty-mux device) */
 #define TIOCSPTLCK	_IOW('T', 0x31, int)  /* Lock/unlock Pty */
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 3b2f6c0..1051c8c 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -165,6 +165,7 @@
 #include <linux/tty.h>
 #include <linux/mutex.h>
 #include <linux/sysrq.h>
+#include <linux/timer.h>
 
 struct uart_port;
 struct uart_info;
@@ -239,6 +240,31 @@ struct uart_icount {
 
 typedef unsigned int __bitwise__ upf_t;
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+/* -- Settings used with the TIOCSRS485 & TIOCGRS485 ioctl */
+struct serial_rs485_settings{
+		__u32   flags;			/* RS485 feature flags */
+#define SER_RS485_MODE			(3 << 0)	/* Mask for mode. */
+#define SER_RS485_MODE_DISABLED		(0 << 0)
+#define SER_RS485_MODE_RTS		(1 << 0)
+#define SER_RS485_MODE_DTR		(2 << 0)
+#define SER_RS485_RTS_TX_LOW		(1 << 2)	/* Inverted RTS	*/
+#define SER_RS485_DTR_TX_LOW		(1 << 3)	/* Inverted DTR	*/
+		__u32   delay_before_send;		/* Microseconds */
+		__u32   delay_after_send;		/* Microseconds */
+		__u32   padding[5];             /* Memory is cheap, new structs
+						   are a royal PITA .. */
+};
+struct serial_rs485 {
+	struct serial_rs485_settings	settings;
+	struct	timer_list       	pre_post_timer;
+	u16	pre_jiffies;
+	u16	post_jiffies;
+	unsigned int mctrl_mask;
+	unsigned int mctrl_xmit;		/* Bits for Tx.	*/
+};
+#endif
+
 struct uart_port {
 	spinlock_t		lock;			/* port lock */
 	unsigned int		iobase;			/* in/out[bwl] */
@@ -308,6 +334,9 @@ struct uart_port {
 	unsigned char		suspended;
 	unsigned char		unused[2];
 	void			*private_data;		/* generic platform data pointer */
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+	struct serial_rs485	rs485;
+#endif
 };
 
 /*


-- 
Christopher Gibson <chris@toftronix.com.au>

Re: [PATCH/RFC] Auto RS485 direction control

[Christopher Gibson]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

It would appear that my RFC patch submission corrupted with word
wrapping of my mail program.  Here is the patch as an attachment which
should not suffer the same fate.

On Wed, 2008-12-03 at 00:09 +1100, Christopher Gibson wrote:
> Have finally put together a patch for UART direction control utilising
> either the RTS, or the DTR handshaking lines, with settable pre and post
> delay times.
> 
> This patch was tested on a 2.6.27.4 version kernel, on an AMD64 bit
> machine.  A previous version was tested on an i486 machine, but there
> have been many changes since.
> 
> This is a software only solution, requiring no special hardware, but
> timing control for delays is only accurate to the next nearest jiffy.
> 
> I've allowed for setting the delays to microsecond resolution only to
> support future work that utilises special UART features.  (I've found
> very fine timing control on handshake line release in the Atmel USART
> peripherals, and have also seen references to it in various embedded
> controllers).
> 
> 


[-- Attachment #2: ser_dir_ctrl.dif --]
[-- Type: text/plain, Size: 13981 bytes --]

 drivers/serial/Kconfig       |   28 +++++
 drivers/serial/serial_core.c |  252 ++++++++++++++++++++++++++++++++++++++++++
 include/asm-x86/ioctls.h     |    2 +
 include/linux/serial_core.h  |   29 +++++
 4 files changed, 311 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 77cb342..5ca3ba3 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1421,4 +1421,32 @@ config SPORT_BAUD_RATE
 	default 19200 if (SERIAL_SPORT_BAUD_RATE_19200)
 	default 9600 if (SERIAL_SPORT_BAUD_RATE_9600)
 
+comment "serial port extensions"
+        depends on EXPERIMENTAL
+
+config SERIAL_PORT_DIRECTION_CONTROL
+        bool "Allow hand shake line half duplex direction signaling"
+        default n
+        select SERIAL_CORE
+        help
+          Some serial communications devices are half-duplex and require
+          a signal to give the required direction of communications.  
+          
+          One common example of this is when using a MAX202 - MAX485 chip 
+          pair (or similar) as a bridge between a RS232 interface and a 
+          RS485 interface.
+          
+          Another example is when using simple radio modems, which may have a 
+          further requirement that the direction should be asserted for a 
+          specified time before transmission, and held for a specified time 
+          after packet transmission.
+
+          Select this option to enable kernel control of the handshaking
+          lines to give direction control.  This will make a serial port
+          ioctl (TIOCSRS485) available for enabling this feature as well as
+          for configuration of handshaking line to use (RTS or DTR), 
+          the sense of the line, and pre and post transmission delays.
+
+          Unless you know that you need this say N.
+
 endmenu
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index f977c98..d691338 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -62,6 +62,7 @@ static void uart_change_speed(struct uart_state *state,
 					struct ktermios *old_termios);
 static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
 static void uart_change_pm(struct uart_state *state, int pm_state);
+static void direction_control_uart_start(struct tty_struct *tty);
 
 /*
  * This routine is used by the interrupt handler to schedule processing in
@@ -105,6 +106,12 @@ static void uart_start(struct tty_struct *tty)
 	struct uart_port *port = state->port;
 	unsigned long flags;
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+	if (port->rs485.settings.flags & SER_RS485_MODE) {
+		direction_control_uart_start(tty);
+		return;
+	}
+#endif
 	spin_lock_irqsave(&port->lock, flags);
 	__uart_start(tty);
 	spin_unlock_irqrestore(&port->lock, flags);
@@ -130,8 +137,15 @@ uart_update_mctrl(struct uart_port *port, unsigned int set, unsigned int clear)
 	spin_unlock_irqrestore(&port->lock, flags);
 }
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+#define uart_set_mctrl(port, set) \
+	uart_update_mctrl(port, (set) & ~port->rs485.mctrl_mask, 0)
+#define uart_clear_mctrl(port, clear) \
+	uart_update_mctrl(port, 0, (clear) & ~port->rs485.mctrl_mask)
+#else
 #define uart_set_mctrl(port, set)	uart_update_mctrl(port, set, 0)
 #define uart_clear_mctrl(port, clear)	uart_update_mctrl(port, 0, clear)
+#endif
 
 /*
  * Startup the port.  This will be called once per open.  All calls
@@ -456,6 +470,169 @@ uart_change_speed(struct uart_state *state, struct ktermios *old_termios)
 	port->ops->set_termios(port, termios, old_termios);
 }
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+/**
+ * direction_control_init() - initialise direction control state variables.
+ * @tty:	tty for UART
+ * 
+ * Initialisation call to setup state variables used for the direction
+ * control logic.
+ * Note that the direction control settings themselves have persistence
+ * across device openings.
+ */
+static void direction_control_init(struct tty_struct *tty)
+{
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+
+	init_timer(&rs->pre_post_timer);
+	rs->pre_post_timer.function = NULL;
+	rs->pre_post_timer.data = (unsigned long)tty;
+}
+
+/**
+ * direction_control_timed_post_xmit() - Post transmission delay callback
+ * @data:	Holds pointer to the tty structure, recorded when timer is 
+ * 		set up.
+ *
+ * This is a kernel timer callback function, that is called after the post
+ * transmission delay has expired.  It uses a modem control call to set the
+ * RTS or DTR line for inbound communications.
+ *
+ * Note: This software timing approach limits direction control timing to
+ * 	granularity to that of the System timer. (Timing is only good to the 
+ * 	nearest jiffy).  
+ **/
+static void direction_control_timed_post_xmit(unsigned long data)
+{
+	struct tty_struct *tty = (struct tty_struct *)data;
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+	uart_update_mctrl(port,
+			  rs->mctrl_mask & ~rs->mctrl_xmit,
+			  rs->mctrl_mask & rs->mctrl_xmit);
+	rs->pre_post_timer.function = NULL;	/* Back to idle state */
+}
+
+/**
+ * direction_control_timed_xmit_end_detect() - End of transmission polling
+ * @data:	Holds pointer to the tty structure, recorded when timer is 
+ * 		set up.
+ *
+ * This is a kernel timer callback function, called on every timer tick until
+ * it is detected that there is no more data to transmit.  The post 
+ * transmission delay is then scheduled.
+ **/
+static void direction_control_timed_xmit_end_detect(unsigned long data)
+{
+	struct tty_struct *tty = (struct tty_struct *)data;
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+
+	if (port->ops->tx_empty(port)) {
+		if (rs->post_jiffies) {
+			/*
+			 * Schedule line turn around after required delay.
+			 */
+			rs->pre_post_timer.function =
+				direction_control_timed_post_xmit;
+			rs->pre_post_timer.expires = jiffies + rs->post_jiffies;
+			add_timer(&rs->pre_post_timer);
+		} else {
+			/*
+			 * No delay required turn line around now.
+			 */
+			direction_control_timed_post_xmit(data);
+		}
+	} else {
+		/* 
+		 * Transmission not finished, so try again next jiffy.
+		 */
+		add_timer(&rs->pre_post_timer);
+	}
+}
+
+/**
+ * direction_control_timed_start_xmit() - Trigger data transmission
+ * @data:	tty pointer for UART type case as unsigned long.
+ * 		(To conform to timer callback function prototype)
+ *
+ * Kicks the UART into transmission mode, and schedules polling of the
+ * UART status for transmission completion once per jiffy.  
+ * Called from a timer if a pre-transmission delay is required or directly if 
+ * not.
+ */
+static void direction_control_timed_start_xmit(unsigned long data)
+{
+	struct tty_struct *tty = (struct tty_struct *)data;
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+	unsigned long flags;
+
+	rs->pre_post_timer.function = direction_control_timed_xmit_end_detect;
+	rs->pre_post_timer.expires  = jiffies;
+	add_timer(&rs->pre_post_timer);
+	spin_lock_irqsave(&port->lock, flags);
+	__uart_start(tty);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/**
+ * direction_control_uart_start() - UART Tx start, with direction control
+ * @tty:	tty for UART
+ *
+ * Changes RTS and/or DTR handshaking lines to prepare for data transmission.
+ * Schedules a delayed transmission if a required, or initiates immediate
+ * transmission if pre transmission delay not required.
+ */
+static void direction_control_uart_start(struct tty_struct *tty)
+{
+	struct uart_state *state = tty->driver_data;
+	struct uart_port *port = state->port;
+	struct serial_rs485 *rs = &port->rs485;
+	if (!rs->pre_post_timer.function) {	/* Was in idle (Rx) state? */
+		/*
+		 * Set RTS or DTR for transmission.
+		 */
+		uart_update_mctrl(port,
+				  rs->mctrl_mask & rs->mctrl_xmit,
+				  rs->mctrl_mask & ~rs->mctrl_xmit);
+
+		if (rs->pre_jiffies) {
+			/*
+			 * Pre transmission delay required, schedule timer.
+			 */
+			rs->pre_post_timer.function =
+			    direction_control_timed_start_xmit;
+			rs->pre_post_timer.expires = jiffies + rs->pre_jiffies;
+			add_timer(&rs->pre_post_timer);
+		} else {
+			/*
+			 * No pre transmission delay required start 
+			 * immediate transmission.
+			 */
+			direction_control_timed_start_xmit((unsigned long)tty);
+		}
+	} else if (rs->pre_post_timer.function ==
+		   direction_control_timed_start_xmit) {
+		/* 
+		 * Nothing to do - already in pre xmit delay.
+		 */
+	} else {
+		/* 
+		 * Transmitting or in post transmit delay, reschedule the end 
+		 * of transmission polling.
+		 */
+		del_timer(&port->rs485.pre_post_timer);
+		direction_control_timed_start_xmit((unsigned long)tty);
+	}
+}
+#endif
+
 static inline int
 __uart_put_char(struct uart_port *port, struct circ_buf *circ, unsigned char c)
 {
@@ -1082,6 +1259,70 @@ static int uart_get_count(struct uart_state *state,
 	return copy_to_user(icnt, &icount, sizeof(icount)) ? -EFAULT : 0;
 }
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+/*
+ * Get the current direction control settings.
+ */
+static int rs485_get_settings(struct tty_struct *tty,
+			      struct serial_rs485_settings __user * uarg)
+{
+	struct uart_state *state = tty->driver_data;
+	int ret;
+	ret = copy_to_user(uarg, &state->port->rs485.settings, sizeof(*uarg));
+	ret = ret ? -EFAULT : 0;
+	return ret;
+}
+
+/*
+ * Set the current direction control settings.
+ */
+static int rs485_set_settings(struct tty_struct *tty,
+			      struct serial_rs485_settings __user * uarg)
+{
+	struct uart_state *state = tty->driver_data;
+	struct serial_rs485 *rs = &state->port->rs485;
+
+	/*-- Get requested settings. */
+	if (copy_from_user(&rs->settings, uarg, sizeof(rs->settings))) {
+		return -EFAULT;
+	}
+	/*
+	 * Alter requested settings to match our capabilities.
+	 * The user can query this by reading the setting back.
+	 */
+	rs->settings.delay_before_send =
+		jiffies_to_usecs(usecs_to_jiffies(
+					rs->settings.delay_before_send)); 
+
+	rs->settings.delay_after_send =
+		jiffies_to_usecs(usecs_to_jiffies(
+					rs->settings.delay_after_send)); 
+
+	/*
+	 * Pre-calculate values based on settings, to make interrupt code
+	 * more efficient.
+	 */
+	rs->pre_jiffies = usecs_to_jiffies(rs->settings.delay_before_send);
+	rs->post_jiffies = usecs_to_jiffies(rs->settings.delay_after_send);
+
+	rs->mctrl_mask = 0;
+	rs->mctrl_xmit = 0;
+	if (rs->settings.flags & SER_RS485_MODE_RTS) {
+		rs->mctrl_mask |= TIOCM_RTS;
+		if ( !(rs->settings.flags & SER_RS485_RTS_TX_LOW) ) {
+			rs->mctrl_xmit |= TIOCM_RTS;
+		}
+	}
+	if (rs->settings.flags & SER_RS485_MODE_DTR) {
+		rs->mctrl_mask |= TIOCM_DTR;
+		if ( !(rs->settings.flags & SER_RS485_DTR_TX_LOW) ) {
+			rs->mctrl_xmit |= TIOCM_DTR;
+		}
+	}
+	return 0;
+}
+#endif
+
 /*
  * Called via sys_ioctl.  We can use spin_lock_irq() here.
  */
@@ -1114,6 +1355,14 @@ uart_ioctl(struct tty_struct *tty, struct file *filp, unsigned int cmd,
 	case TIOCSERSWILD: /* obsolete */
 		ret = 0;
 		break;
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+	case TIOCGRS485:
+		ret = rs485_get_settings(tty, uarg);
+		break;
+	case TIOCSRS485:
+		ret = rs485_set_settings(tty, uarg);
+		break;
+#endif
 	}
 
 	if (ret != -ENOIOCTLCMD)
@@ -1680,6 +1929,9 @@ static int uart_open(struct tty_struct *tty, struct file *filp)
 		state->info->flags |= UIF_NORMAL_ACTIVE;
 
 		uart_update_termios(state);
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+		direction_control_init(tty);
+#endif
 	}
 
  fail:
diff --git a/include/asm-x86/ioctls.h b/include/asm-x86/ioctls.h
index c0c338b..2cd4775 100644
--- a/include/asm-x86/ioctls.h
+++ b/include/asm-x86/ioctls.h
@@ -51,6 +51,8 @@
 #define TCSETS2		_IOW('T', 0x2B, struct termios2)
 #define TCSETSW2	_IOW('T', 0x2C, struct termios2)
 #define TCSETSF2	_IOW('T', 0x2D, struct termios2)
+#define TIOCGRS485	0x542E
+#define TIOCSRS485	0x542F
 #define TIOCGPTN	_IOR('T', 0x30, unsigned int)
 				/* Get Pty Number (of pty-mux device) */
 #define TIOCSPTLCK	_IOW('T', 0x31, int)  /* Lock/unlock Pty */
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 3b2f6c0..1051c8c 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -165,6 +165,7 @@
 #include <linux/tty.h>
 #include <linux/mutex.h>
 #include <linux/sysrq.h>
+#include <linux/timer.h>
 
 struct uart_port;
 struct uart_info;
@@ -239,6 +240,31 @@ struct uart_icount {
 
 typedef unsigned int __bitwise__ upf_t;
 
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+/* -- Settings used with the TIOCSRS485 & TIOCGRS485 ioctl */
+struct serial_rs485_settings{
+		__u32   flags;			/* RS485 feature flags */
+#define SER_RS485_MODE			(3 << 0)	/* Mask for mode. */
+#define SER_RS485_MODE_DISABLED		(0 << 0)
+#define SER_RS485_MODE_RTS		(1 << 0)
+#define SER_RS485_MODE_DTR		(2 << 0)
+#define SER_RS485_RTS_TX_LOW		(1 << 2)	/* Inverted RTS	*/
+#define SER_RS485_DTR_TX_LOW		(1 << 3)	/* Inverted DTR	*/
+		__u32   delay_before_send;		/* Microseconds */
+		__u32   delay_after_send;		/* Microseconds */
+		__u32   padding[5];             /* Memory is cheap, new structs
+						   are a royal PITA .. */
+};
+struct serial_rs485 {
+	struct serial_rs485_settings	settings;
+	struct	timer_list       	pre_post_timer;
+	u16	pre_jiffies;
+	u16	post_jiffies;
+	unsigned int mctrl_mask;
+	unsigned int mctrl_xmit;		/* Bits for Tx.	*/
+};
+#endif
+
 struct uart_port {
 	spinlock_t		lock;			/* port lock */
 	unsigned int		iobase;			/* in/out[bwl] */
@@ -308,6 +334,9 @@ struct uart_port {
 	unsigned char		suspended;
 	unsigned char		unused[2];
 	void			*private_data;		/* generic platform data pointer */
+#ifdef CONFIG_SERIAL_PORT_DIRECTION_CONTROL
+	struct serial_rs485	rs485;
+#endif
 };
 
 /*

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Tosoni]

> Original Message From: Laurent Pinchart
> Sent: Monday, August 04, 2008 4:37 PM
> 
> On Monday 04 August 2008, Tosoni wrote:
> > About the flags names -- CARTS, UART_FCTR_RS485
> > 
> > May I suggest CRTSTOGGLE since it is known by that kind
> > of name in other OS's :-)
> 
> I like Russell's proposal of sticking to CRTSCTS and adding 
> options to setserial:
> 
> > Should CRTSCTS be a global "enable some kind of flow 
> control" bit and
> > setserial be used to configure the actual flow control method
> > (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
> > RS485 on DTR) ?
> 
> Any opinion on that ?

It sounds fine, and it's much better than nothing.
Here are some drawbacks I can see:

1. We are talking about userland to kernel interface. It should
look like a "virtual" or "ideal" serial port. See this example:

The Philips SC28L202 chip can implement RS485 on RTS with its
MD2(5) register, but is is definitely NOT compatible with the 16C550.
What if I want to make a driver for it ? (and it might well happen)
Must I support setserial for it then ? Will setserial evolve when my
SC28L202 driver evolves ?

AFAIK setserial was added to handle new, specific features for 8250
compatible cards without breaking *NIX TERMIOS compatibility. If a
general feature can be added without resorting to setserial nor breaking
*NIX compatibility, let's do so ! (else let's do our best with setserial)

2. As far as I remember the CRTSCTS flag has a long history back to
XENIX and SCO Unix ports. This flag is well defined and used in
many *NIX implementations and I am reluctant to alter its meaning.

On the other hand, using CRTSCTS would garantee that is any
architecture we will find this bit available in termios, which may
not be the case with a brand new bit definition.

Last remark:
Interestingly, the RTS envelope on the Oxford chips is implemented
with... the DTR pin. On our cards we have a piece of hardware which
redirect the uart DTR pin to the external RTS in this case.


> 
> > And further, it says was RTS will do, instead of why. Maybe 
> someone could
> > use it for something other than RS485 ?
> 
> I agree with you here. The name should reflect that RTS is 
> used in 'envelope' mode (asserted during data transmission, 
> idle between frames).
> 
> Best regards,
> 
> -- 
> Laurent Pinchart
> CSE Semaphore Belgium
> 
> Chaussee de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
> 
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
> 

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Grant Edwards]

On 2008-08-04, Tosoni <jp.tosoni@acksys.fr> wrote:

> Last remark:
>
> Interestingly, the RTS envelope on the Oxford chips is
> implemented with... the DTR pin. On our cards we have a piece
> of hardware which redirect the uart DTR pin to the external
> RTS in this case.

Well, that's just plain wrong.  The RS-232 standard was quite
clear that RTS is what's used to enable transmission.  ;)

-- 
Grant Edwards                   grante             Yow! I have a VISION!  It's
                                  at               a RANCID double-FISHWICH on
                               visi.com            an ENRICHED BUN!!

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Matt Schulte]

>> Interestingly, the RTS envelope on the Oxford chips is
>> implemented with... the DTR pin. On our cards we have a piece
>> of hardware which redirect the uart DTR pin to the external
>> RTS in this case.
> 
> Well, that's just plain wrong.  The RS-232 standard was quite
> clear that RTS is what's used to enable transmission.  ;)
> 
Believe it or not, it actually has a purpose.  That way you can use 
RTS/CTS hardware flow control AND have RS485 driver control using the 
DTR pin.

Matt Schulte

Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

On Monday 04 August 2008, Grant Edwards wrote:
> On 2008-08-04, Tosoni <jp.tosoni@acksys.fr> wrote:
> 
> > Last remark:
> >
> > Interestingly, the RTS envelope on the Oxford chips is
> > implemented with... the DTR pin. On our cards we have a piece
> > of hardware which redirect the uart DTR pin to the external
> > RTS in this case.
> 
> Well, that's just plain wrong.  The RS-232 standard was quite
> clear that RTS is what's used to enable transmission.  ;)

UARTs are not restricted to RS-232. The pin labelled RTS in the 16850 datasheet is a dual purpose pin that can be used either as RTS in RS-232 mode or as a bus direction signal in RS-485 mode.

Beside, even in RS-232 mode, RTS has at least two widely used modes. The historical usage asserts RTS when the DTE (computer) wants to send data. It then waits for the DCE (modem) to assert CTS and then sends data on the TX line. This was used with half-duplex modems. The newer flow-control usage asserts RTS when the DTE is ready to receive data. The DCE uses CTS for the same purpose in the opposite data flow direction.

This means we already have at least 3 hardware RTS/CTS modes that we need to support in the serial API.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: [PATCH/RFC] 8250: Auto RS485 direction control

[Tosoni]

I agree with your understanding of the standard.

I guess that the Oxford guys wanted to keep the possibility of using both
RTS input flow control AND half-duplex.

JP Tosoni

> -----Original Message-----
> From: linux-serial-owner@vger.kernel.org
> [mailto:linux-serial-owner@vger.kernel.org]On Behalf Of Grant Edwards
> Sent: Monday, August 04, 2008 7:46 PM
> To: linux-serial@vger.kernel.org
> Subject: Re: [PATCH/RFC] 8250: Auto RS485 direction control
>
>
> On 2008-08-04, Tosoni <jp.tosoni@acksys.fr> wrote:
>
> > Last remark:
> >
> > Interestingly, the RTS envelope on the Oxford chips is
> > implemented with... the DTR pin. On our cards we have a piece
> > of hardware which redirect the uart DTR pin to the external
> > RTS in this case.
>
> Well, that's just plain wrong.  The RS-232 standard was quite
> clear that RTS is what's used to enable transmission.  ;)
>
> --
> Grant Edwards                   grante             Yow! I
> have a VISION!  It's
>                                   at               a RANCID
> double-FISHWICH on
>                                visi.com            an ENRICHED BUN!!
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>