Re: [PATCH 0/2] Add rs485 support to uartps driver

[m.brock@vanmierlo.com]

Guntupalli, Manikanta schreef op 2023-05-10 18:26:
> Hi Maarten,
> 
>> -----Original Message-----
>> From: m.brock@vanmierlo.com <m.brock@vanmierlo.com>
>> Sent: Thursday, May 4, 2023 5:52 PM
>> To: Guntupalli, Manikanta <manikanta.guntupalli@amd.com>
>> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org;
>> krzysztof.kozlowski+dt@linaro.org; michal.simek@xilinx.com; linux-
>> serial@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> kernel@vger.kernel.org; jirislaby@kernel.org; linux-arm-
>> kernel@lists.infradead.org; Simek, Michal <michal.simek@amd.com>; git
>> (AMD-Xilinx) <git@amd.com>; Pandey, Radhey Shyam
>> <radhey.shyam.pandey@amd.com>; Datta, Shubhrajyoti
>> <shubhrajyoti.datta@amd.com>; Goud, Srinivas <srinivas.goud@amd.com>;
>> manion05gk@gmail.com
>> Subject: Re: [PATCH 0/2] Add rs485 support to uartps driver
>> 
>> Manikanta Guntupalli wrote 2023-04-26 14:29:
>> > Add optional gpio property to uartps node to support rs485 Add rs485
>> > support to uartps driver
>> >
>> > Manikanta Guntupalli (2):
>> >   dt-bindings: Add optional gpio property to uartps node to support
>> >     rs485
>> >   tty: serial: uartps: Add rs485 support to uartps driver
>> >
>> >  .../devicetree/bindings/serial/cdns,uart.yaml |  5 +
>> >  drivers/tty/serial/xilinx_uartps.c            | 96 ++++++++++++++++++-
>> >  2 files changed, 100 insertions(+), 1 deletion(-)
>> 
>> Why would you want to use a GPIO and not RTS for choosing the 
>> direction as
>> is more common in this case?
> In ZynqMp platform Cadence UART Controller RTS signal routed to
> external through the PL(Programmable Logic) design not through
> Multiplexed IO.

Then why not route RXD & TXD to the PL as well and connect the module to 
a
PMOD connector connected to the PL? But I admit that a GPIO always works 
as
well.

>> And have you thought about configuring the polarity?
> GPIO polarity configured through device tree property.
> 
> &uart0 {
>         ...
>         txrx-gpios = <&gpio 72 GPIO_ACTIVE_LOW>;
>         linux,rs485-enabled-at-boot-time;
> };

Useable, but not honoring 
SER_RS485_RTS_ON_SEND/SER_RS485_RTS_AFTER_SEND.

>> How long will the signal be active before the real transmission begins 
>> so the
>> driver can settle?
> Default is RE(GPIO LOW) and while sending we drive the pin to HIGH. We
> wait for transmission completion, for that we check Transmitter state
> machine active status to ZERO and TX FIFO EMPTY.

How does that take delay_rts_before_send/delay_rts_after_send into 
account?
Not every driver switches direction as fast as you would like.

> Thanks,
> Manikanta.

Greetings,
Maarten