andy git 06/15 suspend/resume observations

[Mike (mwester)]

Sean McNeil wrote:
> Please excuse my ignorance (once again), but I'm unclear about the
> manipulation required for GSM in the serial driver. Is this because of
> multiplexing? Isn't the GSM simply a uart with hw flow control and RTS
> causing an interrupt when in suspend? I noticed several places that test
> for GSM_PORT and thought this might be able to be generic across all of
> the ports.

Anything involving GSM_PORT and nspy is just debug and instrumentation
to permit monitoring of the GSM/UART communications.  That's the bulk of
the changes from the stock s3c2410.c serial driver in terms of
lines-of-code.

Another of the debugging changes is to print a message when a UART error
(overrun, framing, parity, etc) is encountered.  It's intended to
facilitate analysis of user-submitted bug reports and problems -- if
they provide the output from dmesg, we'll be able to see if a problem
may be related to the serial comms and the known issues the GSM has with
flow-control.

In terms of non-debug code, there is a test in the suspend handler to
see if a GSM interrupt has occurred, and the suspend is aborted if so.

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
solution that didn't modify the serial driver.  That got implemented.
However, it seems that every time I turn around, there's something else
that gets its grubby electronic paws on the console on the GTA01, and
screws things up.  The low-level resume debug messages being fed
directly to the UART can be suppressed by defconfig changes (still not
sure if the patch to fix that is in the official builds yet!).  But even
then, a race condition exists where the console is enabled before the
neo1973_pm_gsm driver resumes and disables the console -- during this
window the GSM would get loads of marvelously confusing output that
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.

(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")

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.)

Mike (mwester)