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 <tony@atomide.com>]

* 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