All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Vinod Koul <vkoul@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, broonie@kernel.org,
	bard.liao@intel.com, "Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 3/4] soundwire: intel: exit clock stop mode on system suspend
Date: Mon, 2 Aug 2021 11:28:54 -0500	[thread overview]
Message-ID: <2b7f632d-e8b2-7a14-54c6-86d19ca4ba01@linux.intel.com> (raw)
In-Reply-To: <792f70bd-b4ae-e3a1-c37e-ba2913018d0b@linux.intel.com>




>> 1. In above you are calling resume of child devices first and then intel
>> device, which sounds reverse, should you not resume intel device first
>> and then child (codec devices) ?
>>
>> 2. What about when resume is invoked by the core for the child devices.
>> That would be called in the PM resume flow, so why do it here?
> 
> I realize it's a complicated sequence, it took us multiple phases to get
> it right. There are multiple layers between power domain, bus and driver.
> 
> The .prepare phase happens before the system suspend phase. Unlike
> suspend, which progresses from children to parents, the .prepare is
> handled parent first.
> 
> When we do a request_resume of the child device, by construction that
> also resumes the parent. In other words, if we have multiple codecs on a
> link, the first iteration of device_for_each_child() will already resume
> the parent and the first device, and the second iteration will only
> resume the second device.
> 
> What this step does is make sure than when the codec .suspend routine is
> invoked, the entire bus is already back to full power. I did check
> privately with Rafael (CC:ed) if this sequence was legit.
> 
> We did consider modifying the system suspend callback in codec drivers,
> so that we would do a pm_runtime resume(). This is functionally
> equivalent to what we are suggesting here, but we decided not to do so
> for two main reasons
> 
> a) lots of code changes across all codecs for an Intel-specific issue
> 
> b) we would need to add a flag so that codec drivers would know in which
> Intel-specific clock-stop mode the bus was configured. That's not so
> good either.
> 
> It seemed simpler to use to add this .prepare step and test on the Intel
> clock stop mode before doing a pm_runtime_resume for all codecs.

Note that we could invert the two parts and do a parent resume first,
and a loop for all children second. It's completely equivalent, but
might be less convoluted to understand without any implicit behavior
assumed.

	if ((clock_stop_quirks & SDW_INTEL_CLK_STOP_BUS_RESET) ||
	    !clock_stop_quirks) {

		/* resume parent first */
		ret = pm_request_resume(dev);
		if (ret < 0)
			dev_err(dev, "%s: pm_request_resume failed: %d\n", __func__, ret);

		/*
		 * resume all children next.
		 * if there are no children on this link,
		 * this is a no-op
		 */
		ret = device_for_each_child(bus->dev, NULL, intel_resume_child_device);

		if (ret < 0)
			dev_err(dev, "%s: intel_resume_child_device failed: %d\n", __func__,
ret);
	}
	

  reply	other threads:[~2021-08-02 16:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27  5:56 [PATCH 0/4] soundwire: intel: exit clock-stop mode before system suspend Bard Liao
2021-07-27  5:56 ` [PATCH 1/4] soundwire: intel: fix potential race condition during power down Bard Liao
2021-07-27  5:56 ` [PATCH 2/4] soundwire: intel: skip suspend/resume/wake when link was not started Bard Liao
2021-08-02  4:02   ` Vinod Koul
2021-08-02 13:59     ` Pierre-Louis Bossart
2021-08-06 13:24       ` Vinod Koul
2021-08-06 15:57         ` Pierre-Louis Bossart
2021-07-27  5:56 ` [PATCH 3/4] soundwire: intel: exit clock stop mode on system suspend Bard Liao
2021-08-02  4:31   ` Vinod Koul
2021-08-02 14:24     ` Pierre-Louis Bossart
2021-08-02 16:28       ` Pierre-Louis Bossart [this message]
2021-08-06 13:31         ` Vinod Koul
2021-08-06 16:03           ` Pierre-Louis Bossart
2021-07-27  5:56 ` [PATCH 4/4] soundwire: intel: simplify pm_runtime handling in suspend/resume Bard Liao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b7f632d-e8b2-7a14-54c6-86d19ca4ba01@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=broonie@kernel.org \
    --cc=rafael@kernel.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    --cc=yung-chuan.liao@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.