andy git 06/15 suspend/resume observations

Andy Green andy at
Fri Jun 20 10:20:03 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| Also important is that the console code has a test to not print anything
| if the mux is switched to the GSM.  This affects only the GTA01.  We had
| a lengthy discussion on this along while back, and there seemed to be a
| usually resulted in both GSM and gsmd going out to lunch.  THAT problem
| can be resolved by removing ttySAC0 as a console altogether.  BUT when
| you do that, it turns out that init will select ttys0 for its output --
| and then you get messages from init coming directly into the tty driver,
| and getting mixed up with messages to the GSM.  It's really a horrible,
| horrible mess, and its so incredibly frustrating to think that there had
| to have been a meeting at Openmoko/FIC at one point, where SOMEBODY
| could have said one sentence and had the GSM/console mux changed to
| GPS/console -- and the grief that would have solved is immeasurable.

It's basically hell, isn't it.

FWIW these decisions come because from hardware side view only, the
question seems to be about running out of UART pins and making a smart
cheap decision to stick a mux in.  There is no Hell visible from that
view because the guys down there have no idea of the destruction that
causes up at this level.  Muxing against GPS would have just moved the
Hell over there.  Other way around but same issue: "what do you need a
system management controller for, you got a CPU!".

What happens if GTA01 folks had console=ttySAC0 removed from commandline
and we either added a fake ttyS3 to take init output, or configurably
"fixed" init so it didn't take a dump on ttys0 "just because" but used
/dev/null?  That sounds like a way because the patient clearly needs
radical surgery if he is to be saved.

| (Sorry for the rambling on that last two-line patch, it's a painful
| point.  I expended a lot of effort rewriting in response to criticism
| from many sources about the attempted solutions, only to arrive back at
| that very same solution 6 months later.  So if you perceive me to be
| difficult on the recent GSM flow-control issue we've been discussing,
| it's because this time around I'm determined not to go down what I know
| in my gut to be the wrong path -- as they say, "been there, done that")

Yes if the argument involves "upstream" and leads to a "solution" of
permanent inaction, we should instead study if there is a case for us
carrying the code for the solution that we need until the happy day
upstream has a better way, or we figure a better way, or forever,
whichever comes first.

| Finally, there is a bunch of other code that still may have to be done
| for the GTA01 to solve the overrun problem.  I have no idea where/how
| that will be done, but it's looking like some major modifications to the
| serial driver will be required.  (Hopefully we don't need this for the
| GTA02, but until we get more results on large transfers under load we
| don't know for certain that it's better -- the flaw appears to be in the
| GSM, and both GTA's use the same GSM.)

I don't know much about this issue yet, so this is a bit forward of me,
but I find I am suspicious that the flow control behaviours might still
be hidden symptom of resume ordering or some other kind of sequencing.
Are they ever seen outside of resume?

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list