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

[Michal Simek]

On 5/14/23 13:01, m.brock at vanmierlo.com wrote:
> Guntupalli, Manikanta schreef op 2023-05-10 18:26:
>> Hi Maarten,
>>
>>> -----Original Message-----
>>> From: m.brock at vanmierlo.com <m.brock at vanmierlo.com>
>>> Sent: Thursday, May 4, 2023 5:52 PM
>>> To: Guntupalli, Manikanta <manikanta.guntupalli at amd.com>
>>> Cc: gregkh at linuxfoundation.org; robh+dt at kernel.org;
>>> krzysztof.kozlowski+dt at linaro.org; michal.simek at xilinx.com; linux-
>>> serial at vger.kernel.org; devicetree at vger.kernel.org; linux-
>>> kernel at vger.kernel.org; jirislaby at kernel.org; linux-arm-
>>> kernel at lists.infradead.org; Simek, Michal <michal.simek at amd.com>; git
>>> (AMD-Xilinx) <git at amd.com>; Pandey, Radhey Shyam
>>> <radhey.shyam.pandey at amd.com>; Datta, Shubhrajyoti
>>> <shubhrajyoti.datta at amd.com>; Goud, Srinivas <srinivas.goud at amd.com>;
>>> manion05gk at 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.

I will let Mani to comment other parts. Simply that's how PCB is wired now.
I remember some discussions to enhance silicon with being able to route MIO pins 
to PL but that capability has never been added.
And the second part of it is on PL pin constrained system there doesn't need to 
be free PL pin for this functionality.
And third thing is that routing via PL means that PL has to be loaded to get 
this functionality. Which also means much higher power consumption even if there 
is single wire between EMIO and PL pin.
It means GPIO routed via MIO through free existing pin is PCB design choice in 
the context of project they are focusing on.
And good that you see also GPIO as viable option for it.

Thanks,
Michal