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@xxxxxxxxxxxxx>
> ---
>
> 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
