* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 9:14 ` Stefan Agner 0 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 9:14 UTC (permalink / raw) To: s.hauer, u.kleine-koenig, baruch; +Cc: linux-arm-kernel, linux-serial Hi, Using upstream I noticed that RS-485 does not work in the default configuration for our platforms (Toradex Apalis/Colibri). Closer debugging shows that it is related to "serial: imx: default to half duplex rs485". We use the i.MX UART in DTE mode and control the RS-485 transceiver using the RTS signal in low-active mode. uart-has-rtscts; fsl,dte-mode; linux,rs485-enabled-at-boot-time; rs485-rts-active-low; Using this setting leads to the RTS signal not getting asserted (the oscilloscope only shows a very short fluke before the start bit is sent). However, using uart-has-rtscts; fsl,dte-mode; linux,rs485-enabled-at-boot-time; rs485-rts-active-low; rs485-rx-during-tx; Asserts the RTS signal low active just fine... Is this a known problem? Any idea where that could come from? It looks as if the receiver part is actually enabling RTS...? Also, isn't enabling RX even in half-duplex mode quite common in order to detect collisions? -- Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 9:14 ` Stefan Agner 0 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 9:14 UTC (permalink / raw) To: linux-arm-kernel Hi, Using upstream I noticed that RS-485 does not work in the default configuration for our platforms (Toradex Apalis/Colibri). Closer debugging shows that it is related to "serial: imx: default to half duplex rs485". We use the i.MX UART in DTE mode and control the RS-485 transceiver using the RTS signal in low-active mode. uart-has-rtscts; fsl,dte-mode; linux,rs485-enabled-at-boot-time; rs485-rts-active-low; Using this setting leads to the RTS signal not getting asserted (the oscilloscope only shows a very short fluke before the start bit is sent). However, using uart-has-rtscts; fsl,dte-mode; linux,rs485-enabled-at-boot-time; rs485-rts-active-low; rs485-rx-during-tx; Asserts the RTS signal low active just fine... Is this a known problem? Any idea where that could come from? It looks as if the receiver part is actually enabling RTS...? Also, isn't enabling RX even in half-duplex mode quite common in order to detect collisions? -- Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 9:14 ` Stefan Agner @ 2018-04-16 9:22 ` Uwe Kleine-König -1 siblings, 0 replies; 20+ messages in thread From: Uwe Kleine-König @ 2018-04-16 9:22 UTC (permalink / raw) To: Stefan Agner; +Cc: linux-arm-kernel, s.hauer, baruch, linux-serial Hi Stefan, On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: > Using upstream I noticed that RS-485 does not work in the default > configuration for our platforms (Toradex Apalis/Colibri). Closer This is an i.MX6? > debugging shows that it is related to "serial: imx: default to half > duplex rs485". > > We use the i.MX UART in DTE mode and control the RS-485 transceiver > using the RTS signal in low-active mode. > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; That means you're not using a GPIO for RTS signaling, right? > Using this setting leads to the RTS signal not getting asserted (the > oscilloscope only shows a very short fluke before the start bit is > sent). > > However, using > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; > rs485-rx-during-tx; > > Asserts the RTS signal low active just fine... > > Is this a known problem? Any idea where that could come from? It looks > as if the receiver part is actually enabling RTS...? Which kernel version do you use? My latest rs485 related patches went into v4.17-rc1. With that I managed to make rs485 half duplex work on several customer boards. > Also, isn't enabling RX even in half-duplex mode quite common in order > to detect collisions? I don't know. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 9:22 ` Uwe Kleine-König 0 siblings, 0 replies; 20+ messages in thread From: Uwe Kleine-König @ 2018-04-16 9:22 UTC (permalink / raw) To: linux-arm-kernel Hi Stefan, On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: > Using upstream I noticed that RS-485 does not work in the default > configuration for our platforms (Toradex Apalis/Colibri). Closer This is an i.MX6? > debugging shows that it is related to "serial: imx: default to half > duplex rs485". > > We use the i.MX UART in DTE mode and control the RS-485 transceiver > using the RTS signal in low-active mode. > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; That means you're not using a GPIO for RTS signaling, right? > Using this setting leads to the RTS signal not getting asserted (the > oscilloscope only shows a very short fluke before the start bit is > sent). > > However, using > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; > rs485-rx-during-tx; > > Asserts the RTS signal low active just fine... > > Is this a known problem? Any idea where that could come from? It looks > as if the receiver part is actually enabling RTS...? Which kernel version do you use? My latest rs485 related patches went into v4.17-rc1. With that I managed to make rs485 half duplex work on several customer boards. > Also, isn't enabling RX even in half-duplex mode quite common in order > to detect collisions? I don't know. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 9:22 ` Uwe Kleine-König @ 2018-04-16 10:29 ` Stefan Agner -1 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 10:29 UTC (permalink / raw) To: Uwe Kleine-König; +Cc: s.hauer, baruch, linux-arm-kernel, linux-serial On 16.04.2018 11:22, Uwe Kleine-König wrote: > Hi Stefan, > > On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >> Using upstream I noticed that RS-485 does not work in the default >> configuration for our platforms (Toradex Apalis/Colibri). Closer > > This is an i.MX6? > Yes, sorry about that. But I think it is i.MX UART specific, I noticed the same behavior on i.MX 7 too. >> debugging shows that it is related to "serial: imx: default to half >> duplex rs485". >> >> We use the i.MX UART in DTE mode and control the RS-485 transceiver >> using the RTS signal in low-active mode. >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; > > That means you're not using a GPIO for RTS signaling, right? > I use native RTS capability (which is in DTE mode the CTS signal...) >> Using this setting leads to the RTS signal not getting asserted (the >> oscilloscope only shows a very short fluke before the start bit is >> sent). Just FYI, the fluke looks like a proper assert, but it is really only 50ns wide. >> >> However, using >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; >> rs485-rx-during-tx; >> >> Asserts the RTS signal low active just fine... >> >> Is this a known problem? Any idea where that could come from? It looks >> as if the receiver part is actually enabling RTS...? > > Which kernel version do you use? My latest rs485 related patches went > into v4.17-rc1. With that I managed to make rs485 half duplex work on > several customer boards. I used v4.17-rc1. I noticed your changes, but I it seems they make no difference, last week I noticed the same issue in v4.16. Do those customer boards use DTE mode? -- Stefan > >> Also, isn't enabling RX even in half-duplex mode quite common in order >> to detect collisions? > > I don't know. > Probably also depends on the exact use case and the transceiver configuration. -- Stefan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 10:29 ` Stefan Agner 0 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 10:29 UTC (permalink / raw) To: linux-arm-kernel On 16.04.2018 11:22, Uwe Kleine-K?nig wrote: > Hi Stefan, > > On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >> Using upstream I noticed that RS-485 does not work in the default >> configuration for our platforms (Toradex Apalis/Colibri). Closer > > This is an i.MX6? > Yes, sorry about that. But I think it is i.MX UART specific, I noticed the same behavior on i.MX 7 too. >> debugging shows that it is related to "serial: imx: default to half >> duplex rs485". >> >> We use the i.MX UART in DTE mode and control the RS-485 transceiver >> using the RTS signal in low-active mode. >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; > > That means you're not using a GPIO for RTS signaling, right? > I use native RTS capability (which is in DTE mode the CTS signal...) >> Using this setting leads to the RTS signal not getting asserted (the >> oscilloscope only shows a very short fluke before the start bit is >> sent). Just FYI, the fluke looks like a proper assert, but it is really only 50ns wide. >> >> However, using >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; >> rs485-rx-during-tx; >> >> Asserts the RTS signal low active just fine... >> >> Is this a known problem? Any idea where that could come from? It looks >> as if the receiver part is actually enabling RTS...? > > Which kernel version do you use? My latest rs485 related patches went > into v4.17-rc1. With that I managed to make rs485 half duplex work on > several customer boards. I used v4.17-rc1. I noticed your changes, but I it seems they make no difference, last week I noticed the same issue in v4.16. Do those customer boards use DTE mode? -- Stefan > >> Also, isn't enabling RX even in half-duplex mode quite common in order >> to detect collisions? > > I don't know. > Probably also depends on the exact use case and the transceiver configuration. -- Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 10:29 ` Stefan Agner @ 2018-04-16 13:01 ` Stefan Agner -1 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 13:01 UTC (permalink / raw) To: Uwe Kleine-König; +Cc: s.hauer, baruch, linux-arm-kernel, linux-serial On 16.04.2018 12:29, Stefan Agner wrote: > On 16.04.2018 11:22, Uwe Kleine-König wrote: >> Hi Stefan, >> >> On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >>> Using upstream I noticed that RS-485 does not work in the default >>> configuration for our platforms (Toradex Apalis/Colibri). Closer >> >> This is an i.MX6? >> > > Yes, sorry about that. > > But I think it is i.MX UART specific, I noticed the same behavior on > i.MX 7 too. > >>> debugging shows that it is related to "serial: imx: default to half >>> duplex rs485". >>> >>> We use the i.MX UART in DTE mode and control the RS-485 transceiver >>> using the RTS signal in low-active mode. >>> >>> uart-has-rtscts; >>> fsl,dte-mode; >>> linux,rs485-enabled-at-boot-time; >>> rs485-rts-active-low; >> >> That means you're not using a GPIO for RTS signaling, right? >> > > I use native RTS capability (which is in DTE mode the CTS signal...) > >>> Using this setting leads to the RTS signal not getting asserted (the >>> oscilloscope only shows a very short fluke before the start bit is >>> sent). > > Just FYI, the fluke looks like a proper assert, but it is really only > 50ns wide. > Also tried DCE mode, the same behavior. Two screenshots showing TX/RTS (CTS_B) in different settings: https://imgur.com/a/PbUex The little fluke disappears when disabling RX before setting CTSC: --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -657,6 +657,9 @@ static void imx_uart_start_tx(struct uart_port *port) if (port->rs485.flags & SER_RS485_ENABLED) { u32 ucr2; + if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) + imx_uart_stop_rx(port); + ucr2 = imx_uart_readl(sport, UCR2); if (port->rs485.flags & SER_RS485_RTS_ON_SEND) imx_uart_rts_active(sport, &ucr2); @@ -664,9 +667,6 @@ static void imx_uart_start_tx(struct uart_port *port) imx_uart_rts_inactive(sport, &ucr2); imx_uart_writel(sport, ucr2, UCR2); - if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) - imx_uart_stop_rx(port); - /* * Enable transmitter and shifter empty irq only if DMA is off. * In the DMA case this is done in the tx-callback. It seems that if the RX path is disabled, CTS_B is no longer controllable. It just stays high. That is not a problem in the high active RTS case... However, it breaks low active half-duplex... It seems that this thread is describing this situation: https://community.nxp.com/thread/385047 -- Stefan >>> >>> However, using >>> >>> uart-has-rtscts; >>> fsl,dte-mode; >>> linux,rs485-enabled-at-boot-time; >>> rs485-rts-active-low; >>> rs485-rx-during-tx; >>> >>> Asserts the RTS signal low active just fine... >>> >>> Is this a known problem? Any idea where that could come from? It looks >>> as if the receiver part is actually enabling RTS...? >> >> Which kernel version do you use? My latest rs485 related patches went >> into v4.17-rc1. With that I managed to make rs485 half duplex work on >> several customer boards. > > I used v4.17-rc1. > > I noticed your changes, but I it seems they make no difference, last > week I noticed the same issue in v4.16. > > Do those customer boards use DTE mode? > > -- > Stefan > >> >>> Also, isn't enabling RX even in half-duplex mode quite common in order >>> to detect collisions? >> >> I don't know. >> > > Probably also depends on the exact use case and the transceiver > configuration. > > -- > Stefan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 13:01 ` Stefan Agner 0 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 13:01 UTC (permalink / raw) To: linux-arm-kernel On 16.04.2018 12:29, Stefan Agner wrote: > On 16.04.2018 11:22, Uwe Kleine-K?nig wrote: >> Hi Stefan, >> >> On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >>> Using upstream I noticed that RS-485 does not work in the default >>> configuration for our platforms (Toradex Apalis/Colibri). Closer >> >> This is an i.MX6? >> > > Yes, sorry about that. > > But I think it is i.MX UART specific, I noticed the same behavior on > i.MX 7 too. > >>> debugging shows that it is related to "serial: imx: default to half >>> duplex rs485". >>> >>> We use the i.MX UART in DTE mode and control the RS-485 transceiver >>> using the RTS signal in low-active mode. >>> >>> uart-has-rtscts; >>> fsl,dte-mode; >>> linux,rs485-enabled-at-boot-time; >>> rs485-rts-active-low; >> >> That means you're not using a GPIO for RTS signaling, right? >> > > I use native RTS capability (which is in DTE mode the CTS signal...) > >>> Using this setting leads to the RTS signal not getting asserted (the >>> oscilloscope only shows a very short fluke before the start bit is >>> sent). > > Just FYI, the fluke looks like a proper assert, but it is really only > 50ns wide. > Also tried DCE mode, the same behavior. Two screenshots showing TX/RTS (CTS_B) in different settings: https://imgur.com/a/PbUex The little fluke disappears when disabling RX before setting CTSC: --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -657,6 +657,9 @@ static void imx_uart_start_tx(struct uart_port *port) if (port->rs485.flags & SER_RS485_ENABLED) { u32 ucr2; + if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) + imx_uart_stop_rx(port); + ucr2 = imx_uart_readl(sport, UCR2); if (port->rs485.flags & SER_RS485_RTS_ON_SEND) imx_uart_rts_active(sport, &ucr2); @@ -664,9 +667,6 @@ static void imx_uart_start_tx(struct uart_port *port) imx_uart_rts_inactive(sport, &ucr2); imx_uart_writel(sport, ucr2, UCR2); - if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) - imx_uart_stop_rx(port); - /* * Enable transmitter and shifter empty irq only if DMA is off. * In the DMA case this is done in the tx-callback. It seems that if the RX path is disabled, CTS_B is no longer controllable. It just stays high. That is not a problem in the high active RTS case... However, it breaks low active half-duplex... It seems that this thread is describing this situation: https://community.nxp.com/thread/385047 -- Stefan >>> >>> However, using >>> >>> uart-has-rtscts; >>> fsl,dte-mode; >>> linux,rs485-enabled-at-boot-time; >>> rs485-rts-active-low; >>> rs485-rx-during-tx; >>> >>> Asserts the RTS signal low active just fine... >>> >>> Is this a known problem? Any idea where that could come from? It looks >>> as if the receiver part is actually enabling RTS...? >> >> Which kernel version do you use? My latest rs485 related patches went >> into v4.17-rc1. With that I managed to make rs485 half duplex work on >> several customer boards. > > I used v4.17-rc1. > > I noticed your changes, but I it seems they make no difference, last > week I noticed the same issue in v4.16. > > Do those customer boards use DTE mode? > > -- > Stefan > >> >>> Also, isn't enabling RX even in half-duplex mode quite common in order >>> to detect collisions? >> >> I don't know. >> > > Probably also depends on the exact use case and the transceiver > configuration. > > -- > Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 13:01 ` Stefan Agner @ 2018-04-16 13:42 ` Uwe Kleine-König -1 siblings, 0 replies; 20+ messages in thread From: Uwe Kleine-König @ 2018-04-16 13:42 UTC (permalink / raw) To: Stefan Agner; +Cc: s.hauer, baruch, linux-arm-kernel, linux-serial On Mon, Apr 16, 2018 at 03:01:44PM +0200, Stefan Agner wrote: > On 16.04.2018 12:29, Stefan Agner wrote: > > On 16.04.2018 11:22, Uwe Kleine-König wrote: > >> Hi Stefan, > >> > >> On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: > >>> Using upstream I noticed that RS-485 does not work in the default > >>> configuration for our platforms (Toradex Apalis/Colibri). Closer > >> > >> This is an i.MX6? > >> > > > > Yes, sorry about that. > > > > But I think it is i.MX UART specific, I noticed the same behavior on > > i.MX 7 too. > > > >>> debugging shows that it is related to "serial: imx: default to half > >>> duplex rs485". > >>> > >>> We use the i.MX UART in DTE mode and control the RS-485 transceiver > >>> using the RTS signal in low-active mode. > >>> > >>> uart-has-rtscts; > >>> fsl,dte-mode; > >>> linux,rs485-enabled-at-boot-time; > >>> rs485-rts-active-low; > >> > >> That means you're not using a GPIO for RTS signaling, right? > >> > > > > I use native RTS capability (which is in DTE mode the CTS signal...) > > > >>> Using this setting leads to the RTS signal not getting asserted (the > >>> oscilloscope only shows a very short fluke before the start bit is > >>> sent). > > > > Just FYI, the fluke looks like a proper assert, but it is really only > > 50ns wide. > > > > Also tried DCE mode, the same behavior. > > Two screenshots showing TX/RTS (CTS_B) in different settings: > https://imgur.com/a/PbUex > > The little fluke disappears when disabling RX before setting CTSC: > > --- a/drivers/tty/serial/imx.c > +++ b/drivers/tty/serial/imx.c > @@ -657,6 +657,9 @@ static void imx_uart_start_tx(struct uart_port > *port) > if (port->rs485.flags & SER_RS485_ENABLED) { > u32 ucr2; > > + if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) > + imx_uart_stop_rx(port); > + > ucr2 = imx_uart_readl(sport, UCR2); > if (port->rs485.flags & SER_RS485_RTS_ON_SEND) > imx_uart_rts_active(sport, &ucr2); > @@ -664,9 +667,6 @@ static void imx_uart_start_tx(struct uart_port > *port) > imx_uart_rts_inactive(sport, &ucr2); > imx_uart_writel(sport, ucr2, UCR2); > > - if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) > - imx_uart_stop_rx(port); > - > /* > * Enable transmitter and shifter empty irq only if DMA > is off. > * In the DMA case this is done in the tx-callback. > > It seems that if the RX path is disabled, CTS_B is no longer > controllable. It just stays high. That is not a problem in the high > active RTS case... However, it breaks low active half-duplex... > > It seems that this thread is describing this situation: > https://community.nxp.com/thread/385047 So better use a gpio instead of the hardware-function? Adding a respective check in the driver would be nice though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 13:42 ` Uwe Kleine-König 0 siblings, 0 replies; 20+ messages in thread From: Uwe Kleine-König @ 2018-04-16 13:42 UTC (permalink / raw) To: linux-arm-kernel On Mon, Apr 16, 2018 at 03:01:44PM +0200, Stefan Agner wrote: > On 16.04.2018 12:29, Stefan Agner wrote: > > On 16.04.2018 11:22, Uwe Kleine-K?nig wrote: > >> Hi Stefan, > >> > >> On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: > >>> Using upstream I noticed that RS-485 does not work in the default > >>> configuration for our platforms (Toradex Apalis/Colibri). Closer > >> > >> This is an i.MX6? > >> > > > > Yes, sorry about that. > > > > But I think it is i.MX UART specific, I noticed the same behavior on > > i.MX 7 too. > > > >>> debugging shows that it is related to "serial: imx: default to half > >>> duplex rs485". > >>> > >>> We use the i.MX UART in DTE mode and control the RS-485 transceiver > >>> using the RTS signal in low-active mode. > >>> > >>> uart-has-rtscts; > >>> fsl,dte-mode; > >>> linux,rs485-enabled-at-boot-time; > >>> rs485-rts-active-low; > >> > >> That means you're not using a GPIO for RTS signaling, right? > >> > > > > I use native RTS capability (which is in DTE mode the CTS signal...) > > > >>> Using this setting leads to the RTS signal not getting asserted (the > >>> oscilloscope only shows a very short fluke before the start bit is > >>> sent). > > > > Just FYI, the fluke looks like a proper assert, but it is really only > > 50ns wide. > > > > Also tried DCE mode, the same behavior. > > Two screenshots showing TX/RTS (CTS_B) in different settings: > https://imgur.com/a/PbUex > > The little fluke disappears when disabling RX before setting CTSC: > > --- a/drivers/tty/serial/imx.c > +++ b/drivers/tty/serial/imx.c > @@ -657,6 +657,9 @@ static void imx_uart_start_tx(struct uart_port > *port) > if (port->rs485.flags & SER_RS485_ENABLED) { > u32 ucr2; > > + if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) > + imx_uart_stop_rx(port); > + > ucr2 = imx_uart_readl(sport, UCR2); > if (port->rs485.flags & SER_RS485_RTS_ON_SEND) > imx_uart_rts_active(sport, &ucr2); > @@ -664,9 +667,6 @@ static void imx_uart_start_tx(struct uart_port > *port) > imx_uart_rts_inactive(sport, &ucr2); > imx_uart_writel(sport, ucr2, UCR2); > > - if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) > - imx_uart_stop_rx(port); > - > /* > * Enable transmitter and shifter empty irq only if DMA > is off. > * In the DMA case this is done in the tx-callback. > > It seems that if the RX path is disabled, CTS_B is no longer > controllable. It just stays high. That is not a problem in the high > active RTS case... However, it breaks low active half-duplex... > > It seems that this thread is describing this situation: > https://community.nxp.com/thread/385047 So better use a gpio instead of the hardware-function? Adding a respective check in the driver would be nice though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 13:42 ` Uwe Kleine-König @ 2018-04-16 16:12 ` Stefan Agner -1 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 16:12 UTC (permalink / raw) To: Uwe Kleine-König; +Cc: s.hauer, baruch, linux-arm-kernel, linux-serial On 16.04.2018 15:42, Uwe Kleine-König wrote: > On Mon, Apr 16, 2018 at 03:01:44PM +0200, Stefan Agner wrote: >> On 16.04.2018 12:29, Stefan Agner wrote: >> > On 16.04.2018 11:22, Uwe Kleine-König wrote: >> >> Hi Stefan, >> >> >> >> On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >> >>> Using upstream I noticed that RS-485 does not work in the default >> >>> configuration for our platforms (Toradex Apalis/Colibri). Closer >> >> >> >> This is an i.MX6? >> >> >> > >> > Yes, sorry about that. >> > >> > But I think it is i.MX UART specific, I noticed the same behavior on >> > i.MX 7 too. >> > >> >>> debugging shows that it is related to "serial: imx: default to half >> >>> duplex rs485". >> >>> >> >>> We use the i.MX UART in DTE mode and control the RS-485 transceiver >> >>> using the RTS signal in low-active mode. >> >>> >> >>> uart-has-rtscts; >> >>> fsl,dte-mode; >> >>> linux,rs485-enabled-at-boot-time; >> >>> rs485-rts-active-low; >> >> >> >> That means you're not using a GPIO for RTS signaling, right? >> >> >> > >> > I use native RTS capability (which is in DTE mode the CTS signal...) >> > >> >>> Using this setting leads to the RTS signal not getting asserted (the >> >>> oscilloscope only shows a very short fluke before the start bit is >> >>> sent). >> > >> > Just FYI, the fluke looks like a proper assert, but it is really only >> > 50ns wide. >> > >> >> Also tried DCE mode, the same behavior. >> >> Two screenshots showing TX/RTS (CTS_B) in different settings: >> https://imgur.com/a/PbUex >> >> The little fluke disappears when disabling RX before setting CTSC: >> >> --- a/drivers/tty/serial/imx.c >> +++ b/drivers/tty/serial/imx.c >> @@ -657,6 +657,9 @@ static void imx_uart_start_tx(struct uart_port >> *port) >> if (port->rs485.flags & SER_RS485_ENABLED) { >> u32 ucr2; >> >> + if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) >> + imx_uart_stop_rx(port); >> + >> ucr2 = imx_uart_readl(sport, UCR2); >> if (port->rs485.flags & SER_RS485_RTS_ON_SEND) >> imx_uart_rts_active(sport, &ucr2); >> @@ -664,9 +667,6 @@ static void imx_uart_start_tx(struct uart_port >> *port) >> imx_uart_rts_inactive(sport, &ucr2); >> imx_uart_writel(sport, ucr2, UCR2); >> >> - if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) >> - imx_uart_stop_rx(port); >> - >> /* >> * Enable transmitter and shifter empty irq only if DMA >> is off. >> * In the DMA case this is done in the tx-callback. >> >> It seems that if the RX path is disabled, CTS_B is no longer >> controllable. It just stays high. That is not a problem in the high >> active RTS case... However, it breaks low active half-duplex... >> >> It seems that this thread is describing this situation: >> https://community.nxp.com/thread/385047 > > So better use a gpio instead of the hardware-function? I guess so, did not test that though. Or use full duplex mode. That is what we used anyways in the past, even when using a single RS485 bus (half duplex) on the physical layer anyway. > > Adding a respective check in the driver would be nice though. Hm, yes agreed. Where would that check go? In probe? Then I guess it only would warn when using device tree properties...? -- Stefan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 16:12 ` Stefan Agner 0 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 16:12 UTC (permalink / raw) To: linux-arm-kernel On 16.04.2018 15:42, Uwe Kleine-K?nig wrote: > On Mon, Apr 16, 2018 at 03:01:44PM +0200, Stefan Agner wrote: >> On 16.04.2018 12:29, Stefan Agner wrote: >> > On 16.04.2018 11:22, Uwe Kleine-K?nig wrote: >> >> Hi Stefan, >> >> >> >> On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >> >>> Using upstream I noticed that RS-485 does not work in the default >> >>> configuration for our platforms (Toradex Apalis/Colibri). Closer >> >> >> >> This is an i.MX6? >> >> >> > >> > Yes, sorry about that. >> > >> > But I think it is i.MX UART specific, I noticed the same behavior on >> > i.MX 7 too. >> > >> >>> debugging shows that it is related to "serial: imx: default to half >> >>> duplex rs485". >> >>> >> >>> We use the i.MX UART in DTE mode and control the RS-485 transceiver >> >>> using the RTS signal in low-active mode. >> >>> >> >>> uart-has-rtscts; >> >>> fsl,dte-mode; >> >>> linux,rs485-enabled-at-boot-time; >> >>> rs485-rts-active-low; >> >> >> >> That means you're not using a GPIO for RTS signaling, right? >> >> >> > >> > I use native RTS capability (which is in DTE mode the CTS signal...) >> > >> >>> Using this setting leads to the RTS signal not getting asserted (the >> >>> oscilloscope only shows a very short fluke before the start bit is >> >>> sent). >> > >> > Just FYI, the fluke looks like a proper assert, but it is really only >> > 50ns wide. >> > >> >> Also tried DCE mode, the same behavior. >> >> Two screenshots showing TX/RTS (CTS_B) in different settings: >> https://imgur.com/a/PbUex >> >> The little fluke disappears when disabling RX before setting CTSC: >> >> --- a/drivers/tty/serial/imx.c >> +++ b/drivers/tty/serial/imx.c >> @@ -657,6 +657,9 @@ static void imx_uart_start_tx(struct uart_port >> *port) >> if (port->rs485.flags & SER_RS485_ENABLED) { >> u32 ucr2; >> >> + if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) >> + imx_uart_stop_rx(port); >> + >> ucr2 = imx_uart_readl(sport, UCR2); >> if (port->rs485.flags & SER_RS485_RTS_ON_SEND) >> imx_uart_rts_active(sport, &ucr2); >> @@ -664,9 +667,6 @@ static void imx_uart_start_tx(struct uart_port >> *port) >> imx_uart_rts_inactive(sport, &ucr2); >> imx_uart_writel(sport, ucr2, UCR2); >> >> - if (!(port->rs485.flags & SER_RS485_RX_DURING_TX)) >> - imx_uart_stop_rx(port); >> - >> /* >> * Enable transmitter and shifter empty irq only if DMA >> is off. >> * In the DMA case this is done in the tx-callback. >> >> It seems that if the RX path is disabled, CTS_B is no longer >> controllable. It just stays high. That is not a problem in the high >> active RTS case... However, it breaks low active half-duplex... >> >> It seems that this thread is describing this situation: >> https://community.nxp.com/thread/385047 > > So better use a gpio instead of the hardware-function? I guess so, did not test that though. Or use full duplex mode. That is what we used anyways in the past, even when using a single RS485 bus (half duplex) on the physical layer anyway. > > Adding a respective check in the driver would be nice though. Hm, yes agreed. Where would that check go? In probe? Then I guess it only would warn when using device tree properties...? -- Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 16:12 ` Stefan Agner @ 2018-04-16 18:02 ` Uwe Kleine-König -1 siblings, 0 replies; 20+ messages in thread From: Uwe Kleine-König @ 2018-04-16 18:02 UTC (permalink / raw) To: Stefan Agner; +Cc: s.hauer, baruch, linux-arm-kernel, linux-serial Hallo Stefan, On Mon, Apr 16, 2018 at 06:12:41PM +0200, Stefan Agner wrote: > On 16.04.2018 15:42, Uwe Kleine-König wrote: > > Adding a respective check in the driver would be nice though. > > Hm, yes agreed. Where would that check go? In probe? Then I guess it > only would warn when using device tree properties...? look at the code between the calls to uart_get_rs485_mode() and imx_uart_rs485_config(). Something like that would be needed and imx_uart_rs485_config must adapt the flags accordingly. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 18:02 ` Uwe Kleine-König 0 siblings, 0 replies; 20+ messages in thread From: Uwe Kleine-König @ 2018-04-16 18:02 UTC (permalink / raw) To: linux-arm-kernel Hallo Stefan, On Mon, Apr 16, 2018 at 06:12:41PM +0200, Stefan Agner wrote: > On 16.04.2018 15:42, Uwe Kleine-K?nig wrote: > > Adding a respective check in the driver would be nice though. > > Hm, yes agreed. Where would that check go? In probe? Then I guess it > only would warn when using device tree properties...? look at the code between the calls to uart_get_rs485_mode() and imx_uart_rs485_config(). Something like that would be needed and imx_uart_rs485_config must adapt the flags accordingly. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 9:14 ` Stefan Agner @ 2018-04-16 9:54 ` Einar Vading -1 siblings, 0 replies; 20+ messages in thread From: Einar Vading @ 2018-04-16 9:54 UTC (permalink / raw) To: Stefan Agner Cc: linux-arm-kernel, s.hauer, baruch, linux-serial, u.kleine-koenig On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: > Hi, > > Using upstream I noticed that RS-485 does not work in the default > configuration for our platforms (Toradex Apalis/Colibri). Closer > debugging shows that it is related to "serial: imx: default to half > duplex rs485". We where struggling a bit with half duplex rs485 too a while ago. > > We use the i.MX UART in DTE mode and control the RS-485 transceiver > using the RTS signal in low-active mode. > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; > > Using this setting leads to the RTS signal not getting asserted (the > oscilloscope only shows a very short fluke before the start bit is > sent). I think this is what we had too. But if I recall we where supposed to be active-high but I think the behavior is the same either way. > > However, using > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; > rs485-rx-during-tx; > > Asserts the RTS signal low active just fine... We have a (RTS active high) configuration working for us now with only uart-has-rtscts in DT, and then when using the port we do struct serial_rs485 rs485conf; memset(&rs485conf, 0x00, sizeof(struct serial_rs485)); rs485conf.flags |= SER_RS485_ENABLED; rs485conf.flags |= SER_RS485_RTS_ON_SEND; rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); f_debug("Calling ioctl..."); if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) { f_critical("ioctl serial_rs485 failed"); return -1; } Hope it helps. > > Is this a known problem? Any idea where that could come from? It looks > as if the receiver part is actually enabling RTS...? > > Also, isn't enabling RX even in half-duplex mode quite common in order > to detect collisions? > > -- > Stefan // Einar > > -- > To unsubscribe from this list: send the line "unsubscribe linux-serial" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 9:54 ` Einar Vading 0 siblings, 0 replies; 20+ messages in thread From: Einar Vading @ 2018-04-16 9:54 UTC (permalink / raw) To: linux-arm-kernel On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: > Hi, > > Using upstream I noticed that RS-485 does not work in the default > configuration for our platforms (Toradex Apalis/Colibri). Closer > debugging shows that it is related to "serial: imx: default to half > duplex rs485". We where struggling a bit with half duplex rs485 too a while ago. > > We use the i.MX UART in DTE mode and control the RS-485 transceiver > using the RTS signal in low-active mode. > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; > > Using this setting leads to the RTS signal not getting asserted (the > oscilloscope only shows a very short fluke before the start bit is > sent). I think this is what we had too. But if I recall we where supposed to be active-high but I think the behavior is the same either way. > > However, using > > uart-has-rtscts; > fsl,dte-mode; > linux,rs485-enabled-at-boot-time; > rs485-rts-active-low; > rs485-rx-during-tx; > > Asserts the RTS signal low active just fine... We have a (RTS active high) configuration working for us now with only uart-has-rtscts in DT, and then when using the port we do struct serial_rs485 rs485conf; memset(&rs485conf, 0x00, sizeof(struct serial_rs485)); rs485conf.flags |= SER_RS485_ENABLED; rs485conf.flags |= SER_RS485_RTS_ON_SEND; rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); f_debug("Calling ioctl..."); if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) { f_critical("ioctl serial_rs485 failed"); return -1; } Hope it helps. > > Is this a known problem? Any idea where that could come from? It looks > as if the receiver part is actually enabling RTS...? > > Also, isn't enabling RX even in half-duplex mode quite common in order > to detect collisions? > > -- > Stefan // Einar > > -- > To unsubscribe from this list: send the line "unsubscribe linux-serial" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 9:54 ` Einar Vading @ 2018-04-16 9:57 ` Einar Vading -1 siblings, 0 replies; 20+ messages in thread From: Einar Vading @ 2018-04-16 9:57 UTC (permalink / raw) To: Stefan Agner Cc: linux-arm-kernel, s.hauer, baruch, linux-serial, u.kleine-koenig On Mon, Apr 16, 2018 at 11:54:36AM +0200, Einar Vading wrote: > On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: Forgot to mention that we are not using DTE-de mode. We tried to but failed. > > Hi, > > > > Using upstream I noticed that RS-485 does not work in the default > > configuration for our platforms (Toradex Apalis/Colibri). Closer > > debugging shows that it is related to "serial: imx: default to half > > duplex rs485". > > We where struggling a bit with half duplex rs485 too a while ago. > > > > We use the i.MX UART in DTE mode and control the RS-485 transceiver > > using the RTS signal in low-active mode. > > > > uart-has-rtscts; > > fsl,dte-mode; > > linux,rs485-enabled-at-boot-time; > > rs485-rts-active-low; > > > > Using this setting leads to the RTS signal not getting asserted (the > > oscilloscope only shows a very short fluke before the start bit is > > sent). > > I think this is what we had too. But if I recall we where supposed to be > active-high but I think the behavior is the same either way. > > > > However, using > > > > uart-has-rtscts; > > fsl,dte-mode; > > linux,rs485-enabled-at-boot-time; > > rs485-rts-active-low; > > rs485-rx-during-tx; > > > > Asserts the RTS signal low active just fine... > > We have a (RTS active high) configuration working for us now with only > > uart-has-rtscts > > in DT, and then when using the port we do > > struct serial_rs485 rs485conf; > memset(&rs485conf, 0x00, sizeof(struct serial_rs485)); > > rs485conf.flags |= SER_RS485_ENABLED; > rs485conf.flags |= SER_RS485_RTS_ON_SEND; > rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); > > f_debug("Calling ioctl..."); > if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) { > f_critical("ioctl serial_rs485 failed"); > return -1; > } > > Hope it helps. > > > > Is this a known problem? Any idea where that could come from? It looks > > as if the receiver part is actually enabling RTS...? > > > > Also, isn't enabling RX even in half-duplex mode quite common in order > > to detect collisions? > > > > -- > > Stefan > > // Einar // Einar > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-serial" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-serial" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 9:57 ` Einar Vading 0 siblings, 0 replies; 20+ messages in thread From: Einar Vading @ 2018-04-16 9:57 UTC (permalink / raw) To: linux-arm-kernel On Mon, Apr 16, 2018 at 11:54:36AM +0200, Einar Vading wrote: > On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: Forgot to mention that we are not using DTE-de mode. We tried to but failed. > > Hi, > > > > Using upstream I noticed that RS-485 does not work in the default > > configuration for our platforms (Toradex Apalis/Colibri). Closer > > debugging shows that it is related to "serial: imx: default to half > > duplex rs485". > > We where struggling a bit with half duplex rs485 too a while ago. > > > > We use the i.MX UART in DTE mode and control the RS-485 transceiver > > using the RTS signal in low-active mode. > > > > uart-has-rtscts; > > fsl,dte-mode; > > linux,rs485-enabled-at-boot-time; > > rs485-rts-active-low; > > > > Using this setting leads to the RTS signal not getting asserted (the > > oscilloscope only shows a very short fluke before the start bit is > > sent). > > I think this is what we had too. But if I recall we where supposed to be > active-high but I think the behavior is the same either way. > > > > However, using > > > > uart-has-rtscts; > > fsl,dte-mode; > > linux,rs485-enabled-at-boot-time; > > rs485-rts-active-low; > > rs485-rx-during-tx; > > > > Asserts the RTS signal low active just fine... > > We have a (RTS active high) configuration working for us now with only > > uart-has-rtscts > > in DT, and then when using the port we do > > struct serial_rs485 rs485conf; > memset(&rs485conf, 0x00, sizeof(struct serial_rs485)); > > rs485conf.flags |= SER_RS485_ENABLED; > rs485conf.flags |= SER_RS485_RTS_ON_SEND; > rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); > > f_debug("Calling ioctl..."); > if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) { > f_critical("ioctl serial_rs485 failed"); > return -1; > } > > Hope it helps. > > > > Is this a known problem? Any idea where that could come from? It looks > > as if the receiver part is actually enabling RTS...? > > > > Also, isn't enabling RX even in half-duplex mode quite common in order > > to detect collisions? > > > > -- > > Stefan > > // Einar // Einar > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-serial" in > > the body of a message to majordomo at vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-serial" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: serial: imx: half-duplex RS485 operation with RTS active low 2018-04-16 9:54 ` Einar Vading @ 2018-04-16 10:35 ` Stefan Agner -1 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 10:35 UTC (permalink / raw) To: Einar Vading Cc: linux-arm-kernel, s.hauer, baruch, linux-serial, u.kleine-koenig On 16.04.2018 11:54, Einar Vading wrote: > On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >> Hi, >> >> Using upstream I noticed that RS-485 does not work in the default >> configuration for our platforms (Toradex Apalis/Colibri). Closer >> debugging shows that it is related to "serial: imx: default to half >> duplex rs485". > > We where struggling a bit with half duplex rs485 too a while ago. >> >> We use the i.MX UART in DTE mode and control the RS-485 transceiver >> using the RTS signal in low-active mode. >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; >> >> Using this setting leads to the RTS signal not getting asserted (the >> oscilloscope only shows a very short fluke before the start bit is >> sent). > > I think this is what we had too. But if I recall we where supposed to be > active-high but I think the behavior is the same either way. With v4.17-rc1, active high RTS, DTE in half duplex mode seems to work fine (looks good on an oscilloscope). However, active low seems to be broken. >> >> However, using >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; >> rs485-rx-during-tx; >> >> Asserts the RTS signal low active just fine... > > We have a (RTS active high) configuration working for us now with only > > uart-has-rtscts > > in DT, and then when using the port we do > > struct serial_rs485 rs485conf; > memset(&rs485conf, 0x00, sizeof(struct serial_rs485)); > > rs485conf.flags |= SER_RS485_ENABLED; > rs485conf.flags |= SER_RS485_RTS_ON_SEND; > rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); >From what I can tell, in v4.17-rc1 this should be equivalent to just: linux,rs485-enabled-at-boot-time; > > f_debug("Calling ioctl..."); > if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) { > f_critical("ioctl serial_rs485 failed"); > return -1; > } > > Hope it helps. Thanks, I will check using RS485 flags via ioctrl. -- Stefan >> >> Is this a known problem? Any idea where that could come from? It looks >> as if the receiver part is actually enabling RTS...? >> >> Also, isn't enabling RX even in half-duplex mode quite common in order >> to detect collisions? >> >> -- >> Stefan > > // Einar >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-serial" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* serial: imx: half-duplex RS485 operation with RTS active low @ 2018-04-16 10:35 ` Stefan Agner 0 siblings, 0 replies; 20+ messages in thread From: Stefan Agner @ 2018-04-16 10:35 UTC (permalink / raw) To: linux-arm-kernel On 16.04.2018 11:54, Einar Vading wrote: > On Mon, Apr 16, 2018 at 11:14:32AM +0200, Stefan Agner wrote: >> Hi, >> >> Using upstream I noticed that RS-485 does not work in the default >> configuration for our platforms (Toradex Apalis/Colibri). Closer >> debugging shows that it is related to "serial: imx: default to half >> duplex rs485". > > We where struggling a bit with half duplex rs485 too a while ago. >> >> We use the i.MX UART in DTE mode and control the RS-485 transceiver >> using the RTS signal in low-active mode. >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; >> >> Using this setting leads to the RTS signal not getting asserted (the >> oscilloscope only shows a very short fluke before the start bit is >> sent). > > I think this is what we had too. But if I recall we where supposed to be > active-high but I think the behavior is the same either way. With v4.17-rc1, active high RTS, DTE in half duplex mode seems to work fine (looks good on an oscilloscope). However, active low seems to be broken. >> >> However, using >> >> uart-has-rtscts; >> fsl,dte-mode; >> linux,rs485-enabled-at-boot-time; >> rs485-rts-active-low; >> rs485-rx-during-tx; >> >> Asserts the RTS signal low active just fine... > > We have a (RTS active high) configuration working for us now with only > > uart-has-rtscts > > in DT, and then when using the port we do > > struct serial_rs485 rs485conf; > memset(&rs485conf, 0x00, sizeof(struct serial_rs485)); > > rs485conf.flags |= SER_RS485_ENABLED; > rs485conf.flags |= SER_RS485_RTS_ON_SEND; > rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); >From what I can tell, in v4.17-rc1 this should be equivalent to just: linux,rs485-enabled-at-boot-time; > > f_debug("Calling ioctl..."); > if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) { > f_critical("ioctl serial_rs485 failed"); > return -1; > } > > Hope it helps. Thanks, I will check using RS485 flags via ioctrl. -- Stefan >> >> Is this a known problem? Any idea where that could come from? It looks >> as if the receiver part is actually enabling RTS...? >> >> Also, isn't enabling RX even in half-duplex mode quite common in order >> to detect collisions? >> >> -- >> Stefan > > // Einar >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-serial" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-04-16 18:02 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-16 9:14 serial: imx: half-duplex RS485 operation with RTS active low Stefan Agner 2018-04-16 9:14 ` Stefan Agner 2018-04-16 9:22 ` Uwe Kleine-König 2018-04-16 9:22 ` Uwe Kleine-König 2018-04-16 10:29 ` Stefan Agner 2018-04-16 10:29 ` Stefan Agner 2018-04-16 13:01 ` Stefan Agner 2018-04-16 13:01 ` Stefan Agner 2018-04-16 13:42 ` Uwe Kleine-König 2018-04-16 13:42 ` Uwe Kleine-König 2018-04-16 16:12 ` Stefan Agner 2018-04-16 16:12 ` Stefan Agner 2018-04-16 18:02 ` Uwe Kleine-König 2018-04-16 18:02 ` Uwe Kleine-König 2018-04-16 9:54 ` Einar Vading 2018-04-16 9:54 ` Einar Vading 2018-04-16 9:57 ` Einar Vading 2018-04-16 9:57 ` Einar Vading 2018-04-16 10:35 ` Stefan Agner 2018-04-16 10:35 ` Stefan Agner
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.