From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
To: Farouk Bouabid <farouk.bouabid@theobroma-systems.com>,
Lino Sanfilippo <LinoSanfilippo@gmx.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"quentin.schulz@theobroma-systems.com"
<quentin.schulz@theobroma-systems.com>,
Heiko Stuebner <heiko.stuebner@cherry.de>
Subject: RE: [PATCH v5 2/6] serial: 8250: Support separate rs485 rx-enable GPIO
Date: Tue, 30 Jan 2024 12:29:47 +0000 [thread overview]
Message-ID: <3d31b17ffd4a4f02aaaa1b6c33a09009@dh-electronics.com> (raw)
In-Reply-To: <37522087-d3ac-4cc7-b11b-c844d36206ba@theobroma-systems.com>
From: Farouk Bouabid
Sent: Monday, January 29, 2024 9:57 AM
Hi,
> On 26.01.24 20:58, Lino Sanfilippo wrote:
>> [Some people who received this message don't often get email from linosanfilippo@gmx.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi,
>>
>> On 26.01.24 18:27, Farouk Bouabid wrote:
>>> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>>>
>>> The RE signal is used to control the duplex mode of transmissions,
>>> aka receiving data while sending in full duplex mode, while stopping
>>> receiving data in half-duplex mode.
>>>
>>> On a number of boards the !RE signal is tied to ground so reception
>>> is always enabled except if the UART allows disabling the receiver.
>>> This can be taken advantage of to implement half-duplex mode - like
>>> done on 8250_bcm2835aux.
>>>
>>> Another solution is to tie !RE to RTS always forcing half-duplex mode.
>>>
>>> And finally there is the option to control the RE signal separately,
>>> like done here by introducing a new rs485-specific gpio that can be
>>> set depending on the RX_DURING_TX setting in the common em485 callbacks.
>>>
>> we just added the rx_during_tx_gpio to the serial core.
>> Why cant you use this GPIO for your purpose?
>>
>> Regards,
>> Lino.
> What we are trying to implement is a gpio that emulates the RTS signal
> itself as we do not have a dedicated RTS signal that can be controlled
> through MCR. The rx during tx state in our case is a fixed state of
> "NO_RX_WHILE_TX"
Why can't the property rts-gpios be used here for this purpose?
Regards
Christoph
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
To: Farouk Bouabid <farouk.bouabid@theobroma-systems.com>,
Lino Sanfilippo <LinoSanfilippo@gmx.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"quentin.schulz@theobroma-systems.com"
<quentin.schulz@theobroma-systems.com>,
Heiko Stuebner <heiko.stuebner@cherry.de>
Subject: RE: [PATCH v5 2/6] serial: 8250: Support separate rs485 rx-enable GPIO
Date: Tue, 30 Jan 2024 12:29:47 +0000 [thread overview]
Message-ID: <3d31b17ffd4a4f02aaaa1b6c33a09009@dh-electronics.com> (raw)
In-Reply-To: <37522087-d3ac-4cc7-b11b-c844d36206ba@theobroma-systems.com>
From: Farouk Bouabid
Sent: Monday, January 29, 2024 9:57 AM
Hi,
> On 26.01.24 20:58, Lino Sanfilippo wrote:
>> [Some people who received this message don't often get email from linosanfilippo@gmx.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi,
>>
>> On 26.01.24 18:27, Farouk Bouabid wrote:
>>> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>>>
>>> The RE signal is used to control the duplex mode of transmissions,
>>> aka receiving data while sending in full duplex mode, while stopping
>>> receiving data in half-duplex mode.
>>>
>>> On a number of boards the !RE signal is tied to ground so reception
>>> is always enabled except if the UART allows disabling the receiver.
>>> This can be taken advantage of to implement half-duplex mode - like
>>> done on 8250_bcm2835aux.
>>>
>>> Another solution is to tie !RE to RTS always forcing half-duplex mode.
>>>
>>> And finally there is the option to control the RE signal separately,
>>> like done here by introducing a new rs485-specific gpio that can be
>>> set depending on the RX_DURING_TX setting in the common em485 callbacks.
>>>
>> we just added the rx_during_tx_gpio to the serial core.
>> Why cant you use this GPIO for your purpose?
>>
>> Regards,
>> Lino.
> What we are trying to implement is a gpio that emulates the RTS signal
> itself as we do not have a dedicated RTS signal that can be controlled
> through MCR. The rx during tx state in our case is a fixed state of
> "NO_RX_WHILE_TX"
Why can't the property rts-gpios be used here for this purpose?
Regards
Christoph
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
To: Farouk Bouabid <farouk.bouabid@theobroma-systems.com>,
Lino Sanfilippo <LinoSanfilippo@gmx.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"quentin.schulz@theobroma-systems.com"
<quentin.schulz@theobroma-systems.com>,
Heiko Stuebner <heiko.stuebner@cherry.de>
Subject: RE: [PATCH v5 2/6] serial: 8250: Support separate rs485 rx-enable GPIO
Date: Tue, 30 Jan 2024 12:29:47 +0000 [thread overview]
Message-ID: <3d31b17ffd4a4f02aaaa1b6c33a09009@dh-electronics.com> (raw)
In-Reply-To: <37522087-d3ac-4cc7-b11b-c844d36206ba@theobroma-systems.com>
From: Farouk Bouabid
Sent: Monday, January 29, 2024 9:57 AM
Hi,
> On 26.01.24 20:58, Lino Sanfilippo wrote:
>> [Some people who received this message don't often get email from linosanfilippo@gmx.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi,
>>
>> On 26.01.24 18:27, Farouk Bouabid wrote:
>>> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>>>
>>> The RE signal is used to control the duplex mode of transmissions,
>>> aka receiving data while sending in full duplex mode, while stopping
>>> receiving data in half-duplex mode.
>>>
>>> On a number of boards the !RE signal is tied to ground so reception
>>> is always enabled except if the UART allows disabling the receiver.
>>> This can be taken advantage of to implement half-duplex mode - like
>>> done on 8250_bcm2835aux.
>>>
>>> Another solution is to tie !RE to RTS always forcing half-duplex mode.
>>>
>>> And finally there is the option to control the RE signal separately,
>>> like done here by introducing a new rs485-specific gpio that can be
>>> set depending on the RX_DURING_TX setting in the common em485 callbacks.
>>>
>> we just added the rx_during_tx_gpio to the serial core.
>> Why cant you use this GPIO for your purpose?
>>
>> Regards,
>> Lino.
> What we are trying to implement is a gpio that emulates the RTS signal
> itself as we do not have a dedicated RTS signal that can be controlled
> through MCR. The rx during tx state in our case is a fixed state of
> "NO_RX_WHILE_TX"
Why can't the property rts-gpios be used here for this purpose?
Regards
Christoph
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-30 12:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 17:27 [PATCH v5 0/6] serial: 8250: Add support for rs485 half/full duplex on puma/ringneck-haikou Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` [PATCH v5 1/6] dt-bindings: serial: Add binding for rs485 receiver enable GPIO Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-30 22:56 ` Rob Herring
2024-01-30 22:56 ` Rob Herring
2024-01-30 22:56 ` Rob Herring
2024-01-26 17:27 ` [PATCH v5 2/6] serial: 8250: Support separate rs485 rx-enable GPIO Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 19:58 ` Lino Sanfilippo
2024-01-26 19:58 ` Lino Sanfilippo
2024-01-26 19:58 ` Lino Sanfilippo
2024-01-29 8:57 ` Farouk Bouabid
2024-01-29 8:57 ` Farouk Bouabid
2024-01-29 8:57 ` Farouk Bouabid
2024-01-30 12:29 ` Christoph Niedermaier [this message]
2024-01-30 12:29 ` Christoph Niedermaier
2024-01-30 12:29 ` Christoph Niedermaier
2024-02-08 15:46 ` Farouk Bouabid
2024-02-08 15:46 ` Farouk Bouabid
2024-02-08 15:46 ` Farouk Bouabid
2024-01-26 17:27 ` [PATCH v5 3/6] dt-bindings: serial: add binding for rs485 rx-enable state when rs485 is disabled Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-30 23:02 ` Rob Herring
2024-01-30 23:02 ` Rob Herring
2024-01-30 23:02 ` Rob Herring
2024-01-26 17:27 ` [PATCH v5 4/6] serial: 8250: set rx-enable gpio " Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` [PATCH v5 5/6] arm64: dts: rockchip: rk3399-puma-haikou: add rs485 support on uart2 Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` [PATCH v5 6/6] arm64: dts: rockchip: px30-ringneck-haikou: add rs485 support on uart5 Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
2024-01-26 17:27 ` Farouk Bouabid
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d31b17ffd4a4f02aaaa1b6c33a09009@dh-electronics.com \
--to=cniedermaier@dh-electronics.com \
--cc=LinoSanfilippo@gmx.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=farouk.bouabid@theobroma-systems.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.stuebner@cherry.de \
--cc=heiko@sntech.de \
--cc=jirislaby@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=quentin.schulz@theobroma-systems.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.