| Message ID | 20190221171758.10322-1-martin.kepplinger@ginzinger.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/9] serial: uapi: add SER_RS485_DELAY_IN_USEC flag to struct serial_rs485 | expand |
On 21.02.19 18:17, Martin Kepplinger wrote: > This extends the user interface for rs485 communication: > > We add a new flag, SER_RS485_DELAY_IN_USEC, to struct serial_rs485 that > indicates that delay_rts_before_send and delay_rts_after_send values are > interpreted in microsecond units. > > Up until now, the code comment defined these values to hold the delays in > millisecond units. Especially with fast data rates (1Mbaut or more) that > are not too uncommon for RS485, 1ms become quite long. Users need to be > able to set shorter delays than 1 ms in order not to slow down the channel > unnecessarily. > > So when delays are needed, but not as long as 1ms, this enables faster > communication channels without changing the baudrate. > > Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> > --- > > revision history > ---------------- > v2: re-send as a proper series after fixing my mailserver > v1: initial implementation idea > > > So have this totally quirky patch that uses udelay() in our tree > for a looong time now because of the above reasons - and because we are lazy. > This is an attempt to get rid of said patch on our side and fix this properly. > > What do you thing about adding a flag in general? > > The following patches should integrate this idea in devicetree and drivers. > These changes are NOT tested on hardware but should behave predictably > enough. I use the delays in a driver that doesn't implement them yet at > all. I'll do that after this (or something similar) is merged - it's a 2-liner > then. > > Also, a patch to the rs485conf tool, that is sometimes used instead of > ioctl() directly, will be prepared as well. > any objections of questions about having microsecond delays and this series of changes? thanks martin
diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h index 93eb3c496ff1..c16c950ebca2 100644 --- a/include/uapi/linux/serial.h +++ b/include/uapi/linux/serial.h @@ -126,8 +126,15 @@ struct serial_rs485 { #define SER_RS485_TERMINATE_BUS (1 << 5) /* Enable bus termination (if supported) */ - __u32 delay_rts_before_send; /* Delay before send (milliseconds) */ - __u32 delay_rts_after_send; /* Delay after send (milliseconds) */ +#define SER_RS485_DELAY_IN_USEC (1 << 6) /* delay_rts_*_send + values are given in + microseconds */ + __u32 delay_rts_before_send; /* Delay before send (milliseconds + by default. microseconds if flag + is set) */ + __u32 delay_rts_after_send; /* Delay after send (milliseconds + by default. microseconds if flag + is set) */ __u32 padding[5]; /* Memory is cheap, new structs are a royal PITA .. */ };
This extends the user interface for rs485 communication: We add a new flag, SER_RS485_DELAY_IN_USEC, to struct serial_rs485 that indicates that delay_rts_before_send and delay_rts_after_send values are interpreted in microsecond units. Up until now, the code comment defined these values to hold the delays in millisecond units. Especially with fast data rates (1Mbaut or more) that are not too uncommon for RS485, 1ms become quite long. Users need to be able to set shorter delays than 1 ms in order not to slow down the channel unnecessarily. So when delays are needed, but not as long as 1ms, this enables faster communication channels without changing the baudrate. Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> --- revision history ---------------- v2: re-send as a proper series after fixing my mailserver v1: initial implementation idea So have this totally quirky patch that uses udelay() in our tree for a looong time now because of the above reasons - and because we are lazy. This is an attempt to get rid of said patch on our side and fix this properly. What do you thing about adding a flag in general? The following patches should integrate this idea in devicetree and drivers. These changes are NOT tested on hardware but should behave predictably enough. I use the delays in a driver that doesn't implement them yet at all. I'll do that after this (or something similar) is merged - it's a 2-liner then. Also, a patch to the rs485conf tool, that is sometimes used instead of ioctl() directly, will be prepared as well. thanks martin include/uapi/linux/serial.h | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)