Skip to content

Conversation

@hase86
Copy link

@hase86 hase86 commented Sep 18, 2019

rs485 allows for robust half-duplex serial communication. It is often
implemented by attaching an rs485 transceiver to a UART. The UART's
RTS line is wired to the transceiver's Transmit Enable pin and
determines whether the transceiver is sending or receiving.

Examples for such transceivers are Maxim MAX13451E and TI SN65HVD1781A:
https://datasheets.maximintegrated.com/en/ds/MAX13450E-MAX13451E.pdf
http://www.ti.com/lit/ds/symlink/sn65hvd1781a-q1.pdf

In the devicetree, the transceiver itself is not represented, only the
UART is. A few rs485-specific dt-bindings already exist and these go
into the UART's device node.

This commit adds a binding to set the RTS polarity. Most (if not all)
transceivers require the Transmit Enable pin be driven high for sending,
but in some cases boards may negate the pin and RTS must then be driven
low. Consequently the polarity defaults to active high but can be
inverted with the newly added "rs485-rts-active-low" binding.

rs485 allows for robust half-duplex serial communication.  It is often
implemented by attaching an rs485 transceiver to a UART.  The UART's
RTS line is wired to the transceiver's Transmit Enable pin and
determines whether the transceiver is sending or receiving.

Examples for such transceivers are Maxim MAX13451E and TI SN65HVD1781A:
https://datasheets.maximintegrated.com/en/ds/MAX13450E-MAX13451E.pdf
http://www.ti.com/lit/ds/symlink/sn65hvd1781a-q1.pdf

In the devicetree, the transceiver itself is not represented, only the
UART is. A few rs485-specific dt-bindings already exist and these go
into the UART's device node.

This commit adds a binding to set the RTS polarity.  Most (if not all)
transceivers require the Transmit Enable pin be driven high for sending,
but in some cases boards may negate the pin and RTS must then be driven
low. Consequently the polarity defaults to active high but can be
inverted with the newly added "rs485-rts-active-low" binding.
@pelwell
Copy link
Contributor

pelwell commented Sep 25, 2019

This patch should be submitted upstream. Once accepted, we'll back-port it.

The upstream devs will want a commit message which isn't just copied from 6abe9ea.

Something simple like:

tty: amba-pl011: Add software emulated RS485 support for pl011

...

Signed-off-by: Your Name <[email protected]>

if (cr_old != cr) {
pl011_write(cr, uap, REG_CR);
if (port->rs485.delay_rts_before_send > 0) {
mdelay(port->rs485.delay_rts_before_send);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please try to find a better solution which doesn't waste the CPU power.

@sistik
Copy link

sistik commented Feb 17, 2020

I have created new implementation of RS485 for PL011.
Pending patch:
https://patchwork.kernel.org/patch/11320241/

@RuhanSA079
Copy link

Hello, is there any plans to merge this PR into the base branch and make it available in the newest rev. kernel?

@pelwell
Copy link
Contributor

pelwell commented Feb 4, 2021

We're all waiting for the patch to be accepted upstream - it's a significant change to a common driver, and we don't want to maintain it downstream.

@RuhanSA079 RuhanSA079 mentioned this pull request Oct 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants