* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-16 23:01 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-omap, linux-serial, linux-arm-kernel
In-Reply-To: <20180416212653.GC5671@atomide.com>
On Mon, Apr 16, 2018 at 02:26:53PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180416 15:47]:
> > * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > > Hi,
> > >
> > > I'm not entirely sure what's going on, but I see corrupted characters
> > > with the serial console on the OMAP4430 SDP board. During boot,
> > > everything seems fine, the problem appears to be userspace output.
> > >
> > > For example, if I edit a file, then quit vi:
> > >
> > > :q■■%■■B■■Z■root@omap-4430sdp:~#
> >
> > I don't think I've seen that one. What I've seen few times is
> > typing a key on the serial console echoing back the previous
> > character typed while the new character won't get displayed
> > until hitting keyboard again. Only rebooting the device seems
> > to solve this. This is with 4430 ES2.3 revision.
> >
> > I wonder if we're missing some parts of errata i202 handling
> > in omap_8250_mdr1_errataset()?
>
> Trying to see what we might be missing in 8250_omap compared
> to omap-serial, your description sounds like it could be similar
> issue compared to what got fixed for omap-serial earlier with
> commit 0ba5f66836c9 ("tty: serial: OMAP: use a 1-byte RX FIFO
> threshold in PIO mode").
... except this is the transmit side, not the receive side.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Tony Lindgren @ 2018-04-16 21:26 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Greg Kroah-Hartman, linux-omap, linux-serial, linux-arm-kernel
In-Reply-To: <20180416154545.GA5671@atomide.com>
* Tony Lindgren <tony@atomide.com> [180416 15:47]:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > Hi,
> >
> > I'm not entirely sure what's going on, but I see corrupted characters
> > with the serial console on the OMAP4430 SDP board. During boot,
> > everything seems fine, the problem appears to be userspace output.
> >
> > For example, if I edit a file, then quit vi:
> >
> > :q■■%■■B■■Z■root@omap-4430sdp:~#
>
> I don't think I've seen that one. What I've seen few times is
> typing a key on the serial console echoing back the previous
> character typed while the new character won't get displayed
> until hitting keyboard again. Only rebooting the device seems
> to solve this. This is with 4430 ES2.3 revision.
>
> I wonder if we're missing some parts of errata i202 handling
> in omap_8250_mdr1_errataset()?
Trying to see what we might be missing in 8250_omap compared
to omap-serial, your description sounds like it could be similar
issue compared to what got fixed for omap-serial earlier with
commit 0ba5f66836c9 ("tty: serial: OMAP: use a 1-byte RX FIFO
threshold in PIO mode").
> Also, I'm seeing an issue where the UARTs won't idle on init
> with 8250_omap driver if connected to the wl12xx bluetooth port
> unless I write some data to the port first. It does not seem
> to be related to the rts/cts lines being wired as I've tested
> muxing them out of the way.
I'll try to debug this one a bit.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <15ca978834ac705c550d9d3339ae1602@agner.ch>
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
* Re: 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-16 17:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-omap, linux-serial, linux-arm-kernel
In-Reply-To: <20180416155259.GB5671@atomide.com>
On Mon, Apr 16, 2018 at 08:52:59AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > Since this uses a USB adapter (built onto the board) it could be
> > that there could be a bug in the driver for that rather than the
> > OMAP4430 SDP, but I've no way to check that hypothesis.
>
> Does it go away when you do a warm reboot of the sdp? Then
> it should not be related to the USB iff the ftdi chip is bus
> powered by VBUS.
Yes, the FTDI chip is bus powered.
I booted, ran vi, quit vi, saw corruption, typed reboot, waited for
it to reboot, ran vi, quit vi, and still saw corruption. So the
reboot seems to have had no effect.
I don't see it with other USB serial consoles on other machines...
I have two of these using the same FTDI chipset:
Bus 001 Device 021: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 020: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Device 20 is the SDP board, and device 21 is a ZII board. Both use
port 2 on the quad ftdi device. The serial console on the ZII board
is fine, so that seems to rule out the FTDI driver / FTDI hardware.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <20180416134249.vdjyye73elv2p5qr@pengutronix.de>
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
* Re: 4.16 OMAP serial transmit corruption?
From: Tony Lindgren @ 2018-04-16 15:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Greg Kroah-Hartman, linux-omap, linux-serial, linux-arm-kernel
In-Reply-To: <20180416151732.GU16141@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> Since this uses a USB adapter (built onto the board) it could be
> that there could be a bug in the driver for that rather than the
> OMAP4430 SDP, but I've no way to check that hypothesis.
Does it go away when you do a warm reboot of the sdp? Then
it should not be related to the USB iff the ftdi chip is bus
powered by VBUS.
Regards,
Tony
^ permalink raw reply
* Re: 4.16 OMAP serial transmit corruption?
From: Tony Lindgren @ 2018-04-16 15:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Greg Kroah-Hartman, linux-omap, linux-serial, linux-arm-kernel
In-Reply-To: <20180416151732.GU16141@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> Hi,
>
> I'm not entirely sure what's going on, but I see corrupted characters
> with the serial console on the OMAP4430 SDP board. During boot,
> everything seems fine, the problem appears to be userspace output.
>
> For example, if I edit a file, then quit vi:
>
> :q■■%■■B■■Z■root@omap-4430sdp:~#
I don't think I've seen that one. What I've seen few times is
typing a key on the serial console echoing back the previous
character typed while the new character won't get displayed
until hitting keyboard again. Only rebooting the device seems
to solve this. This is with 4430 ES2.3 revision.
I wonder if we're missing some parts of errata i202 handling
in omap_8250_mdr1_errataset()?
Also, I'm seeing an issue where the UARTs won't idle on init
with 8250_omap driver if connected to the wl12xx bluetooth port
unless I write some data to the port first. It does not seem
to be related to the rts/cts lines being wired as I've tested
muxing them out of the way.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] serial: imx: fix cached UCR2 read on software reset
From: Stefan Agner @ 2018-04-16 15:35 UTC (permalink / raw)
To: gregkh, u.kleine-koenig; +Cc: jslaby, linux-serial, linux-kernel, Stefan Agner
To reset the UART the SRST needs be cleared (low active). According
to the documentation the bit will remain active for 4 module clocks
until it is cleared (set to 1).
Hence the real register need to be read in case the cached register
indcates that the SRST bit is zero.
This bug lead to wrong baudrate because the baud rate register got
restored before reset completed in imx_flush_buffer.
Fixes: 3a0ab62f43de ("serial: imx: implement shadow registers for UCRx and UFCR")
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 91f3a1a5cb7f..4ff6bd6eb9ab 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -316,7 +316,7 @@ static u32 imx_uart_readl(struct imx_port *sport, u32 offset)
* differ from the value that was last written. As it only
* clears after being set, reread conditionally.
*/
- if (sport->ucr2 & UCR2_SRST)
+ if (!(sport->ucr2 & UCR2_SRST))
sport->ucr2 = readl(sport->port.membase + offset);
return sport->ucr2;
break;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF
From: Rob Herring @ 2018-04-16 15:22 UTC (permalink / raw)
To: Jacopo Mondi
Cc: gregkh, mark.rutland, linux-serial, devicetree, linux-renesas-soc,
linux-kernel
In-Reply-To: <1523886928-14535-1-git-send-email-jacopo+renesas@jmondi.org>
On Mon, Apr 16, 2018 at 03:55:28PM +0200, Jacopo Mondi wrote:
> Add documentation for r8a77965 compatible string to Renesas sci-serial
> device tree bindings documentation.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>
> Renesas R-Car M3-N support has been merged for v4.17.
> Document the missing device tree bindings.
>
> ---
> Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
> 1 file changed, 2 insertions(+)
Applied.
Rob
^ permalink raw reply
* 4.16 OMAP serial transmit corruption?
From: Russell King - ARM Linux @ 2018-04-16 15:17 UTC (permalink / raw)
To: Tony Lindgren, Greg Kroah-Hartman
Cc: linux-omap, linux-serial, linux-arm-kernel
Hi,
I'm not entirely sure what's going on, but I see corrupted characters
with the serial console on the OMAP4430 SDP board. During boot,
everything seems fine, the problem appears to be userspace output.
For example, if I edit a file, then quit vi:
:q■■%■■B■■Z■root@omap-4430sdp:~#
The hexdump of that is:
00000000 1b 5b 32 35 3b 31 48 1b 5b 30 4b 3a 71 1b db db |.[25;1H.[0K:q...|
^^^^^
00000010 da 25 aa da 8a 42 b5 b4 05 5a fd 72 6f 6f 74 40 |.%...B...Z.root@|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000020 6f 6d 61 70 2d 34 34 33 30 73 64 70 3a 7e 23 20 |omap-4430sdp:~# |
This appears to come from these write calls in vi:
write(1, "\33[25;1H\33[0K:"..., 12) = 12
write(1, "q"..., 1) = 1
write(1, "\33[1;1H\r\33[25;1H- kexec-test 1/9 11%\33[0K\33[1;1H"..., 44) = 44
write(1, "\33[25;1H\33[0K"..., 11) = 11
It appears to be timing related, as stracing vi produces different output:
- k9■root@omap-4430sdp:~#
00000000 1b 5b 32 35 3b 31 48 1b 5b 30 4b 3a 71 1b 5b 31 |.[25;1H.[0K:q.[1|
00000010 3b 31 48 0d 1b 5b 32 35 3b 31 48 2d 20 6b 39 ff |;1H..[25;1H- k9.|
^^^^^
00000020 72 6f 6f 74 40 6f 6d 61 70 2d 34 34 33 30 73 64 |root@omap-4430sd|
00000030 70 3a 7e 23 20 |p:~# |
Similar, but more severe effects can be seen with "dmesg | less":
00000000 0d 72 6f 6f 74 40 6f 6d 61 70 2d 34 34 33 30 73 |.root@omap-4430s|
00000010 64 70 3a 7e 23 20 64 6d 65 73 67 20 7c 20 6c 65 |dp:~# dmesg | le|
00000020 73 73 1b 5b 4a 0d 0a 1b 5b 30 3b 30 48 1b 5b 4b |ss.[J...[0;0H.[K|
00000030 0d 0a 1b 5b 4b 7e cd d4 a4 68 b4 b5 ca 35 52 da |...[K~...h...5R.|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000040 b4 b5 ca 35 52 da b4 b5 ca 35 52 da b4 b5 ca 35 |...5R....5R....5|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000050 52 da b4 b5 ca 35 52 da b4 b5 ca 35 52 da b4 b5 |R....5R....5R...|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000060 ca 35 52 da b4 b5 ca 35 52 da b4 b5 ca 35 52 da |.5R....5R....5R.|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000070 b4 b5 ca 35 52 da b4 b5 ca 35 52 da b4 b5 ca 35 |...5R....5R....5|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000080 52 da b4 b5 ca 35 52 da b4 b5 ca 35 52 da b4 b5 |R....5R....5R...|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000090 ca 35 52 da b4 25 aa da 82 42 b5 b4 b5 6a b4 75 |.5R..%...B...j.u|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000a0 6a cd d1 85 b9 91 85 c9 91 81 4a b9 c1 d5 d1 6d |j.........J....m|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000b0 da c1 6a 6d da c1 da 82 42 b5 b4 b5 4a ea eb 8b |..jm....B...J...|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000c0 57 cb eb 16 12 2a cb ab 17 81 7a b9 81 82 a1 e5 |W....*....z.....|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000d0 cd a5 8d 85 b1 81 1a 41 55 81 82 c2 c1 6a 52 b4 |.......AU....jR.|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000e0 b4 b5 8a 2a cb ab 17 81 b2 95 c9 cd a5 bd b9 81 |...*............|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000f0 a2 72 8a b2 72 82 5a 02 42 92 b5 ad 01 c9 b5 ad |.r..r.Z.B.......|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000100 b5 82 0d b9 0a c9 b5 b1 a5 b9 d5 e1 b9 7a c9 9d |.............z..|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000110 b9 aa ad a5 02 42 3a 8d 8d 81 b2 95 c9 cd a5 bd |.....B:.........|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000120 b9 81 a2 72 ba 72 a2 02 42 3a 35 35 2a 29 09 d2 |...r.r..B:55*)..|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000130 52 53 48 68 b4 b5 0a b2 02 9a d5 05 05 a9 ea cb |RSHh............|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000140 0b 52 14 2e 2e 48 4c 9b 90 31 33 3a 33 30 3a 30 |.R...HL..13:30:0|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000150 39 20 42 53 54 20 32 30 31 38 0d 0a 1b 5b 4b 43 |9 BST 2018...[KC|
00000160 50 55 3a 20 41 52 4d 76 37 20 50 72 6f 63 65 73 |PU: ARMv7 Proces|
Since this uses a USB adapter (built onto the board) it could be
that there could be a bug in the driver for that rather than the
OMAP4430 SDP, but I've no way to check that hypothesis.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-16 14:47 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180416084439.GA5489@amd>
* Pavel Machek <pavel@ucw.cz> [180416 08:46]:
> Ahha, so first I missed two of the patches, and second, I was not
> patient enough. I was stopping my test after first or second
> error. Now I get... so I guess it works for me.
OK good to hear.
> For the series:
>
> Tested-by: Pavel Machek <pavel@ucw.cz>
Thanks for testing.
> Testing ngsm..
> 1> U0000AT+CFUN?
> 1<
Hmm droid4-ngsm should show the response or error out as you
already probably figured out :)
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF
From: Geert Uytterhoeven @ 2018-04-16 14:29 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Greg KH, Rob Herring, Mark Rutland, linux-serial,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas, Linux Kernel Mailing List
In-Reply-To: <1523886928-14535-1-git-send-email-jacopo+renesas@jmondi.org>
On Mon, Apr 16, 2018 at 3:55 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Add documentation for r8a77965 compatible string to Renesas sci-serial
> device tree bindings documentation.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
My
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
on v2 of the full r8a77965 series is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF
From: Jacopo Mondi @ 2018-04-16 13:55 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland
Cc: Jacopo Mondi, linux-serial, devicetree, linux-renesas-soc,
linux-kernel
Add documentation for r8a77965 compatible string to Renesas sci-serial
device tree bindings documentation.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
Renesas R-Car M3-N support has been merged for v4.17.
Document the missing device tree bindings.
---
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index ad962f4..0cc5417 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -41,6 +41,8 @@ Required properties:
- "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART.
- "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART.
- "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART.
+ - "renesas,scif-r8a77965" for R8A77965 (R-Car M3-N) SCIF compatible UART.
+ - "renesas,hscif-r8a77965" for R8A77965 (R-Car M3-N) HSCIF compatible UART.
- "renesas,scif-r8a77970" for R8A77970 (R-Car V3M) SCIF compatible UART.
- "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART.
- "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART.
--
2.7.4
^ permalink raw reply related
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <94f7fcf8873f7607087fc3a59a9422a8@agner.ch>
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
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <c6059022d48191909d030584f981d1a2@agner.ch>
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
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <20180416095436.7mxh4cqdvlyleryr@lnxeinarv.se.axis.com>
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
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <20180416092257.frbmooduhm4zrhhl@pengutronix.de>
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
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <20180416095436.7mxh4cqdvlyleryr@lnxeinarv.se.axis.com>
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
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <0e88706a05a302201be396d2f03c3e9e@agner.ch>
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
* Re: serial: imx: half-duplex RS485 operation with RTS active low
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
In-Reply-To: <0e88706a05a302201be396d2f03c3e9e@agner.ch>
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
* serial: imx: half-duplex RS485 operation with RTS active low
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
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Pavel Machek @ 2018-04-16 8:44 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180413002415.GC5700@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]
> Do you have phy-mapphone-mdm6600 loaded? That is still needed to
> configure all the boot mode pins for the modem so it is usable..
> The UART will then work also without ohci-platform, just the
> USB PHY is disabled without ohci-platform.
>
> I have these in my .config:
> CONFIG_SERIAL_8250_OMAP=y
> CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
> CONFIG_PHY_MAPPHONE_MDM6600=m
> CONFIG_N_GSM=m
>
> And then the two patches from $subject thread. I just tried
> it with today's mainline kernel and it's still working for
> me.
>
> Maybe you're missing some related patch though if usingv4.16?
>
> 984c7706ff18 ("ARM: dts: omap4-droid4: Configure uart1 pins")
> e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
> fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
> bca809d8183c ("ARM: omap2plus_defconfig: Enable MDM6600 USB PHY")
> 077e1cde78c3 ("ARM: omap2plus_defconfig: Enable 8250_OMAP"
>
> So maybe you're still using CONFIG_SERIAL_OMAP=y instead of
> CONFIG_SERIAL_8250_OMAP=y?
Ahha, so first I missed two of the patches, and second, I was not
patient enough. I was stopping my test after first or second
error. Now I get... so I guess it works for me.
Thanks!
For the series:
Tested-by: Pavel Machek <pavel@ucw.cz>
Pavel
user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
Testing ngsm..
1> U0000AT+CFUN?
1<
Enable speaker phone..
2> U0001AT+EACC=3,0
2<
2> U0002AT+CMUT=0
2<
2> U0003AT+NREC=1
2<
2> U0004AT+CLVL=6
2<
Started ngsm, press Ctrl-C to exit when done
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-13 0:24 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180412212412.GA29243@amd>
* Pavel Machek <pavel@ucw.cz> [180412 21:25]:
> sudo insmod /tmp/n_gsm.ko debug=0xff
>
> user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
> Starting ngsm..
> Testing ngsm..
> Could not open /dev/gsmtty1: Level 2 halted
> Trying to start ngsm again: Level 2 halted
> Starting ngsm..
> Testing ngsm..
> Could not open /dev/gsmtty1: Level 2 halted
> Trying to start ngsm again: Level 2 halted
> Starting ngsm..
> ^CCould not set conf: Interrupted system call
> Could not start ngsm: Interrupted system call
>
> [ 3378.381134] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
> [ 3408.460937] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
> [ 3413.633239] Q> 0) R: UIH(F)
> [ 3413.639190] C3
> [ 3413.642761] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
> ~....~
> [ 3413.653564] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
OK so no response from the modem. After few of the above
packets, you should then also see something coming back:
gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
gsmld_output: 00000000: 7e 01 ef c3 aa 7e
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
DLCI 0 opening in ADM mode.
Do you have phy-mapphone-mdm6600 loaded? That is still needed to
configure all the boot mode pins for the modem so it is usable..
The UART will then work also without ohci-platform, just the
USB PHY is disabled without ohci-platform.
I have these in my .config:
CONFIG_SERIAL_8250_OMAP=y
CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
CONFIG_PHY_MAPPHONE_MDM6600=m
CONFIG_N_GSM=m
And then the two patches from $subject thread. I just tried
it with today's mainline kernel and it's still working for
me.
Maybe you're missing some related patch though if usingv4.16?
984c7706ff18 ("ARM: dts: omap4-droid4: Configure uart1 pins")
e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
bca809d8183c ("ARM: omap2plus_defconfig: Enable MDM6600 USB PHY")
077e1cde78c3 ("ARM: omap2plus_defconfig: Enable 8250_OMAP"
So maybe you're still using CONFIG_SERIAL_OMAP=y instead of
CONFIG_SERIAL_8250_OMAP=y?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Pavel Machek @ 2018-04-12 21:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180409134259.GO5700@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3735 bytes --]
On Mon 2018-04-09 06:42:59, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180409 10:56]:
> > Ok, I should have all that enabled. But droid4-ngsm still fails:
> >
> > user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
> > Starting ngsm..
> > Testing ngsm..
> > Could not open /dev/gsmtty1: Level 2 halted
> > Trying to start ngsm again: Level 2 halted
> > Starting ngsm..
>
> I guess you must have phy-mapphone-mdm6600 enabled as you a have
> working modem over USB. What do you see in dmesg if you enable n_gsm
> debug with modprobe n_gsm debug=0xff or on kernel cmdline?
Ok, let me try... Got some debugging output, hopefully you can see
what is going on there?
Thanks,
Pavel
sudo insmod /tmp/n_gsm.ko debug=0xff
user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
^CCould not set conf: Interrupted system call
Could not start ngsm: Interrupted system call
[ 3378.381134] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[ 3408.460937] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[ 3413.633239] Q> 0) R: UIH(F)
[ 3413.639190] C3
[ 3413.642761] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3413.653564] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3413.978942] Q> 0) R: UIH(F)
[ 3413.984924] C3
[ 3413.988586] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3413.999114] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3414.328247] Q> 0) R: UIH(F)
[ 3414.333068] C3
[ 3414.336608] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3414.346984] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3414.679870] gsmld_output: 00000000: f9 03 3f 01 1c f9
..?...
[ 3414.690979] --> 0) C: SABM(P)
[ 3414.798370] gsmld_output: 00000000: f9 03 3f 01 1c f9
..?...
[ 3414.809570] --> 0) C: SABM(P)
[ 3414.918243] gsmld_output: 00000000: f9 03 3f 01 1c f9
..?...
[ 3414.928588] --> 0) C: SABM(P)
[ 3416.743682] Q> 0) R: UIH(F)
[ 3416.748352] C3
[ 3416.751800] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3416.762145] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3417.088256] Q> 0) R: UIH(F)
[ 3417.093078] C3
[ 3417.096679] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3417.107208] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3417.438201] Q> 0) R: UIH(F)
[ 3417.443206] C3
[ 3417.446990] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3417.457733] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3417.788330] gsmld_output: 00000000: f9 03 3f 01 1c f9
..?...
[ 3417.799163] --> 0) C: SABM(P)
[ 3417.918243] gsmld_output: 00000000: f9 03 3f 01 1c f9
..?...
[ 3417.929107] --> 0) C: SABM(P)
[ 3418.038208] gsmld_output: 00000000: f9 03 3f 01 1c f9
..?...
[ 3418.049102] --> 0) C: SABM(P)
[ 3419.854248] Q> 0) R: UIH(F)
[ 3419.859527] C3
[ 3419.863555] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3419.874481] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3420.208221] Q> 0) R: UIH(F)
[ 3420.213500] C3
[ 3420.217498] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3420.228393] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3420.598205] Q> 0) R: UIH(F)
[ 3420.603515] C3
[ 3420.607513] gsm_data_kick: 00000000: 7e 01 ef c3 aa 7e
~....~
[ 3420.618377] gsmld_output: 00000000: 7e 01 ef c3 aa 7e
~....~
user@devuan:/my/droid4-ngsm$
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: John Garry @ 2018-04-12 16:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan, linux-serial,
linux-kernel, linuxarm
In-Reply-To: <98039a90-cbf2-6d76-bdb5-56c8e83f6470@huawei.com>
On 26/02/2018 15:07, John Garry wrote:
> On 26/02/2018 15:02, Andy Shevchenko wrote:
>> On Mon, 2018-02-26 at 13:15 +0000, John Garry wrote:
>>> On 26/02/2018 12:27, Andy Shevchenko wrote:
>>>> On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:
>>>>> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
>>>>
>>>>
>>>>>> Device (LPC0.CON0) {
>>>>>> Name (_HID, "HISI1031")
>>>>>> // Name (_CID, "PNP0501") // cannot support PNP
>>>>
>>>>
>>>> One more question. What is the problem with this CID? Do you have a
>>>> race
>>>> condition in enumeration?
>>>>
>>>
>>> Hi Andy,
>>>
>>> Not sure if race condition exactly. I tried enabling this CID and a
>>> pnp
>>> device is created in pnpacpi_add_device_handler(), while we have
>>> already
>>> marked the corresponding acpi_device to skip enumeration in ACPI scan
>>> handler (by flagging it as a serial bus slave).
>>
>> Is that code already in upstream?
>
> No, not yet.
>
>>
>> If no, please, Cc next version to me and possible Mika.
>
> Of course. I should be sending it later today.
>
Hi Andy,
A while ago we discussed on this thread the possibility of adding
generic 8250 IO space platform driver support for ACPI FW.
In this discussion I mentioned that we require specifically platform
device support, and not PNP device support, as this is how we enumerate
the devices in the host controller driver. I think you're familiar with
this driver - here is the thread posting for reference:
https://lkml.org/lkml/2018/3/6/230
I would say that there were 2 main takeaway points:
a. for 8250-compatible UART, we should use a PNP driver for ACPI FW
b. you prefered us to change the host driver to use an ACPI handler approach
For b., I was not keen as we already did try the handler in the ACPI
core code, but this was not so welcome. Reasoning here:
https://lkml.org/lkml/2018/2/14/532
I did also say that I would prefer not to change approach after a very
long upstream effort, with no clear end in sight.
However do you have an idea on creating a PNP device in a.? That is,
enumerate (create) a 8250 PNP device.
If you look at the least driver here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bus/hisi_lpc.c
We could have this working with a change in the ACPI probe code, like in
this code snippet:
list_for_each_entry(child, &adev->children, node) {
struct resource_entry *rentry;
LIST_HEAD(resource_list);
int rc;
if (!acpi_is_pnp_device(child))
continue;
acpi_dev_get_resources(child, &resource_list, NULL, NULL);
list_for_each_entry(rentry, &resource_list, node) {
struct resource *res = rentry->res;
if (res->flags | IORESOURCE_IO)
hisi_lpc_acpi_xlat_io_res(child, adev, res); /* bad */
}
rc = pnpacpi_add_device(child);
if (rc)
return rc;
}
Obviously this is not sound as we should not modify the child
acpi_device resources.
Alternatively, as another approach, I could copy the relevant code
pnpacpi_add_device() verbatim into this above code, and xlat the
resource of the PNP device, but it's not good to copy the code like.
Any other ideas?
All the best,
John
>>
> All the best,
> John
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox