GTA01 shared UART vs. flow control (bug #788)
werner at openmoko.org
Tue Jan 22 15:28:41 CET 2008
Mike Westerhof wrote:
> As we embark on this discussion, can somone please define "intrusive"
> for me?
Hmm, I guess a definition would go along these lines:
- changes a lot of code
- changes unrelated code
- changes the logic of existing code
In this case, it's mainly the introduction of platform-specific code in
a general driver that's ugly. I also find the use of "unused" and the
logic leading there quite scary.
to aim too high and too low at the same time. Too high,
because it tries to provide the abstraction of two independent UARTs
(which seems to be ambitious beyond what we actually need), but too
low, because it doesn't implement this generalization in a truly
> It strikes me as a completely relative term, which makes the evaluation
> of solutions for this problem largely subjective
It is :-)
Anyway, don't you think just keeping the serial console from getting
permanently stuck would solve the issue for all practical purposes ?
The algorithm I proposed would let the console resume operation as
soon as the misconfiguration is cleared. So you'd only lose messages
if your setup/bringdown sequence is buggy and your kernel crashes at
the same time. As we all know, juggling two types of brokenness at
the same time it bad anyway, so this shouldn't be much of an issue :-)
> (The correct, although *impractical* solution, is to put the missing
> pullups or pulldowns on the mux so that the console flow-control lines
> are in the correct state to make this entire problem a total non-problem.)
Yeah, I wish someone would have thought of putting that pull-down :-(
Pull-up would be easy - the 2410 has that, but alas, no pull-down.
More information about the openmoko-kernel