?: Does the s3c2410 serial driver *really* work (suspend/resume)?

[Mike (mwester)]

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)