andy git 06/15 suspend/resume observations

[Sean McNeil]

Mike (mwester) wrote:
> 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.
>   

Does it make sense to make this generic and provide instrumentation and 
monitor all the ports?

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