Harald Welte wrote:
On Mon, Apr 21, 2008 at 01:32:33PM -0500, Mike (mwester) wrote:
I'm asking an opinion question of the kernel gurus...
Is the s3c2410 serial driver known to work well in regard to flow
control and suspend/resume? Or are we perhaps testing new ground?
what do you mean by 'worl well in regard to flow control'? I'm pretty
sure all registers get restored to their previous state.
I'm wondering how well this is generically tested and what the
parameters of that testing or experience might be. Specifically, do we
know for certain that if AFC is enabled, and the device suspends and
resumes, that there is no point during that set of transitions where the
CTS line may "glitch" and cause data loss? And if this is true, is that
knowledge for the case where the port in question is the console or not?
(I see very different paths through the PM code for the low-level
console case, and not).
There might be some ordering problem between GPIO resume (MODEM_ON) and
serial resume.
Yep, this is one of the first things I looked at, actually. But if the
GPIO state is preserved during resume, then the MUX will continue to
connect the GSM to the UART (rather than switching to the console)
throughout the suspend/resume process. There is a race condition with
the console code, which initializes earlier than the GSM PM code -- but
that race can be easily addressed by removing ttySAC0 from the consoles
passed in on the command line.
(When suspended, the MUX is still powered, right? Are there any other
inputs to the MUX that might cause the MUX to "glitch" during the
suspend/resume process?)
Another note: Two days ago I was chatting with Alan Cox (who is working
a lot on the serial/tty layer recently) about the problem that serial
drivers busy-spin indefinitely waiting for CTS in case a serial console
is enabled on a port with hardware flow control.
He stated that he thinks there are valid applications where people want
that, but wouldn't mind any platform or machine specific driver that
implemented a timeout or just ignored hw flow control at all when using
the serial console. A config option to decide on this behaviour would
also be fine, he stated. Another possible suggestion would have been to
have a seperate set of termios options to be used from the serial
console (separate from the ones that are used by the /dev/ttyS device).
That's good news; at least one of the patches has a chance of making
into the mainline then. If the answer to my question is, in fact, that
nobody knows that the s3c2410 UART driver is actually properly
functional in the face of AFC and suspend/resume, perhaps there will be
additional patches going upstream...
Cheers,
Thanks,
Mike (mwester)
