On 07/09/2014 09:01 PM, Lennart Sorensen wrote:
>> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
>> index c7c3bf7..bf06a4c 100644
>> --- a/drivers/tty/serial/8250/8250_core.c
>> +++ b/drivers/tty/serial/8250/8250_core.c
>> @@ -1281,10 +1283,34 @@ static void autoconfig_irq(struct uart_8250_port *up)
>>
>> static inline void __stop_tx(struct uart_8250_port *p)
>> {
>> + if (p->rs485.flags & SER_RS485_ENABLED) {
>> + int ret;
>> +
>> + ret = (p->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
>> + if (gpio_get_value(p->rts_gpio) != ret) {
>> + if (p->rs485.delay_rts_after_send > 0)
>> + mdelay(p->rs485.delay_rts_after_send);
>> + gpio_set_value(p->rts_gpio, ret);
>
> Usually the delay for RS485 is done in bit times, not msec. Not sure
> how you expect this to work. Not sure doing it in software is precise
> enough either. It probably should be calculated based on the current
> baudrate with a bit time rather than msec in the DT data. No one wants
> to have to change the DT data to change the baud rate. After all this
> is very often used with modbus and the modbus rules specify turn around
> times in bit times.
My understanding is that this is not baudrate related. This is the
delay that the hardware (the transceiver) to perform the change and
work.
There is the ioctl() interface which can change the delay, too. The
only required thing is the gpio.
> I hope TI puts this into the UART in future designs where it belongs
> (similar to what Exar and many others already did).
>
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
