[PATCH 1/4] dt_bindings: rs485: Add binding for GPIO that controls Rx enable during Tx

[Christoph Niedermaier]

From: Alexander Dahl [mailto:ada at thorsis.com]
Sent: Friday, October 28, 2022 8:21 AM
> 
> Hello Christoph,
> 

Hello Alex,

> let me first say, for an upcoming new product we are currently
> developing, we tried different wirings, all related to that !RE pin of
> the transceiver.
> 
> In a first hardware revision the engineer doing the schematic
> connected !RE to GND (always on) and it took me a while to recognize
> what was going on: everything send through TX was mirrored on RX,
> which makes using lots of standard applications on that port just
> fail.  (To be fair, we need exactly that behaviour on a different
> board.)
> 
> In a second iteration !RE is directly connected to DE now, so RE is
> now always the opposite of DE.  DE itself is always connected to the
> RTS line of the UART, which allows the driver to switch direction.
> 
> More below.
> 
> Am Thu, Oct 27, 2022 at 12:06:56PM +0000 schrieb Christoph Niedermaier:
>> From: Rob Herring [mailto:robh at kernel.org]
>> Sent: Wednesday, October 26, 2022 10:59 PM
>>> On Wed, Oct 26, 2022 at 06:50:46PM +0200, Christoph Niedermaier wrote:
>>>> Add the binding for a generic definition of a GPIO, that controls whether Rx
>>>> is connected or disconnected by an electrical circuit to have the ability
>>>> to receive the signals on the bus during sending or disable receiving during
>>>> sending.
>>>>
>>>> Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>
>>>> ---
>>>> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>>>> Cc: Rob Herring <robh+dt at kernel.org>
>>>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
>>>> Cc: Marek Vasut <marex at denx.de>
>>>> Cc: devicetree at vger.kernel.org
>>>> To: linux-serial at vger.kernel.org
>>>> To: linux-arm-kernel at lists.infradead.org
>>>> ---
>>>>  Documentation/devicetree/bindings/serial/rs485.yaml | 4 ++++
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
>>>> index 90a1bab40f05..0ebd7690f85d 100644
>>>> --- a/Documentation/devicetree/bindings/serial/rs485.yaml
>>>> +++ b/Documentation/devicetree/bindings/serial/rs485.yaml
>>>> @@ -51,6 +51,10 @@ properties:
>>>>      description: GPIO pin to enable RS485 bus termination.
>>>>      maxItems: 1
>>>>
>>>> +  rs485-rx-during-tx-gpios:
>>>> +    description: GPIO pin to control RS485 Rx enable during Tx.
>>>
>>> Active state means do what? And inactive? This is an output gating the
>>> RX signal or an input telling the receiver what to do during tx? The
>>> description is not adequate.
>>>
>>> How does this property relate to 'rs485-rx-during-tx' Any combination of
>>> the 2 being present or not is okay? If not, you need some constraints.
>>>
>>> Rob
>>
>>
>> Hi Rob,
>>
>> I have improved the message:
>>
>> The standard RS485 is a half-duplex bus that in most cased is driven by an
>> UART controller. The interface to the bus is controlled by a transceiver, that
>> has a pin called RE (Rx enable) or similar, which connects the bus to Rx signal
>> of the UART controller. This patch adds a binding for a generic definition of a
>> GPIO that can switch between two states to control the RE pin via an electrical
>> circuit:
>> - Active:
>>   The RE pin is always active. The UART Rx see everything on the bus and
>>   therefore also what happens with the Tx signal on the bus.
>> - Inactive:
>>   The RE pin is always active, but during sending on the bus the pin RE is
>>   inactive. So basically the receiving during sending is suppressed.
>>
>> Is it now more understandable, or have I still not considered an aspect?
> 
> Better.  But what about the questions Rob asked?  There's already a
> property 'rs485-rx-during-tx' which leads to setting the flag
> SER_RS485_RX_DURING_TX in serial core.  As far as I understood from a
> quick glance at core and drivers, this deals with half or full duplex
> from the UART point of view (not the transceiver).
> 
> You need to explain, what's the difference to the new property.
> I suspect you want to somehow switch behaviour with that GPIO line?
> Which driver should switch that line in the end and when?
> 
> (For third iteration of our hardware we thought about a GPIO
> controlling whether !RE is always on or connected to DE, but that's
> probably not what you have in mind?)
> 
> Maybe a simple generic schematic could help explain or maybe you find
> a better name for the property?
> 
> Greets
> Alex

Basically the idea is that this GPIO is an indicator for the state of the
flag 'rs485-rx-during-tx', so that the hardware knows which mode for the
receiving is wanted.

My schematics:
                                 ┌──────────────────┐
                                 │     RS484        │
               Tx ───────────────┤D                 │
                                 │     Transceiver  │
              RTS ────┬──────────┤DE                │
                      │          │                  │
                      │ ┌─────┐  │                  │
                      └─┤&    │  │                  │
                        │     ├──┤!RE               │
!rx_during_tx_gpio ─────┤     │  │                  │
                        └─────┘  │                  │
                                 │                  │
               Rx ───────────────┤R                 │
                                 │                  │
                                 └──────────────────┘

I muxed the UART CTS pin as GPIO and use it as rx_during_tx_gpio, because
in my case this pin is unused anyway. It should be noted that I then use
this pin LOW ACTIVE (in DT by GPIO_ACTIVE_LOW).

I hope it has become clearer what I am doing.
Do you still think I need another name?


Regards
Christoph