All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
@ 2017-05-23 12:17 Steve Twiss
  2017-05-23 14:09 ` Uwe Kleine-König
  2017-05-23 16:26 ` Fabio Estevam
  0 siblings, 2 replies; 15+ messages in thread
From: Steve Twiss @ 2017-05-23 12:17 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig
  Cc: Support Opensource

From: Steve Twiss <stwiss.opensource@diasemi.com>

Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
ensure DCD and RI irqs to be off")

The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
be off, causes a serial console display problem the i.MX6Q SABRESD board.
The console becomes unreadable and unwritable.

Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>

---
This patch applies against linux-next and v4.12-rc2

Hi,

I have been seeing a problem with the serial output console on the i.MX6Q
SABRESD, but not the i.MX6DL SABRESD. Everything was fine up to
linux-mainline/v4.11 but changed after linux-next/next-20170501.

Some bisection has pointed at the commit
e61c38d85b7392e033ee03bca46f1d6006156175 which, once removed from my
linux-next/v4.12-rc2 build allows the i.MX6Q board to display the console
correctly again.

This patch removes the original commit e61c38d85b7392e ("serial: imx:
setup DCEDTE early and ensure DCD and RI irqs to be off") from  linux-next
v4.12-rc2 and fixes the serial problem seen in the i.MX6Q SABRESD board.

Regards,
Steve Twiss, Dialog Semiconductor Ltd.


 drivers/tty/serial/imx.c | 36 +++++++++++++-----------------------
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 33509b4..b4340b5 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1325,10 +1325,19 @@ static int imx_startup(struct uart_port *port)
 	if (!is_imx1_uart(sport)) {
 		temp = readl(sport->port.membase + UCR3);
 
-		temp |= UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
+		/*
+		 * The effect of RI and DCD differs depending on the UFCR_DCEDTE
+		 * bit. In DCE mode they control the outputs, in DTE mode they
+		 * enable the respective irqs. At least the DCD irq cannot be
+		 * cleared on i.MX25 at least, so it's not usable and must be
+		 * disabled. I don't have test hardware to check if RI has the
+		 * same problem but I consider this likely so it's disabled for
+		 * now, too.
+		 */
+		temp |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP |
+			UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
 
 		if (sport->dte_mode)
-			/* disable broken interrupts */
 			temp &= ~(UCR3_RI | UCR3_DCD);
 
 		writel(temp, sport->port.membase + UCR3);
@@ -1610,6 +1619,8 @@ static void imx_flush_buffer(struct uart_port *port)
 
 	ufcr = readl(sport->port.membase + UFCR);
 	ufcr = (ufcr & (~UFCR_RFDIV)) | UFCR_RFDIV_REG(div);
+	if (sport->dte_mode)
+		ufcr |= UFCR_DCEDTE;
 	writel(ufcr, sport->port.membase + UFCR);
 
 	writel(num, sport->port.membase + UBIR);
@@ -2177,27 +2188,6 @@ static int serial_imx_probe(struct platform_device *pdev)
 		 UCR1_TXMPTYEN | UCR1_RTSDEN);
 	writel_relaxed(reg, sport->port.membase + UCR1);
 
-	if (!is_imx1_uart(sport) && sport->dte_mode) {
-		/*
-		 * The DCEDTE bit changes the direction of DSR, DCD, DTR and RI
-		 * and influences if UCR3_RI and UCR3_DCD changes the level of RI
-		 * and DCD (when they are outputs) or enables the respective
-		 * irqs. So set this bit early, i.e. before requesting irqs.
-		 */
-		writel(UFCR_DCEDTE, sport->port.membase + UFCR);
-
-		/*
-		 * Disable UCR3_RI and UCR3_DCD irqs. They are also not
-		 * enabled later because they cannot be cleared
-		 * (confirmed on i.MX25) which makes them unusable.
-		 */
-		writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
-		       sport->port.membase + UCR3);
-
-	} else {
-		writel(0, sport->port.membase + UFCR);
-	}
-
 	clk_disable_unprepare(sport->clk_ipg);
 
 	/*
-- 
end-of-patch for PATCH V1

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 12:17 [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off Steve Twiss
@ 2017-05-23 14:09 ` Uwe Kleine-König
  2017-05-23 14:28   ` Steve Twiss
  2017-05-23 16:26 ` Fabio Estevam
  1 sibling, 1 reply; 15+ messages in thread
From: Uwe Kleine-König @ 2017-05-23 14:09 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
> 
> Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> ensure DCD and RI irqs to be off")
> 
> The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> be off, causes a serial console display problem the i.MX6Q SABRESD board.
> The console becomes unreadable and unwritable.
> 
> Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>

You're not the first to report this issue but you still have the chance
to be the first to test a suggested patch for it.

See

	http://marc.info/?l=linux-serial&m=149434029912947&w=2

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 14:09 ` Uwe Kleine-König
@ 2017-05-23 14:28   ` Steve Twiss
  2017-05-23 14:37     ` Uwe Kleine-König
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Twiss @ 2017-05-23 14:28 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

Hi Uwe,

Thanks for your quick response.

On 23 May 2017 15:10, Uwe Kleine-König wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> >
> > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > ensure DCD and RI irqs to be off")
> >
> > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > The console becomes unreadable and unwritable.
> >
> > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> 
> You're not the first to report this issue but you still have the chance
> to be the first to test a suggested patch for it.

I've just applied your patch against a clean linux-next/v4.12-rc2
I added your patch ...

> 	http://marc.info/?l=linux-serial&m=149434029912947&w=2

(this one?)

diff --git a/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c b/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
index 33509b4..2182548 100644
--- a/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
+++ b/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
@@ -2193,9 +2193,14 @@ static int serial_imx_probe(struct platform_device *pdev)
                 */
                writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
                       sport->port.membase + UCR3);
-
        } else {
+               unsigned long ucr3 = UCR3_DSR;
+
+               if (!is_imx1_uart(sport))
+                       ucr3 |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP;
+
                writel(0, sport->port.membase + UFCR);
+               writel(ucr3, sport->port.membase + UCR3);
        }
 
        clk_disable_unprepare(sport->clk_ipg);

I've added that to my working directory, but I am still seeing the corrupted
console output on the i.MX6 Q (quad) board.

Best regards
Steve

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 14:28   ` Steve Twiss
@ 2017-05-23 14:37     ` Uwe Kleine-König
  2017-05-23 15:01       ` Steve Twiss
  0 siblings, 1 reply; 15+ messages in thread
From: Uwe Kleine-König @ 2017-05-23 14:37 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

Hallo Steve,

On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > >
> > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > ensure DCD and RI irqs to be off")
> > >
> > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > > The console becomes unreadable and unwritable.
> > >
> > > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > 
> > You're not the first to report this issue but you still have the chance
> > to be the first to test a suggested patch for it.
> 
> I've just applied your patch against a clean linux-next/v4.12-rc2
> I added your patch ...
> 
> > 	http://marc.info/?l=linux-serial&m=149434029912947&w=2
> 
> (this one?)
> 
> diff --git a/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c b/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
> index 33509b4..2182548 100644
> --- a/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
> +++ b/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
> @@ -2193,9 +2193,14 @@ static int serial_imx_probe(struct platform_device *pdev)
>                  */
>                 writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
>                        sport->port.membase + UCR3);
> -
>         } else {
> +               unsigned long ucr3 = UCR3_DSR;
> +
> +               if (!is_imx1_uart(sport))
> +                       ucr3 |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP;
> +
>                 writel(0, sport->port.membase + UFCR);
> +               writel(ucr3, sport->port.membase + UCR3);
>         }
>  
>         clk_disable_unprepare(sport->clk_ipg);
> 
Yeah, that's the patch I meant.

> I've added that to my working directory, but I am still seeing the corrupted
> console output on the i.MX6 Q (quad) board.

I don't have a failing board (I think). So here are a few questions
about yours:

 - how does the dts snippet for your failing device look like?
 - This is not the device the console runs on, right?
 - Can you initialize the device in the bootloader and check if it is
   working there?
 - Does it make a difference in Linux if the bootloader used the device
   before?
 - Can you dump the register space of the uart with v4.12-rc2 and
   v4.12-rc2 + revert of e61c38d85b7392e?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 14:37     ` Uwe Kleine-König
@ 2017-05-23 15:01       ` Steve Twiss
  2017-05-23 16:08         ` Uwe Kleine-König
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Twiss @ 2017-05-23 15:01 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

Hi Uwe,

On 23 May 2017 15:37, Uwe Kleine-König wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> > On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > >
> > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > > ensure DCD and RI irqs to be off")
> > > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > > > The console becomes unreadable and unwritable.
> > > >
> > > > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > >
> > > You're not the first to report this issue but you still have the chance
> > > to be the first to test a suggested patch for it.
> >
> > I've just applied your patch against a clean linux-next/v4.12-rc2
> > I added your patch ...
> >
> > > 	http://marc.info/?l=linux-serial&m=149434029912947&w=2
> >
[...]
> > I've added that to my working directory, but I am still seeing the corrupted
> > console output on the i.MX6 Q (quad) board.
> 
> I don't have a failing board (I think). So here are a few questions
> about yours:
> 
>  - how does the dts snippet for your failing device look like?

I am using the standard DTS from the v4.12-rc2 kernel, no changes.
I did an earlier test yesterday using the DTS from v4.11 to see if it was the new
imx7 changes that have recently gone into the kernel but I still see the same
effect.

>  - This is not the device the console runs on, right?

I am connected through the USB to UART, U22 on the i.MX6Q board.
Terminal set to 115200 baud, no parity, 8bit data.

>  - Can you initialize the device in the bootloader and check if it is working there?

I can get U-boot ok for all cases.
Once I TFTP the kernel across, I am okay until I get to "Starting kernel ...",
then, the UART is "working" in the sense that I get the some characters in the style
of the kernel starting up, but they are all garbled.

I expect the kernel has started ok, but I am unable to read/write through the UART
console because of corruptions.

Console log:
--- 8< ---
U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature:   46 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 198000000Hz
usdhc2 clock  : 198000000Hz
usdhc3 clock  : 198000000Hz
usdhc4 clock  : 198000000Hz
nfc clock     : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [WDOG ]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot:  0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x12000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 5951108 (5ace84 hex)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5951044 Bytes =  5.7 MB
   Load Address: 10800000
   Entry Point:  10800000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

à\x1cü\x1cü\x1cpþ\x1càüþü\x1cà\x1càà\x1càüþü\x1c\x1c\x1c\x1càüü\x1cþü\x1cà\x1cü\x1cà\x1cà\x1càüŽ\x1c\x1càü\x1càü\x1c\x1c\x1c\x1c\x1càà\x1cà\x1cà\x1c€à\x1càüþü\x1c\x1c\x1c\x1cààü\x1c\x1cüÿ
à\x1càüŽü\x1cþü\x1càüàð\x1c\x1cààðàà\x1c\x1cà\x1c\x1c\x1cþ\x1c\x1c\x1c~pà\x1cœà\x1c`þ\x1cü\x1càüŽà\x1cà\x1c\x1cà\x1cü\x1cà\x1c\x1cþ\x1cüþ\x1c\x1c\x1c\x1cà\x1cü\x1c\x1cà\x1cŽàà\x1c\x1cà\x1c\x1c\x1c
ààü\x1c\x1cüÿ\x1cà\x1càüŽü\x1cþü\x1càüàð\x1c\x1c€àà\x1c\x1cààààðàà\x1cðàüààüðààðààà\x1c\x1c\x1c\x1cþ\x1c\x1cüÿ\x1c\x1cüðü\x1c\x1cüŽ\x1cà\x1c\x1cüŽà\x1cà\x1c\x1cà\x1cüü
\x1c\x1c\x1c\x1cþ\x1c\x1c\x1cüÿ\x1cà\x1càü\x1cü\x1cpð\x1c\x1cüÀ\x1c\x1cüþü\x1c\x1cü\x1càà\x1càüpÿ\x1c\x1cüààðàà\x1cðàüàð\x1c\x1cà\x1cüàŽ\x1c\x1c~8à\x1cŽàà\x1cŽààü€ààðààüp
Ž\x1cà\x1c\x1cà\x1c\x1c\x1c\x1c\x1cüà\x1cà\x1c\x1cà\x1cààðàüðàà\x1cðà\x1cüàpþàüðàüðààþà\x1cðà\x1cüààà\x1cà\x1c\x1c\x1cààðàà\x1cðàüüàŽà\x1c€ü\x1c\x1c\x1c\x1c\x1c\x1càà\x1c
\x1c\x1cŽ\x1cüà~ÿ\x1cüàà\x1càà\x1cü\x1c\x1c\x1cüŽà\x1cà\x1cü\x1cþ\x1càü~Žüàðààðààà\x1c\x1cà\x1cþà\x1c€\x1cü\x1cààð\x1c\x1cü~ÿ\x1càüŽà\x1càüŽü\x1cþü\x1cà\x1cðààà\x1c
\x1c\x1cŽ\x1cüà~ÿ\x1cüàŽà\x1c\x1càü€\x1c\x1cþ\x1cüà\x1cðààü€\x1c\x1càüðààüüà€à\x1cüà\x1c€ü\x1c\x1c\x1c\x1c\x1c\x1càà\x1c\x1c\x1cŽ\x1c\x1c\x1càü\x1c\x1càà\x1c\x1cààã\x1cpŽ\x1cààü\x1cü
\x1cþü\x1c\x1càü\x1càüŽ\x1cà\x1càüþü\x1cà\x1càà\x1c\x1càþ\x1c\x1càü€\x1c\x1c\x1cü\x1c\x1cüð\x1c\x1càà\x1c\x1cààã\x1cpŽ\x1cà\x1c€\x1càü\x1càüŽ\x1cà\x1càüþü\x1cà\x1cà\x1cŽ\x1cü
--- 8< ---

>  - Does it make a difference in Linux if the bootloader used the device  before?

If you mean, if U-boot uses the UART console before loading the kernel, then no.
Is that what you mean?
It makes no difference until the kernel is loaded, then the serial output gets corrupted.

>  - Can you dump the register space of the uart with v4.12-rc2 and
>    v4.12-rc2 + revert of e61c38d85b7392e?

Difficult to do that I think. The console is unusable in both directions. I can't get any
response from the console (through typing) once the kernel has started.

Regards,
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 15:01       ` Steve Twiss
@ 2017-05-23 16:08         ` Uwe Kleine-König
  2017-05-24 10:28           ` Steve Twiss
  0 siblings, 1 reply; 15+ messages in thread
From: Uwe Kleine-König @ 2017-05-23 16:08 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

Hello Steve,

On Tue, May 23, 2017 at 03:01:26PM +0000, Steve Twiss wrote:
> On 23 May 2017 15:37, Uwe Kleine-König wrote:
> > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> > On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> > > On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > > >
> > > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > > > ensure DCD and RI irqs to be off")
> > > > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > > > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > > > > The console becomes unreadable and unwritable.
> > > > >
> > > > > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > >
> > > > You're not the first to report this issue but you still have the chance
> > > > to be the first to test a suggested patch for it.
> > >
> > > I've just applied your patch against a clean linux-next/v4.12-rc2
> > > I added your patch ...
> > >
> > > > 	http://marc.info/?l=linux-serial&m=149434029912947&w=2
> > >
> [...]
> > > I've added that to my working directory, but I am still seeing the corrupted
> > > console output on the i.MX6 Q (quad) board.
> > 
> > I don't have a failing board (I think). So here are a few questions
> > about yours:
> > 
> >  - how does the dts snippet for your failing device look like?
> 
> I am using the standard DTS from the v4.12-rc2 kernel, no changes.
> I did an earlier test yesterday using the DTS from v4.11 to see if it was the new
> imx7 changes that have recently gone into the kernel but I still see the same
> effect.
> 
> >  - This is not the device the console runs on, right?
> 
> I am connected through the USB to UART, U22 on the i.MX6Q board.
> Terminal set to 115200 baud, no parity, 8bit data.
> 
> >  - Can you initialize the device in the bootloader and check if it is working there?
> 
> I can get U-boot ok for all cases.
> Once I TFTP the kernel across, I am okay until I get to "Starting kernel ...",
> then, the UART is "working" in the sense that I get the some characters in the style
> of the kernel starting up, but they are all garbled.
> 
> I expect the kernel has started ok, but I am unable to read/write through the UART
> console because of corruptions.
> 
> Console log:
> --- 8< ---
> U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)
> 
> CPU: Freescale i.MX6 family TO1.2 at 792 MHz
> Thermal sensor with ratio = 200
> Temperature:   46 C, calibration data 0x5f15527d

huh, it's hot in your office :-)

> mx6q pll1: 792MHz
> mx6q pll2: 528MHz
> mx6q pll3: 480MHz
> mx6q pll8: 50MHz
> ipg clock     : 66000000Hz
> ipg per clock : 66000000Hz
> uart clock    : 80000000Hz
> cspi clock    : 60000000Hz
> ahb clock     : 132000000Hz
> axi clock   : 264000000Hz
> emi_slow clock: 132000000Hz
> ddr clock     : 528000000Hz
> usdhc1 clock  : 198000000Hz
> usdhc2 clock  : 198000000Hz
> usdhc3 clock  : 198000000Hz
> usdhc4 clock  : 198000000Hz
> nfc clock     : 24000000Hz
> Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [WDOG ]
> Boot Device: SD
> I2C:   ready
> DRAM:   1 GB
> MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
> In:    serial
> Out:   serial
> Err:   serial
> Found PFUZE100! deviceid=10,revid=11
> Net:   got MAC address from IIM: 00:04:9f:02:e3:0a
> FEC0 [PRIME]
> Hit any key to stop autoboot:  0
> PHY indentify @ 0x1 = 0x004dd074
> FEC: Link is Up 796d
> Using FEC0 device
> TFTP from server 192.168.2.1; our IP address is 192.168.2.2
> Filename 'uImage_dtb.imx6q.v4.12-rc2'.
> Load address: 0x12000000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################################################
> done
> Bytes transferred = 5951108 (5ace84 hex)
> ## Booting kernel from Legacy Image at 12000000 ...
>    Image Name:
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    5951044 Bytes =  5.7 MB
>    Load Address: 10800000
>    Entry Point:  10800000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> à\x1cü\x1cü\x1cpþ\x1càüþü\x1cà\x1càà\x1càüþü\x1c\x1c\x1c\x1càüü\x1cþü\x1cà\x1cü\x1cà\x1cà\x1càüŽ\x1c\x1càü\x1càü\x1c\x1c\x1c\x1c\x1càà\x1cà\x1cà\x1c€à\x1càüþü\x1c\x1c\x1c\x1cààü\x1c\x1cüÿ
> à\x1càüŽü\x1cþü\x1càüàð\x1c\x1cààðàà\x1c\x1cà\x1c\x1c\x1cþ\x1c\x1c\x1c~pà\x1cœà\x1c`þ\x1cü\x1càüŽà\x1cà\x1c\x1cà\x1cü\x1cà\x1c\x1cþ\x1cüþ\x1c\x1c\x1c\x1cà\x1cü\x1c\x1cà\x1cŽàà\x1c\x1cà\x1c\x1c\x1c
> ààü\x1c\x1cüÿ\x1cà\x1càüŽü\x1cþü\x1càüàð\x1c\x1c€àà\x1c\x1cààààðàà\x1cðàüààüðààðààà\x1c\x1c\x1c\x1cþ\x1c\x1cüÿ\x1c\x1cüðü\x1c\x1cüŽ\x1cà\x1c\x1cüŽà\x1cà\x1c\x1cà\x1cüü
> \x1c\x1c\x1c\x1cþ\x1c\x1c\x1cüÿ\x1cà\x1càü\x1cü\x1cpð\x1c\x1cüÀ\x1c\x1cüþü\x1c\x1cü\x1càà\x1càüpÿ\x1c\x1cüààðàà\x1cðàüàð\x1c\x1cà\x1cüàŽ\x1c\x1c~8à\x1cŽàà\x1cŽààü€ààðààüp
> Ž\x1cà\x1c\x1cà\x1c\x1c\x1c\x1c\x1cüà\x1cà\x1c\x1cà\x1cààðàüðàà\x1cðà\x1cüàpþàüðàüðààþà\x1cðà\x1cüààà\x1cà\x1c\x1c\x1cààðàà\x1cðàüüàŽà\x1c€ü\x1c\x1c\x1c\x1c\x1c\x1càà\x1c
> \x1c\x1cŽ\x1cüà~ÿ\x1cüàà\x1càà\x1cü\x1c\x1c\x1cüŽà\x1cà\x1cü\x1cþ\x1càü~Žüàðààðààà\x1c\x1cà\x1cþà\x1c€\x1cü\x1cààð\x1c\x1cü~ÿ\x1càüŽà\x1càüŽü\x1cþü\x1cà\x1cðààà\x1c
> \x1c\x1cŽ\x1cüà~ÿ\x1cüàŽà\x1c\x1càü€\x1c\x1cþ\x1cüà\x1cðààü€\x1c\x1càüðààüüà€à\x1cüà\x1c€ü\x1c\x1c\x1c\x1c\x1c\x1càà\x1c\x1c\x1cŽ\x1c\x1c\x1càü\x1c\x1càà\x1c\x1cààã\x1cpŽ\x1cààü\x1cü
> \x1cþü\x1c\x1càü\x1càüŽ\x1cà\x1càüþü\x1cà\x1càà\x1c\x1càþ\x1c\x1càü€\x1c\x1c\x1cü\x1c\x1cüð\x1c\x1càà\x1c\x1cààã\x1cpŽ\x1cà\x1c€\x1càü\x1càüŽ\x1cà\x1càüþü\x1cà\x1cà\x1cŽ\x1cü

did you check with an oscilloscope if the baud rate is as expected (hmm,
but I wouldn't expect my patch to change the baud rate).

> --- 8< ---
> 
> >  - Does it make a difference in Linux if the bootloader used the device  before?
> 
> If you mean, if U-boot uses the UART console before loading the kernel, then no.
> Is that what you mean?

I didn't expect that it destroys the console UART so I expected that you
can make use of a 2nd UART in U-Boot somehow to already initialize the
port and check if that makes it magically work in Linux.

Note to myself: So we're taking about the UART at 0x02020000, it is
operated in DCE mode.

> It makes no difference until the kernel is loaded, then the serial
> output gets corrupted.
> 
> >  - Can you dump the register space of the uart with v4.12-rc2 and
> >    v4.12-rc2 + revert of e61c38d85b7392e?
> 
> Difficult to do that I think. The console is unusable in both directions. I can't get any
> response from the console (through typing) once the kernel has started.

ssh or telnet come to mind.

Can you try to just remove the line

	writel(0, sport->port.membase + UFCR);

that was introduced in the last hunk by commit e61c38d85b7?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 12:17 [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off Steve Twiss
  2017-05-23 14:09 ` Uwe Kleine-König
@ 2017-05-23 16:26 ` Fabio Estevam
  2017-05-24 10:32   ` Steve Twiss
  1 sibling, 1 reply; 15+ messages in thread
From: Fabio Estevam @ 2017-05-23 16:26 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig, Support Opensource

Hi Steve,

On Tue, May 23, 2017 at 9:17 AM, Steve Twiss
<stwiss.opensource@diasemi.com> wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> ensure DCD and RI irqs to be off")
>
> The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> be off, causes a serial console display problem the i.MX6Q SABRESD board.
> The console becomes unreadable and unwritable.
>
> Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and v4.12-rc2
>
> Hi,
>
> I have been seeing a problem with the serial output console on the i.MX6Q
> SABRESD, but not the i.MX6DL SABRESD. Everything was fine up to
> linux-mainline/v4.11 but changed after linux-next/next-20170501.
>
> Some bisection has pointed at the commit
> e61c38d85b7392e033ee03bca46f1d6006156175 which, once removed from my
> linux-next/v4.12-rc2 build allows the i.MX6Q board to display the console
> correctly again.
>
> This patch removes the original commit e61c38d85b7392e ("serial: imx:
> setup DCEDTE early and ensure DCD and RI irqs to be off") from  linux-next
> v4.12-rc2 and fixes the serial problem seen in the i.MX6Q SABRESD board.

How can the error be reproduced?

Care to share more details of the error, please?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 16:08         ` Uwe Kleine-König
@ 2017-05-24 10:28           ` Steve Twiss
  2017-05-24 11:57             ` Uwe Kleine-König
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Twiss @ 2017-05-24 10:28 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

Hi Uwe,

On 23 May 2017 17:09, Uwe Kleine-König wrote:

> On Tue, May 23, 2017 at 03:01:26PM +0000, Steve Twiss wrote:
> > On 23 May 2017 15:37, Uwe Kleine-König wrote:
> > > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> > > On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> > > > On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > > > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > > > >
> > > > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > > > > ensure DCD and RI irqs to be off")
> > > > > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > > > > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > > > > > The console becomes unreadable and unwritable.
> > > > > >
> > > > > > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > > > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > > >
> > > > > You're not the first to report this issue but you still have the chance
> > > > > to be the first to test a suggested patch for it.
> > > >
> > > > I've just applied your patch against a clean linux-next/v4.12-rc2
> > > > I added your patch ...
> > > >
> > > > > 	http://marc.info/?l=linux-serial&m=149434029912947&w=2
> > > >
> > [...]
> > > > I've added that to my working directory, but I am still seeing the corrupted
> > > > console output on the i.MX6 Q (quad) board.
> > >
> > > I don't have a failing board (I think). So here are a few questions
> > > about yours:
> > >
> > >  - how does the dts snippet for your failing device look like?
> >
> > I am using the standard DTS from the v4.12-rc2 kernel, no changes.
> > I did an earlier test yesterday using the DTS from v4.11 to see if it was the new
> > imx7 changes that have recently gone into the kernel but I still see the same
> > effect.
> >
> > >  - This is not the device the console runs on, right?
> >
> > I am connected through the USB to UART, U22 on the i.MX6Q board.
> > Terminal set to 115200 baud, no parity, 8bit data.
> >
> > >  - Can you initialize the device in the bootloader and check if it is working
> there?
> >
> > I can get U-boot ok for all cases.
> > Once I TFTP the kernel across, I am okay until I get to "Starting kernel ...",
> > then, the UART is "working" in the sense that I get the some characters in the style
> > of the kernel starting up, but they are all garbled.
> >
> > I expect the kernel has started ok, but I am unable to read/write through the UART
> > console because of corruptions.
> >
> > Console log:
> > --- 8< ---
[...]
> > Starting kernel ...
> >
> à\x1cü\x1cü\x1cpþ\x1càüþü\x1cà\x1càà\x1càüþü\x1c\x1c\x1c\x1càüü\x1cþü\x1cà\x1cü\x1cà\x1cà\x1càüŽ\x1c\x1càü\x1càü\x1c\x1c\x1c\x1c\x1càà\x1c
[...]
> 
> did you check with an oscilloscope if the baud rate is as expected (hmm,
> but I wouldn't expect my patch to change the baud rate).

I did try several different baudrates on the terminal connection, but I didn't find any
that worked. I've only checked the obvious ones however. I have not tried to debug
this problem any further than diagnosing what kernel commit caused the difference.

We also swapped compilers to begin with, when the first investigation began.
I noticed kernelci.org had some i.MX sabre boards, but used a different compiler
and did not see any problem.
Swapping the compiler made no difference and led us to find it only happened 
on the i.MX6Q  not the i.MX6DL. The kernelci.org site does not test any i.MX6Q
boards.

> > >  - Does it make a difference in Linux if the bootloader used the device before?
> >
> > If you mean, if U-boot uses the UART console before loading the kernel, then no.
> > Is that what you mean?
> 
> I didn't expect that it destroys the console UART so I expected that you
> can make use of a 2nd UART in U-Boot somehow to already initialize the
> port and check if that makes it magically work in Linux.
> 
> Note to myself: So we're taking about the UART at 0x02020000, it is
> operated in DCE mode.

> > It makes no difference until the kernel is loaded, then the serial
> > output gets corrupted.
> >
> > >  - Can you dump the register space of the uart with v4.12-rc2 and
> > >    v4.12-rc2 + revert of e61c38d85b7392e?
> >
> > Difficult to do that I think. The console is unusable in both directions. I can't get any
> > response from the console (through typing) once the kernel has started.
> 
> ssh or telnet come to mind.

Yup. We thought of that also, but finding the time at this side is the problem. 
I am looking at this Linux kernel i.MX6Q problem, but other customers are taking my
priority at the moment, so this does not have a very high level (probably because
we have found a "fix", at least to unblock our testing).
Dialog do want to assist the Linux community however. So I will try to help where I can.

> Can you try to just remove the line
> 	writel(0, sport->port.membase + UFCR);
> that was introduced in the last hunk by commit e61c38d85b7?

Yep. I can do this.
If I make this change, to the stock linux-next/v4.12-rc2 kernel, like this:

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 33509b4..68cfd3e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2194,9 +2194,7 @@ static int serial_imx_probe(struct platform_device *pdev)
                writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
                       sport->port.membase + UCR3);
 
-       } else {
-               writel(0, sport->port.membase + UFCR);
-       }
+       } 
 
        clk_disable_unprepare(sport->clk_ipg);

This console works okay.
Everything is ok on our i.MX6Q board after this change to v4.12-rc2.

-- 8< --
U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature:   25 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 198000000Hz
usdhc2 clock  : 198000000Hz
usdhc3 clock  : 198000000Hz
usdhc4 clock  : 198000000Hz
nfc clock     : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot:  0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x12000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 5951076 (5ace64 hex)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5951012 Bytes =  5.7 MB
   Load Address: 10800000
   Entry Point:  10800000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.12.0-rc2 (stwiss@test) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #1 SMP Wed May 24 11:10:14 BST 2017
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Freescale i.MX6 Quad SABRE Smart Device Board
...
-- 8< --

Regards,
Steve

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-23 16:26 ` Fabio Estevam
@ 2017-05-24 10:32   ` Steve Twiss
  2017-05-24 11:52     ` Fabio Estevam
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Twiss @ 2017-05-24 10:32 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig, Support Opensource

Hi Fabio,

On 23 May 2017 17:26 Fabio Estevam wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> On Tue, May 23, 2017 at 9:17 AM, Steve Twiss wrote:
> >
> > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > ensure DCD and RI irqs to be off")
> >
> > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > The console becomes unreadable and unwritable.
> >
> > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > ---
> > This patch applies against linux-next and v4.12-rc2
> >
> > Hi,
> >
> > I have been seeing a problem with the serial output console on the i.MX6Q
> > SABRESD, but not the i.MX6DL SABRESD. Everything was fine up to
> > linux-mainline/v4.11 but changed after linux-next/next-20170501.
> >
> > Some bisection has pointed at the commit
> > e61c38d85b7392e033ee03bca46f1d6006156175 which, once removed from my
> > linux-next/v4.12-rc2 build allows the i.MX6Q board to display the console
> > correctly again.
> >
> > This patch removes the original commit e61c38d85b7392e ("serial: imx:
> > setup DCEDTE early and ensure DCD and RI irqs to be off") from  linux-next
> > v4.12-rc2 and fixes the serial problem seen in the i.MX6Q SABRESD board.
> 
> How can the error be reproduced?
> 
> Care to share more details of the error, please?

The USB to UART connection gets corrupted.
If this patch is applied to the kernel, the i.MX6 Q (quad), and only this board as far as
we know, starts to fail. This does *not* change the i.MX6DL and other sabre boards
have been tested on kernelci.org and do not see a problem.

An NXP/Freescale SABRESD i.MX6 Q board is requred.

My system for testing is to TFTP the Linux kernel over an ethernet connection. The
U-boot executes okay and the UART is working at that point. When the kernel loads
the console trace becomes garbled, in the sense that I get the some characters being
output to the console, in the style of the kernel starting up, but they are not correct.

I expect the kernel has started ok, but I am unable to read/write through the UART
console because of corruptions.

Console log with the output I am seeing with linux-next/v4.12-rc2
--- 8< ---
U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature:   46 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 198000000Hz
usdhc2 clock  : 198000000Hz
usdhc3 clock  : 198000000Hz
usdhc4 clock  : 198000000Hz
nfc clock     : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [WDOG ]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot:  0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x12000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 5951108 (5ace84 hex)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5951044 Bytes =  5.7 MB
   Load Address: 10800000
   Entry Point:  10800000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

à ü ü pþ àüþü à àà àüþü    àüü þü à ü à à àüŽ  àü àü     àà à à €à àüþü    ààü  üÿ
à àüŽü þü àüàð  ààðàà  à   þ   ~pà œà `þ ü àüŽà à  à ü à  þ üþ    à ü  à Žàà  à   
ààü  üÿ à àüŽü þü àüàð  €àà  ààààðàà ðàüààüðààðààà    þ  üÿ  üðü  üŽ à  üŽà à  à üü
    þ   üÿ à àü ü pð  üÀ  üþü  ü àà àüpÿ  üààðàà ðàüàð  à üàŽ  ~8à Žàà Žààü€ààðààüp
Ž à  à     üà à  à ààðàüðàà ðà üàpþàüðàüðààþà ðà üààà à   ààðàà ðàüüàŽà €ü      àà 
  Ž üà~ÿ üàà àà ü   üŽà à ü þ àü~Žüàðààðààà  à þà € ü ààð  ü~ÿ àüŽà àüŽü þü à ðààà 
  Ž üà~ÿ üàŽà  àü€  þ üà ðààü€  àüðààüüà€à üà €ü      àà   Ž   àü  àà  ààã pŽ ààü ü
 þü  àü àüŽ à àüþü à àà  àþ  àü€   ü  üð  àà  ààã pŽ à € àü àüŽ à àüþü à à Ž ü
--- 8< ---

Is this enough information for you?
It would be difficult to reproduce without the i.MX6Q (quad) board from Freescale/NXP
I think.

Regards,
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-24 10:32   ` Steve Twiss
@ 2017-05-24 11:52     ` Fabio Estevam
  2017-05-24 12:02       ` Uwe Kleine-König
  2017-05-24 12:49       ` Steve Twiss
  0 siblings, 2 replies; 15+ messages in thread
From: Fabio Estevam @ 2017-05-24 11:52 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig, Support Opensource

Hi Steve,

On Wed, May 24, 2017 at 7:32 AM, Steve Twiss
<stwiss.opensource@diasemi.com> wrote:

> The USB to UART connection gets corrupted.
> If this patch is applied to the kernel, the i.MX6 Q (quad), and only this board as far as
> we know, starts to fail. This does *not* change the i.MX6DL and other sabre boards
> have been tested on kernelci.org and do not see a problem.
>
> An NXP/Freescale SABRESD i.MX6 Q board is requred.
>
> My system for testing is to TFTP the Linux kernel over an ethernet connection. The
> U-boot executes okay and the UART is working at that point. When the kernel loads
> the console trace becomes garbled, in the sense that I get the some characters being
> output to the console, in the style of the kernel starting up, but they are not correct.
>
> I expect the kernel has started ok, but I am unable to read/write through the UART
> console because of corruptions.
>
> Console log with the output I am seeing with linux-next/v4.12-rc2
> --- 8< ---
> U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)

Thanks for your detailed explanation.

I also have a mx6q sabresd board here, but the error did not happen
when I use a recent U-Boot version.

I would like to use the same U-Boot version here as well to help
debugging this problem.

Could you please let me know which 2009.08 branch you used? Is it any
one from git.freescale.com
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/refs/heads ?

Thanks,

Fabio Estevam

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-24 10:28           ` Steve Twiss
@ 2017-05-24 11:57             ` Uwe Kleine-König
  0 siblings, 0 replies; 15+ messages in thread
From: Uwe Kleine-König @ 2017-05-24 11:57 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Support Opensource, kernel

Hello Steve,

On Wed, May 24, 2017 at 10:28:58AM +0000, Steve Twiss wrote:
> On 23 May 2017 17:09, Uwe Kleine-König wrote:
> 
> > On Tue, May 23, 2017 at 03:01:26PM +0000, Steve Twiss wrote:
> > > On 23 May 2017 15:37, Uwe Kleine-König wrote:
> > > > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> > > > On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> > > > > On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > > > > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > > > > >
> > > > > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > > > > > ensure DCD and RI irqs to be off")
> > > > > > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > > > > > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > > > > > > The console becomes unreadable and unwritable.
> > > > > > >
> > > > > > > Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > > > > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > > > >
> > > > > > You're not the first to report this issue but you still have the chance
> > > > > > to be the first to test a suggested patch for it.
> > > > >
> > > > > I've just applied your patch against a clean linux-next/v4.12-rc2
> > > > > I added your patch ...
> > > > >
> > > > > > 	http://marc.info/?l=linux-serial&m=149434029912947&w=2
> > > > >
> > > [...]
> > > > > I've added that to my working directory, but I am still seeing the corrupted
> > > > > console output on the i.MX6 Q (quad) board.
> > > >
> > > > I don't have a failing board (I think). So here are a few questions
> > > > about yours:
> > > >
> > > >  - how does the dts snippet for your failing device look like?
> > >
> > > I am using the standard DTS from the v4.12-rc2 kernel, no changes.
> > > I did an earlier test yesterday using the DTS from v4.11 to see if it was the new
> > > imx7 changes that have recently gone into the kernel but I still see the same
> > > effect.
> > >
> > > >  - This is not the device the console runs on, right?
> > >
> > > I am connected through the USB to UART, U22 on the i.MX6Q board.
> > > Terminal set to 115200 baud, no parity, 8bit data.
> > >
> > > >  - Can you initialize the device in the bootloader and check if it is working
> > there?
> > >
> > > I can get U-boot ok for all cases.
> > > Once I TFTP the kernel across, I am okay until I get to "Starting kernel ...",
> > > then, the UART is "working" in the sense that I get the some characters in the style
> > > of the kernel starting up, but they are all garbled.
> > >
> > > I expect the kernel has started ok, but I am unable to read/write through the UART
> > > console because of corruptions.
> > >
> > > Console log:
> > > --- 8< ---
> [...]
> > > Starting kernel ...
> > >
> > à\x1cü\x1cü\x1cpþ\x1càüþü\x1cà\x1càà\x1càüþü\x1c\x1c\x1c\x1càüü\x1cþü\x1cà\x1cü\x1cà\x1cà\x1càüŽ\x1c\x1càü\x1càü\x1c\x1c\x1c\x1c\x1càà\x1c
> [...]
> > 
> > did you check with an oscilloscope if the baud rate is as expected (hmm,
> > but I wouldn't expect my patch to change the baud rate).
> 
> I did try several different baudrates on the terminal connection, but I didn't find any
> that worked. I've only checked the obvious ones however. I have not tried to debug
> this problem any further than diagnosing what kernel commit caused the difference.
> 
> We also swapped compilers to begin with, when the first investigation began.
> I noticed kernelci.org had some i.MX sabre boards, but used a different compiler
> and did not see any problem.
> Swapping the compiler made no difference and led us to find it only happened 
> on the i.MX6Q  not the i.MX6DL. The kernelci.org site does not test any i.MX6Q
> boards.
> 
> > > >  - Does it make a difference in Linux if the bootloader used the device before?
> > >
> > > If you mean, if U-boot uses the UART console before loading the kernel, then no.
> > > Is that what you mean?
> > 
> > I didn't expect that it destroys the console UART so I expected that you
> > can make use of a 2nd UART in U-Boot somehow to already initialize the
> > port and check if that makes it magically work in Linux.
> > 
> > Note to myself: So we're taking about the UART at 0x02020000, it is
> > operated in DCE mode.
> 
> > > It makes no difference until the kernel is loaded, then the serial
> > > output gets corrupted.
> > >
> > > >  - Can you dump the register space of the uart with v4.12-rc2 and
> > > >    v4.12-rc2 + revert of e61c38d85b7392e?
> > >
> > > Difficult to do that I think. The console is unusable in both directions. I can't get any
> > > response from the console (through typing) once the kernel has started.
> > 
> > ssh or telnet come to mind.
> 
> Yup. We thought of that also, but finding the time at this side is the problem. 
> I am looking at this Linux kernel i.MX6Q problem, but other customers are taking my
> priority at the moment, so this does not have a very high level (probably because
> we have found a "fix", at least to unblock our testing).
> Dialog do want to assist the Linux community however. So I will try to help where I can.
> 
> > Can you try to just remove the line
> > 	writel(0, sport->port.membase + UFCR);
> > that was introduced in the last hunk by commit e61c38d85b7?
> 
> Yep. I can do this.
> If I make this change, to the stock linux-next/v4.12-rc2 kernel, like this:
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 33509b4..68cfd3e 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -2194,9 +2194,7 @@ static int serial_imx_probe(struct platform_device *pdev)
>                 writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
>                        sport->port.membase + UCR3);
>  
> -       } else {
> -               writel(0, sport->port.membase + UFCR);
> -       }
> +       } 
>  
>         clk_disable_unprepare(sport->clk_ipg);
> 
> This console works okay.

OK, thanks for testing. I understand now what is broken. I will check
where I can squeeze in a timeslot to create a patch.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-24 11:52     ` Fabio Estevam
@ 2017-05-24 12:02       ` Uwe Kleine-König
  2017-05-24 12:49       ` Steve Twiss
  1 sibling, 0 replies; 15+ messages in thread
From: Uwe Kleine-König @ 2017-05-24 12:02 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Steve Twiss, Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL,
	LINUX-SERIAL, Lucas Stach, Support Opensource

Hey Fabio,

On Wed, May 24, 2017 at 08:52:50AM -0300, Fabio Estevam wrote:
> On Wed, May 24, 2017 at 7:32 AM, Steve Twiss
> <stwiss.opensource@diasemi.com> wrote:
> 
> > The USB to UART connection gets corrupted.
> > If this patch is applied to the kernel, the i.MX6 Q (quad), and only this board as far as
> > we know, starts to fail. This does *not* change the i.MX6DL and other sabre boards
> > have been tested on kernelci.org and do not see a problem.
> >
> > An NXP/Freescale SABRESD i.MX6 Q board is requred.
> >
> > My system for testing is to TFTP the Linux kernel over an ethernet connection. The
> > U-boot executes okay and the UART is working at that point. When the kernel loads
> > the console trace becomes garbled, in the sense that I get the some characters being
> > output to the console, in the style of the kernel starting up, but they are not correct.
> >
> > I expect the kernel has started ok, but I am unable to read/write through the UART
> > console because of corruptions.
> >
> > Console log with the output I am seeing with linux-next/v4.12-rc2
> > --- 8< ---
> > U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)
> 
> Thanks for your detailed explanation.
> 
> I also have a mx6q sabresd board here, but the error did not happen
> when I use a recent U-Boot version.
> 
> I would like to use the same U-Boot version here as well to help
> debugging this problem.
> 
> Could you please let me know which 2009.08 branch you used? Is it any
> one from git.freescale.com
> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/refs/heads ?

The problem is that RFDIV, RXTL and TXTL are overwritten in the UFCR
register.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-24 11:52     ` Fabio Estevam
  2017-05-24 12:02       ` Uwe Kleine-König
@ 2017-05-24 12:49       ` Steve Twiss
  2017-05-24 13:52         ` Fabio Estevam
  1 sibling, 1 reply; 15+ messages in thread
From: Steve Twiss @ 2017-05-24 12:49 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig, Support Opensource

Hi Fabio,

On 24 May 2017 12:53 Fabio Estevam wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> On Wed, May 24, 2017 at 7:32 AM, Steve Twiss wrote:
> 
> > The USB to UART connection gets corrupted.
> > If this patch is applied to the kernel, the i.MX6 Q (quad), and only this board as far as
> > we know, starts to fail. This does *not* change the i.MX6DL and other sabre boards
> > have been tested on kernelci.org and do not see a problem.
> >
> > An NXP/Freescale SABRESD i.MX6 Q board is requred.
> >
> > My system for testing is to TFTP the Linux kernel over an ethernet connection. The
> > U-boot executes okay and the UART is working at that point. When the kernel loads
> > the console trace becomes garbled, in the sense that I get the some characters being
> > output to the console, in the style of the kernel starting up, but they are not correct.
> >
> > I expect the kernel has started ok, but I am unable to read/write through the UART
> > console because of corruptions.
> >
> > Console log with the output I am seeing with linux-next/v4.12-rc2
> > --- 8< ---
> > U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)
> 
> Thanks for your detailed explanation.
> 
> I also have a mx6q sabresd board here, but the error did not happen
> when I use a recent U-Boot version.
>
> I would like to use the same U-Boot version here as well to help
> debugging this problem.

For the previous tests I was using a slightly modified U-Boot from an old Freescale
Android release JB43_110, but I've just compiled up the standard u-boot from
the Freescale git repository, and I get the same results.

> Could you please let me know which 2009.08 branch you used? Is it any
> one from git.freescale.com
> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/refs/heads ?

I used this tag: jb4.3_1.1.1-ga
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?id=jb4.3_1.1.1-ga

This repo is slightly modified for a project I am working on, but it only queries
the  I2C for devices before printing out some messages, so minor changes I
think. Here's the output from the console:

--- 8< ---
U-Boot 2009.08 (May 24 2017 - 13:15:47)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature:   38 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 198000000Hz
usdhc2 clock  : 198000000Hz
usdhc3 clock  : 198000000Hz
usdhc4 clock  : 198000000Hz
nfc clock     : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot:  0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x12000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 5951076 (5ace64 hex)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5951012 Bytes =  5.7 MB
   Load Address: 10800000
   Entry Point:  10800000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
--- 8< ---

Regards,
Stephen

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-24 12:49       ` Steve Twiss
@ 2017-05-24 13:52         ` Fabio Estevam
  2017-05-24 16:08           ` Steve Twiss
  0 siblings, 1 reply; 15+ messages in thread
From: Fabio Estevam @ 2017-05-24 13:52 UTC (permalink / raw)
  To: Steve Twiss
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig, Support Opensource

Hi Steve,

On Wed, May 24, 2017 at 9:49 AM, Steve Twiss
<stwiss.opensource@diasemi.com> wrote:

> I used this tag: jb4.3_1.1.1-ga
> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?id=jb4.3_1.1.1-ga
>
> This repo is slightly modified for a project I am working on, but it only queries
> the  I2C for devices before printing out some messages, so minor changes I
> think. Here's the output from the console:

I am not able to reproduce it using this same U-Boot version on my
mx6sabresd board:

https://pastebin.com/ppnrnidr

Had to select dtb append in the kernel menu config.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
  2017-05-24 13:52         ` Fabio Estevam
@ 2017-05-24 16:08           ` Steve Twiss
  0 siblings, 0 replies; 15+ messages in thread
From: Steve Twiss @ 2017-05-24 16:08 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Greg Kroah-Hartman, Jiri Slaby, LINUX-KERNEL, LINUX-SERIAL,
	Lucas Stach, Uwe Kleine-Konig, Support Opensource

Hi Fabio,

On 24 May 2017 14:53 Fabio Estevam wrote,
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> On Wed, May 24, 2017 at 9:49 AM, Steve Twiss wrote:
> 
> > I used this tag: jb4.3_1.1.1-ga
> > http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?id=jb4.3_1.1.1-ga
> >
> > This repo is slightly modified for a project I am working on, but it only queries
> > the  I2C for devices before printing out some messages, so minor changes I
> > think. Here's the output from the console:
> 
> I am not able to reproduce it using this same U-Boot version on my
> mx6sabresd board:
> 
> https://pastebin.com/ppnrnidr

That's very interesting.
Once I apply the test change from Uwe, I can get a console trace.

> Uwe Kleine-König wrote:
> > Can you try to just remove the line
> > 	writel(0, sport->port.membase + UFCR);

The differences in the kernel console logs are ...

My board : Your board differences
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ] : Board: i.MX6Q-SABRESD: unknown-board Board: 0x63011 [POR ]
Found PFUZE100! deviceid=10,revid=11 : Found PFUZE100! deviceid=10,revid=10

... and others, but.. I do not have "console=ttymxc0,115200" in my kernel
command line.

Yes. I can verify, using the raw linux-next/v4.12-rc2 I get the console error.
When I add "console=ttymxc0,115200" to my U-boot environment and the
kernel command-line, the kernel console starts working again.

That would indicate the test on the i.MX6DL might be misleading, since my
colleague ran that using their bootloader set-up. So, my assertion this was
only visible on the i.MX6Q could be wrong.

There's no way to to check this until tomorrow now.
I'll check check on the i.MX6DL using my bootloader environment when I
get access to an i.MX6DL board.

Regards,
Stephen

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2017-05-24 16:09 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-23 12:17 [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off Steve Twiss
2017-05-23 14:09 ` Uwe Kleine-König
2017-05-23 14:28   ` Steve Twiss
2017-05-23 14:37     ` Uwe Kleine-König
2017-05-23 15:01       ` Steve Twiss
2017-05-23 16:08         ` Uwe Kleine-König
2017-05-24 10:28           ` Steve Twiss
2017-05-24 11:57             ` Uwe Kleine-König
2017-05-23 16:26 ` Fabio Estevam
2017-05-24 10:32   ` Steve Twiss
2017-05-24 11:52     ` Fabio Estevam
2017-05-24 12:02       ` Uwe Kleine-König
2017-05-24 12:49       ` Steve Twiss
2017-05-24 13:52         ` Fabio Estevam
2017-05-24 16:08           ` Steve Twiss

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.