Re: [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Fri, May 07, 2010 at 04:41:02AM -0700, Arve Hjønnevåg wrote:
> 2010/5/7 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:

> > This goes back to the thing about a full system suspend being a
> > sledgehammer which doesn't give enough information about what's going
> > on when it's used like this.  As discussed we need a way to know that
> > the connections involved are able to stay live during suspend (on a
> > large proportion of systems suspend is going to mean that the relevant
> > bits of the board will loose power so need to be shut down) and that

> Are you trying to use the same driver on systems that can support
> audio while suspend and on systems where this is impossible? If audio

Yes, each chip in the audio subsystem gets its own device driver.  All
Linux systems using a given CODEC share the device specific driver code
(modulo out of tree code, obviously).  Further, the power management is
mostly abstracted out of the individual device drivers into the embedded
audio core so the individual drivers don't really take any decisions
about power for themselves.

> cannot work while suspended, supporting opportunistic suspend is easy.
> You block suspend while audio is active.

Right, but that's not really an interesting case here.

> If the hardware does support some audio paths while suspended, I'll
> ask again, is there a reason to turn them off on suspend?

As the mail you're replying to says:

> > that the intention of the user is that they should do so (this isn't
> > clear in the general system, especially not if the suspend is initiated
> > manually).

this all comes down to the intention of the user when they initiated the
suspend.

> > With a runtime PM approach this is trivial - we just turn off anything
> > that isn't in use at the current time.  I'll need to extend ASoC to add
> > information about what to do on suspend to the existing power data.

> OK, but is this at all related to opportunistic suspend?

Well, opportunistic suspend is essentially blurring the lines between a
suspend and runtime PM - it's using suspend as part of the automatic
drive down into the lowest possible power state.  I'm just saying that
in a pure runtime PM model this issue doesn't come up since the suspend
semantic is much clearer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/