lkml.org 
[lkml]   [2023]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding
    Date
    From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
    Sent: Thursday, December 14, 2023 3:04 PM
    >
    > Hi,
    >
    > On 14.12.23 14:41, Christoph Niedermaier wrote:
    >> From: Crescent CY Hsieh <crescentcy.hsieh@moxa.com>
    >> Sent: Thursday, December 14, 2023 11:25 AM
    >>> On Mon, Dec 11, 2023 at 03:07:59PM +0200, Andy Shevchenko wrote:
    >>>> On Sat, Dec 09, 2023 at 12:47:47PM +0100, Lino Sanfilippo wrote:
    >>>>> On 06.12.23 16:42, Lino Sanfilippo wrote:
    >>>>
    >>>>>>>>> Crescent CY Hsieh (+cc) is in parallel trying to add an RS-422 mode bit
    >>>>>>>>> to struct serial_rs485:
    >>>>>>>>>
    >>>>>>>>> https://lore.kernel.org/all/20231121095122.15948-1-crescentcy.hsieh@moxa.com/
    >>>>>>>>>
    >>>>>>>>
    >>>>>>>> That new flag was suggested by me instead of using SER_RS422_ENABLED, which
    >>>>>>>> would mostly be redundant to SER_RS485_ENABLED.
    >>>>>
    >>>>> A cleaner solution would probably be to not handle RS422 with the RS485 settings at
    >>>>> all, but to introduce another set of ioctls to set and read it.
    >>>>>
    >>>>> An own RS422 structure like
    >>>>>
    >>>>> struct serial_rs422 {
    >>>>> __u32 flags;
    >>>>> #define SER_RS422_ENABLED (1 << 0)
    >>>>> #define SER_RS422_TERMINATE_BUS (1 << 1)
    >>>>> };
    >>>>>
    >>>>>
    >>>>> could be used as the parameter for these new ioctls.
    >>>>>
    >>>>> Any comments on this?
    >>>>
    >>>> I have (maybe not so constructive) a comment. Please, at all means try to not
    >>>> extend the existing serial data structures, we have too many ones with too many
    >>>> fields already. For user space, though, one may use unions and flags, but for
    >>>> internal ones it might be better ways, I think.
    >>>
    >>> How about revising the name of 'TIOCSRS485' and 'serial_rs485' to a
    >>> general one, and put RS422 and RS485 configuration flags into that
    >>> structure?
    >>>
    >>> So that in userspace it could set RS422 or RS485 configurations using a
    >>> single ioctl command and one structure.
    >>>
    >>> In this way, it won't be confused in userspace and won't add new data
    >>> structure internally as well.
    >>>
    >>
    >> I will summarize the current situation from my point of view, maybe it helps:
    >>
    >> RS-232:
    >> - Full Duplex Point-to-Point connection
    >> - No transceiver control with RTS
    >> - No termination
    >> - No extra struct in use
    >>
    >> RS-422:
    >> - Full Duplex Point-to-Point connection
    >> - No transceiver control with RTS needed
    >> - Termination possible
    >> - Extra struct serial_rs485 needed if termination is used
    >> => RS-422 can be used in RS-232 operation, but if a termination should be
    >> switchable the RS485 flag has to be enabled. But then also transceiver
    >> control will be enabled. Not a very satisfying situation.
    >>
    >
    > Thats why I vote for a RS422 mode.
    >
    >> RS-485 (2-wire) very common:
    >> - Half Duplex RS-485 bus
    >> - Transceiver control with RTS is needed
    >> - Termination possible
    >> - Extra struct serial_rs485 is needed
    >> => RS-485 has to be enabled and configured:
    >> - Set SER_RS485_ENABLED
    >> - Set SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND
    >> - Set/clear SER_RS485_RX_DURING_TX depending on whether
    >> the receiver path should be on or off during sending.
    >> If it's set it allows to monitor the sending on the bus
    >> and detect whether another bus device is transmitting
    >> at the same time.
    >> - Set/clear SER_RS485_TERMINATE_BUS for bus termination.
    >>
    >> RS-485 (4-wire) little used:
    >> - Full Duplex RS-485 bus
    >> - Transceiver control with RTS is needed
    >> - Termination possible
    >> - Extra struct serial_rs485 is needed
    >> => RS-485 has to be enabled and configured:
    >> - Set SER_RS485_ENABLED
    >> - Set SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND
    >> - Set SER_RS485_RX_DURING_TX, as the receiver should always
    >> be enabled independently of TX, because TX and RX are
    >> separated from each other by their own wires.
    >> - Set/clear SER_RS485_TERMINATE_BUS for bus termination.
    >
    > How can the driver distinguish between RS485 full duplex and half duplex then?
    > In full duplex RTS control is not needed AFAIU.

    I think we don't need to distinguish, because for a full duplex RS-485
    transceiver also needs RTS control. For example look at the full duplex
    RS-485 transceiver ADM3491E [1]. It's a full duplex transceiver (A/B and Z/Y)
    that has DE (Driver enable) and DI (Driver Input) pins for controlling TX. I
    think the RS-485 master doesn't need it. The DE pin could also be set
    permanently high. But if we have more than one RS-485 slaves it's needed to
    avoid blocking of each other on the receiving wires of the RS-485 master.

    [1] https://www.analog.com/en/products/adm3491e.html

    >> I think the GPIOs reflect the flag states and are meaningful:
    >> - SER_RS485_TERMINATE_BUS: Switch bus termination on/off by GPIO
    >> - SER_RS485_RX_DURING_TX: Used to enable/disable RX during TX
    >> in hardware by GPIO (for 2-wire)
    >> - SER_RS485_ENABLED: Muxing between RS-232 and RS-485 by GPIO
    >>
    >> Switching RS-485 on during boot could also be handled by a devicetree
    >> overlay. Evaluate the GPIO and load a DTO accordingly before booting.
    >>
    >> Please correct me if I have misrepresented something...
    >>
    >> If I looked at it in this new way, I would discard my idea with the
    >> FULL_DUPLEX and HALF_DUPLEX. For a better use of RS-422 it would be
    >> good to disable transceiver control via RTS. It can be done by clearing
    >> the existing flags SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND
    >> at the same time, but I think it is confusing. Better would be a flag
    >> for RS-422:
    >>
    >> RS-422: Set SER_RS422_MODE for disabling
    >> transceiver control via RTS.
    >> RS-485 (2-wire and 4-wire): Clear SER_RS422_MODE for enabling
    >> transceiver control via RTS.
    >>
    >> Finally, at present it is also not possible to distinguish between RS485
    >> 2-wire and 4-wire operation. I think it isn't necessary, as different
    >> hardware has to be used anyway. The hardware then determines the
    >> configuration, see above.
    >
    > But the driver should somehow be informed that there exists a full
    > duplex hardware setup, so that it does not need to control the RTS line.
    > Maybe by means of a device tree property?

    See above.

    Regards
    Christoph
    \
     
     \ /
      Last update: 2023-12-14 15:52    [W:4.316 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site