This particular question could use a little more discussion. I'm
interested to know, for example, under what conditions you would or
would not want to shut down an autonomous codec while going into system
suspend on a cell phone.
Clearly if there's a call in progress you don't want to shut the codec
down. Are there any other circumstances? Would they vary according to
whether the suspend was forced or opportunistic?
In short, I'm trying to get at how much information drivers _really_
need to have about the reason for a system suspend.
Yeah, ok. We probably do need to figure this out.
(Cc:ing Rebecca to see how this got handled on Droid)
The current state of affairs is that a system suspend request is
expected to put the device in as low a power state as possible given the
required wakeup events. Runtime power management is expected to put the
device in as low a power state as possible given its usage constraints.
If opportunistic suspend does the former then it'll tear down devices
that may be in use, but we don't have any real way to indicate usage
constraints other than the phone app taking a wakelock - and that means
leaving userspace running during calls, which seems excessive.
Mark's right in that the only case I can think of that's really relevant
right now is the audio hardware, so the inelegant solution is that this
is something that could be provided at the audio level. Is this
something we want a generic solution for? If so, what should it look
Matthew Garrett | email@example.com
Aside from things where the CODEC is acting as a wake source (for stuff
like jack detect) which are obviously already handled it's basically
just when you've got an external audio source flowing through the device
which is going to continue to function during suspend. Things like FM
radios, for example. I'm not aware of non-audio examples that are use
It's not exactly the *reason* that makes the difference, it's more that
this aggressive use of suspend makes much more apparent a problem which
might exist anyway for this sort of hardware.
When we get runtime PM delviering similar power levels we'll sidestep
the problem since we won't need to do a system wide suspend.