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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Guntupalli, Manikanta schreef op 2023-05-10 18:26:
Hi Maarten,

-----Original Message-----
From: m.brock@xxxxxxxxxxxxx <m.brock@xxxxxxxxxxxxx>
Sent: Thursday, May 4, 2023 5:52 PM
To: Guntupalli, Manikanta <manikanta.guntupalli@xxxxxxx>
Cc: gregkh@xxxxxxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
krzysztof.kozlowski+dt@xxxxxxxxxx; michal.simek@xxxxxxxxxx; linux-
serial@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
kernel@xxxxxxxxxxxxxxx; jirislaby@xxxxxxxxxx; linux-arm-
kernel@xxxxxxxxxxxxxxxxxxx; Simek, Michal <michal.simek@xxxxxxx>; git
(AMD-Xilinx) <git@xxxxxxx>; Pandey, Radhey Shyam
<radhey.shyam.pandey@xxxxxxx>; Datta, Shubhrajyoti
<shubhrajyoti.datta@xxxxxxx>; Goud, Srinivas <srinivas.goud@xxxxxxx>;
manion05gk@xxxxxxxxx
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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux