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)
