[Gta04-owner] Rfkill devices needed before suspend?

[NeilBrown]

On Fri, 06 Apr 2012 09:34:40 +0200 Radek Polak <psonek2 at seznam.cz> wrote:

> On Friday, April 06, 2012 12:51:56 AM NeilBrown wrote:
> 
> > 'suspend' is really about stop processes, not powering down devices.
> > powering down devices just automatically happens when no-one is using them
> > - for some devices.  For other devices you need to be explicit.
> 
> Oki, thanks for explaing.
> 
> > Having said that: you don't actually need to 'rfkill block wifi'.
> > The wifi driver does power down on suspend unless you explicitly set up a
> > wake-on-wan configuration.
> > 
> > > And one more thing, sometimes the kernel suspends and the immediately
> > > resumes again. Dmesg shows this:
> > > 
> > > [ 1470.015624] Freezing user space processes ... (elapsed 0.01 seconds)
> > > done. [ 1470.036987] Freezing remaining freezable tasks ... (elapsed 0.02
> > > seconds) done.
> > > [ 1470.068481] Suspending console(s) (use no_console_suspend to debug)
> > > [ 1470.206787] td028ttec1_panel_suspend()
> > > [ 1470.220916] gta04_disable_lcd()
> > > [ 1470.221099] PM: suspend of devices complete after 145.568 msecs
> > > [ 1470.223205] PM: late suspend of devices complete after 2.075 msecs
> > > [ 1470.537078] Successfully put all powerdomains to target state
> > > [ 1470.542144] PM: early resume of devices complete after 4.943 msecs
> > > [ 1470.542938] td028ttec1_panel_resume()
> > > [ 1470.763366] gta04_enable_lcd()
> > > [ 1471.591735] PM: resume of devices complete after 1049.438 msecs
> > > [ 1471.637786] Restarting tasks ... done.
> > > [ 1491.989135] PM: Syncing filesystems ... done.
> > > 
> > > Any idea what is waking it up? Unfortunately it's not easily
> > > reproducible... Reboot fixes it.
> > 
> > I have seen this happen on one-off occasions a number of time.
> > i.e. it fails to suspend but then when it tries again it succeeds.
> > My device is configured to immediately suspend whenever there is no event or
> > action keeping it awake so I do even notice the "fail then succeed" unless
> > I am watching.
> 
> That must be different problem then. I cant suspend repeatedly. Only reboot 
> solves this.
> 
> > The only times I have seen it happen repeatedly is when the GPS is still on
> > and so repeatedly generating wakeup events.
> > Have you checked that GPS is definitely off when this happens?
> 
> I will try next time it happens. But it must have somehow turned on 
> automatically then. IIRC it happens like this:
> 
> Boot the device, rfkill block bluetooth wifi gps, suspend. After some time wake 
> it up, make a call and then it fails to suspend.

I wonder if using the "sound card" left something in a strange state.
You check that the voice routing program was really dead.
And 
   grep McBSP /proc/interrupts

to see if the audio-path interrupts are still registered.

Another vague possibility is the battery charger.  It is sometimes a source
of strange interrupts.
If you
  echo file twl4030_charger.c +p > /sys/kernel/debug/dynamic_debug/control

then you will debug messages whenever a BCI interrupt happens.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120406/18d71954/attachment.bin>