backlight device, suspend/resume... / Suspend during calls

[Carsten Haitzler (The Rasterman)]

On Wed, 09 Jul 2008 13:48:14 +0100 Andy Green <andy at openmoko.com> babbled:

> | it's to solve a simple problem:
> |
> | 1. qpe is in the middle of a phone call
> | 2. e/illume dont know or care about this
> | 3. screenblank kicks in during call
> | 4. system suspends.. during call.
> |
> | now user can't hang up - no screen to interact with until they come out of
> | suspend. also audio and all sorts of gsm stuff gets broken if this
> happens, so
> | simply - we can't go suspending during calls. there would be other
> times we
> | can't suspend (eg during the time a voip client is active and
> making/receiving
> | calls or just waiting for incoming calls, etc. etc.), so there needs
> to be a
> | way to say "hey - block suspends for now until i say otherwise".
> 
> That blocking "veto" is a simple but fairly reliable way to come at it
> (although it might need some musing if the app crashes).  If you held
> open some magic dev node or somesuch while you wanted to stay up, that
> would be reaped cleanly on app exit by crash or exit.

yeah. right now on app crash the veto stays. i need to track the dbus client and
see if it loses its dbus connection. right now though anyone can remove a block
even if you are not the owner. it's meant to be simple so u can do this from
scripts using dbus-send so the dbus connection going away doesn't impact
anything. i know it has pitfalls, but for now am willing to live with them.

> But on the other issues, we discussed before a weaker "suspend", for the
> "zero clock" method any interrupt will bring back the CPU.  So GSM
> should be OK with such a thing, the touchscreen can wake (there is a
> "stylus down" interrupt that happens).  WLAN on listening socket wake is
> allegedly somehow supported by the module firmware.  So maybe that can
> fit in there somehow.

yeah. it'd be nice to have this. this would make so many things simpler, but
then we REALLY need userspace actively aware of power saving. apps need to have
voluntary power-save modes where they stop all polling activities they don't
absolutely need etc. and when we get there we need to actively be powering down
devices from userspace.

> Audio should not break on suspend.  PCM audio is woke via ALSA in a
> controlled way and I tested suspend and resume during live stream is OK.
> ~ If it is because the audio driver puts the chip to sleep on suspend and
> the analogue path is broken then, I don't know we can detect that the
> analogue path we use is in use from the audio driver side.  If we can
> detect that because we only bring up that path during a call, we can fix
> this behaviour easily.  If not, it is another candidate for your veto
> signal(s) to be visible to the kernel so it can adapt which devices are
> put to sleep in suspend.
> 
> Strong powersaving during call is just something it would be nice to add
> back to GTA02, but for any new designs it would be really good to have
> an answer for any problems.

yup. zero clock would solve this - and imho would be the best default power
saving mode we use - as long as all the other active powering down of devices
was working as well from userspace.

btw - how do you turn off touchscreen interrupts from userspace? i really want
to actually! :) i just want to disable the touchscreen (and re-enable it later
when needed).

> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkh0s4gACgkQOjLpvpq7dMqiBACfSaEQVaA6Eq9506n0Jm8JhYZv
> C28AmgIWxLNMUENB04CoYw3m0ek8EBEj
> =cUoR
> -----END PGP SIGNATURE-----


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>