Hi,

Nick Pelly wrote:
> On Wed, Nov 25, 2009 at 5:06 PM, Michael Trimarchi 
> <trimar...@gandalf.sssup.it <mailto:trimar...@gandalf.sssup.it>> wrote:
>
>     Hi,
>
>     Michael Trimarchi wrote:
>     > Hi all,
>     >
>     > I would like to know how android deal with the problem of data
>     buffering
>     > during mobile phone suspend.
>     > This is a scenario:
>     >
>     > linux start to suspend and no wakelock are acquired by any
>     subsystem and
>     > the application that read from
>     > the serial device is froozen, but the application does't know
>     exaclty
>     > when it will go to sleep so it can
>     > give this info to the gsm modem (rise up RTS). The modem is
>     connected to
>     > the serial and try to send data,
>     > linux buffer it but doesnt't give any info to the application.
>     It can be
>     > happen or there is somenthing
>     > wrong on this scenario?
>     >
>     > Michael
>     >
>     I have seen that the msn kernel serial driver acquire a wake lock
>     on rx path
>     but it is not clear how it force the gsm to start to buffering during
>     suspend.
>     If the gsm has hw flow control the driver must block the gsm to
>     trasmit
>     to the host
>     to avoid data lost. Is this correct?
>
>
> If you want to put the apps CPU to sleep (for example, 
> power-collapse-from-suspend, which is on the linux suspend path), and 
> continue to be ready to receive RX data over a uart, then you'll want 
> to keep the uart clocked on and make the uart irq a wakeup irq.
Before deactivate the clock on the suspend path you must stop the gsm to 
send info using the control line, so the gsm can start
to buffer, then you can deactivate the clock.  When the GSM has data it 
can send you and interrupt and wakeup. So using the
wakelock avoid half sms arrive in the tty buffer but control the line 
before suspend avoid data lost. Is this the idea?

Michael

-- 
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel

Reply via email to