From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Ryan Lee <RyanS.Lee@maximintegrated.com>,
Mark Brown <broonie@kernel.org>
Cc: "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"perex@perex.cz" <perex@perex.cz>,
"tiwai@suse.com" <tiwai@suse.com>,
"yung-chuan.liao@linux.intel.com"
<yung-chuan.liao@linux.intel.com>,
"guennadi.liakhovetski@linux.intel.com"
<guennadi.liakhovetski@linux.intel.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"sathya.prakash.m.r@intel.com" <sathya.prakash.m.r@intel.com>,
"ryan.lee.maxim@gmail.com" <ryan.lee.maxim@gmail.com>
Subject: Re: [EXTERNAL] Re: [PATCH] ASoC: max98373: Mark cache dirty before entering sleep
Date: Thu, 30 Sep 2021 18:53:38 -0500 [thread overview]
Message-ID: <15dd3868-7023-67c2-991c-a0083f59f0b5@linux.intel.com> (raw)
In-Reply-To: <SJ0PR11MB5661A19958E5E41125FDD695E7AA9@SJ0PR11MB5661.namprd11.prod.outlook.com>
> I tried to find the reason why the amp was not detached from the bus properly and
> found information about CLOCK_STOP_NOW bit in 0x0044 SCP_Ctrl register.
> It seems like 0x2(ClockStopNow) needs to be configured before the host CLOCK STOP.
> I was able to get a good result if I add this command in the amp driver suspend function.
> The amp driver receives the detachment event and register restoration was done properly
> after the audio resume.
> I can modify the amp driver for this change but it looks like this needs to be done
> from the host side. May I have a comment on this? Thanks.
This register is already taken care of in drivers/soundwire/intel.c and
cadence_master.c
for pm_runtime suspend, the sequence uses sdw_cdns_clock_stop(), which
will try and prepare devices for clock-stop with a callback, in case any
imp-def registers is required, then it will call sdw_bus_clk_stop()
which does a broadcast write:
sdw_bus_clk_stop(struct sdw_bus *bus)
{
int ret;
/*
* broadcast clock stop now, attached Slaves will ACK this,
* unattached will ignore
*/
ret = sdw_bwrite_no_pm(bus, SDW_BROADCAST_DEV_NUM,
SDW_SCP_CTRL, SDW_SCP_CTRL_CLK_STP_NOW);
if (ret < 0) {
if (ret != -ENODATA)
dev_err(bus->dev, "ClockStopNow Broadcast msg failed %d\n", ret);
return ret;
}
The codec driver is not supposed to set this bit on its own, what this
indicates is that the clock will actually stop at the end of the frame.
Only the master/controller driver can transmit this - there's a very
strong reason why its a bus functionality.
The other point is that on pm_runtime resume, the Intel host will start
a SEVERE_RESET sequence. That's a bit different from the 'traditional'
description of the clock stop due to a power optimization on the Intel
side (see more below), but doing a reset has precedence over any other
configuration that might have happened before the clock stopped so the
amplifier SHALL transition to UNATTACHED on a reset.
Somehow it looks like the amplifiers don't see the clock stopped and
don't see the reset, that's rather surprising.
If this happens for system suspend/resume, then it's a different story:
we don't use the clock stop mode at all, the bus will be completely
reconfigured.
You could try to see if the results change by using the 'traditional'
clock stop mode with a kernel module parameters
option snd-sof-intel-hda-common sdw_clock_stop_quirks=0
the default is SDW_INTEL_CLK_STOP_BUS_RESET
/*
* Require a bus reset (and complete re-enumeration) when exiting
* clock stop modes. This may be needed if the controller power was
* turned off and all context lost. This quirk shall not be used if a
* Slave device needs to remain enumerated and keep its context,
* e.g. to provide the reasons for the wake, report acoustic events or
* pass a history buffer.
*/
#define SDW_INTEL_CLK_STOP_BUS_RESET BIT(3)
In this case, the bus will not be reset, I wonder if this is the part
that's problematic for the amplifier.
Hope this helps
-Pierre
prev parent reply other threads:[~2021-09-30 23:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 22:13 [PATCH] ASoC: max98373: Mark cache dirty before entering sleep Ryan Lee
2021-09-27 14:54 ` Pierre-Louis Bossart
2021-09-27 16:01 ` [EXTERNAL] " Ryan Lee
2021-09-27 16:06 ` Mark Brown
2021-09-27 16:48 ` Pierre-Louis Bossart
2021-09-27 17:10 ` Mark Brown
2021-09-27 17:23 ` Pierre-Louis Bossart
2021-09-27 17:29 ` Mark Brown
2021-09-28 16:43 ` Ryan Lee
2021-09-28 18:15 ` Pierre-Louis Bossart
2021-09-27 18:44 ` Ryan Lee
2021-09-27 19:34 ` Pierre-Louis Bossart
2021-09-27 22:43 ` Ryan Lee
2021-09-30 6:21 ` Ryan Lee
2021-09-30 13:29 ` Pierre-Louis Bossart
2021-09-30 23:31 ` Ryan Lee
2021-09-30 23:53 ` Pierre-Louis Bossart [this message]
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=15dd3868-7023-67c2-991c-a0083f59f0b5@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=RyanS.Lee@maximintegrated.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=guennadi.liakhovetski@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=ryan.lee.maxim@gmail.com \
--cc=sathya.prakash.m.r@intel.com \
--cc=tiwai@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox