Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1207988 > unrolled thread

Re: [PATCH V3 6/6] slim: qcom: Add runtime-pm support using clock-pause feature

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V3 6/6] slim: qcom: Add runtime-pm support using  clock-pause feature Mark Brown <broonie@kernel.org> - 2015-08-15 04:20 +0200

#1207988 — Re: [PATCH V3 6/6] slim: qcom: Add runtime-pm support using clock-pause feature

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 03, 2015 at 12:59:50AM -0600, Sagar Dharia wrote:

> +	if (cur_clk_state == SLIM_CLK_ENTERING_PAUSE) {
> +		if (txn->mc != SLIM_MSG_MC_BEGIN_RECONFIGURATION &&
> +		    txn->mc != SLIM_MSG_MC_RECONFIGURE_NOW &&
> +		    txn->mc != SLIM_MSG_MC_NEXT_PAUSE_CLOCK)
> +			return -EBUSY;
> +	} else {
> +		int ret = pm_runtime_get_sync(dev->dev);
> +
> +		if (ret < 0) {

This is taking a runtime PM reference whenever we're about to start a
transfer - this is the sort of thing I was talking about expecting the
framework to do rather than individual drivers.

> +			pm_runtime_set_suspended(dev->dev);
> +			dev_err(dev->dev, "runtime-pm vote failed:%d\n", ret);
> +			return ret;

If the get failed there should be no need to suspend the device, the
get() should leave us in a sensible state...

> +static int msm_slim_suspend(struct device *dev)
> +{
> +	int ret = 0;
> +
> +	if (!pm_runtime_enabled(dev) ||
> +		(!pm_runtime_suspended(dev))) {
> +		dev_dbg(dev, "system suspend");
> +		ret = msm_slim_runtime_suspend(dev);
> +	}
> +	if (ret == -EISCONN) {
> +		/**
> +		* If the clock pause failed due to active channels, there is
> +		* a possibility that some audio stream is active during suspend
> +		* We dont want to return suspend failure in that case so that
> +		* display and relevant components can still go to suspend.
> +		* If there is some other error, then it should prevent
> +		* system level suspend
> +		*/

Best mention that this is for the modem use case for Android's suspend
model since it's really surprising to see.

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web