?: Does the s3c2410 serial driver *really* work (suspend/resume)?
mwester at dls.net
Tue Apr 22 17:47:22 CEST 2008
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
> 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...
More information about the openmoko-kernel