Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?

Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?

[Rick Bronson]

> Leaving only one map_desc[] entry left using MT_DEVICE not MT_MEMORY_SO...
> I didn't try this, since I'm currently not hooking up that serial port,
> but dmesg does show(*):
> 
>  Serial: 8250/16550 driver3 ports, IRQ sharing disabled
>  serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
>  serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
>  serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16650V2
>  console [ttyS2] enabled
> 
> Is that what you saw too?

  Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that
I had nothing except "Uncompressing Linux........".  ST16650V2 is a
clue that something went awry in auto-detection of the type of 8250
serial port.  With the MT_MEMORY_SO change, I get:

Serial: 8250/16550 driver4 ports, IRQ sharing enabled                           
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654                  
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654                  
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654                  
console [ttyS2] enabled                                                         

  I guess we don't see this problem on the other 2 ports since they
are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

  Rick

Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?

[David Brownell]

On Sunday 02 November 2008, Rick Bronson wrote:
> > Is that what you saw too?
> 
>   Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that
> I had nothing except "Uncompressing Linux........".  

I don't have DEBUG_LL=y ... if you had some kind of network
link configured over USB, could you SSH in?  (I can.)


>   I guess we don't see this problem on the other 2 ports since they
> are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Hmm, inconsistency is to be avoided.  :)

I wonder what the root cause is ... is the driver missing
various barriers needed to make MT_DEVICE work?  Or is the
MT_DEVICE incorrect in the first place?  "git whatchanged"
didn't show any recent changes that seemed (on a quick
glance) to affect I/O at that level.  Maybe it was one of
the other TTY changes interacting here.

- Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

* David Brownell <david-b@pacbell.net> [081102 11:26]:
> On Sunday 02 November 2008, Rick Bronson wrote:
> > > Is that what you saw too?
> > 
> >   Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that
> > I had nothing except "Uncompressing Linux........".  
> 
> I don't have DEBUG_LL=y ... if you had some kind of network
> link configured over USB, could you SSH in?  (I can.)
> 
> 
> >   I guess we don't see this problem on the other 2 ports since they
> > are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).
> 
> Hmm, inconsistency is to be avoided.  :)
> 
> I wonder what the root cause is ... is the driver missing
> various barriers needed to make MT_DEVICE work?  Or is the
> MT_DEVICE incorrect in the first place?  "git whatchanged"
> didn't show any recent changes that seemed (on a quick
> glance) to affect I/O at that level.  Maybe it was one of
> the other TTY changes interacting here.

Yeah I don't know what may have changed, or have things just
gotten faster now with cortex since 2.6.27?

Anyways, this patch fixes the issue for me without marking
things strongly ordered. Rick, does this work for you?

Regards,

Tony

[-- Attachment #2: flush-posted-8250.patch --]
[-- Type: text/x-diff, Size: 906 bytes --]

>From 57eea529292418a20a119c5b18d7636cf44992ae Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 31 Oct 2008 16:47:42 -0700
Subject: [PATCH] serial: Flush posted write on 34xx to make 8250 work

On omap34xx, we need to flush posted writes for TX.

Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 5f383d8..629a16c 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -413,6 +413,13 @@ serial_out(struct uart_8250_port *up, int offset, int value)
 
 	case UPIO_MEM:
 		writeb(value, up->port.membase + offset);
+#ifdef CONFIG_ARCH_OMAP
+		/* Flush posted write for TX */
+		if (cpu_is_omap34xx() && is_omap_port(up) &&
+			(save_offset == UART_TX || save_offset == UART_IER ||
+				save_offset == UART_LCR))
+			value = serial_in(up, UART_LCR); /* Safe to read */
+#endif
 		break;
 
 	case UPIO_RM9000:

Re: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re:

[Grazvydas Ignotas]

> does this work for you?
Works on Pandora, which had garbled text instead of no output at all.

Re: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

[Ming Lei]

2008/11/3 Tony Lindgren <tony@atomide.com>:
> * David Brownell <david-b@pacbell.net> [081102 11:26]:
>> On Sunday 02 November 2008, Rick Bronson wrote:
>> > > Is that what you saw too?
>> >
>> >   Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that
>> > I had nothing except "Uncompressing Linux........".
>>
>> I don't have DEBUG_LL=y ... if you had some kind of network
>> link configured over USB, could you SSH in?  (I can.)
>>
>>
>> >   I guess we don't see this problem on the other 2 ports since they
>> > are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).
>>
>> Hmm, inconsistency is to be avoided.  :)
>>
>> I wonder what the root cause is ... is the driver missing
>> various barriers needed to make MT_DEVICE work?  Or is the
>> MT_DEVICE incorrect in the first place?  "git whatchanged"
>> didn't show any recent changes that seemed (on a quick
>> glance) to affect I/O at that level.  Maybe it was one of
>> the other TTY changes interacting here.
>
> Yeah I don't know what may have changed, or have things just
> gotten faster now with cortex since 2.6.27?
>
> Anyways, this patch fixes the issue for me without marking
> things strongly ordered. Rick, does this work for you?

This patch still works for me.
Thanks!

>
> Regards,
>
> Tony
>



-- 
Lei Ming

Re: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

[Tony Lindgren]

* Ming Lei <tom.leiming@gmail.com> [081103 04:59]:
> 2008/11/3 Tony Lindgren <tony@atomide.com>:
> > * David Brownell <david-b@pacbell.net> [081102 11:26]:
> >> On Sunday 02 November 2008, Rick Bronson wrote:
> >> > > Is that what you saw too?
> >> >
> >> >   Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that
> >> > I had nothing except "Uncompressing Linux........".
> >>
> >> I don't have DEBUG_LL=y ... if you had some kind of network
> >> link configured over USB, could you SSH in?  (I can.)
> >>
> >>
> >> >   I guess we don't see this problem on the other 2 ports since they
> >> > are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).
> >>
> >> Hmm, inconsistency is to be avoided.  :)
> >>
> >> I wonder what the root cause is ... is the driver missing
> >> various barriers needed to make MT_DEVICE work?  Or is the
> >> MT_DEVICE incorrect in the first place?  "git whatchanged"
> >> didn't show any recent changes that seemed (on a quick
> >> glance) to affect I/O at that level.  Maybe it was one of
> >> the other TTY changes interacting here.
> >
> > Yeah I don't know what may have changed, or have things just
> > gotten faster now with cortex since 2.6.27?
> >
> > Anyways, this patch fixes the issue for me without marking
> > things strongly ordered. Rick, does this work for you?
> 
> This patch still works for me.
> Thanks!

Well the real problem has been found, there's a bug with the recent
ptebits patches, which causes section mappings to be just MT_MEMORY
instead of MT_DEVICE..

So let's put things on hold until we have a real fix for that on the
linux-arm-kernel mailing list, hopefully today.

Regards,

Tony

RE: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Well the real problem has been found, there's a bug with the recent
> ptebits patches, which causes section mappings to be just MT_MEMORY
> instead of MT_DEVICE..
>
> So let's put things on hold until we have a real fix for that on the
> linux-arm-kernel mailing list, hopefully today.

That makes a lot more sense.  It was odd to see a flurry of failures.

SO vs. DEVICE were occasional errors usually seen under irq stress. It never took down the serial port.  Mapping things a MEMORY surely would.

Regards,
Richard W.

Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?

[Tony Lindgren]

* Rick Bronson <rick@efn.org> [081102 10:07]:
> 
> > Leaving only one map_desc[] entry left using MT_DEVICE not MT_MEMORY_SO...
> > I didn't try this, since I'm currently not hooking up that serial port,
> > but dmesg does show(*):
> > 
> >  Serial: 8250/16550 driver3 ports, IRQ sharing disabled
> >  serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
> >  serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
> >  serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16650V2
> >  console [ttyS2] enabled
> > 
> > Is that what you saw too?
> 
>   Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that
> I had nothing except "Uncompressing Linux........".  ST16650V2 is a
> clue that something went awry in auto-detection of the type of 8250
> serial port.  With the MT_MEMORY_SO change, I get:
> 
> Serial: 8250/16550 driver4 ports, IRQ sharing enabled                           
> serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654                  
> serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654                  
> serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654                  
> console [ttyS2] enabled                                                         
> 
>   I guess we don't see this problem on the other 2 ports since they
> are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Rick, can you please reply with your Signed-off-by for your patch?

Let's push that one, then continue thinking about the so/device
issues.

Tony