alsa-devel.alsa-project.org archive mirror
 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: alsa-devel@alsa-project.org, tiwai@suse.de,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	ranjani.sridharan@linux.intel.com, hui.wang@canonical.com,
	broonie@kernel.org, srinivas.kandagatla@linaro.org,
	jank@cadence.com, mengdong.lin@intel.com,
	slawomir.blauciak@intel.com, sanyog.r.kale@intel.com,
	rander.wang@linux.intel.com, bard.liao@intel.com
Subject: Re: [PATCH 8/9] soundwire: intel: add wake interrupt support
Date: Tue, 30 Jun 2020 12:18:51 -0500	[thread overview]
Message-ID: <a69aa5d0-613a-6ef6-9263-378b1e99770a@linux.intel.com> (raw)
In-Reply-To: <20200630165126.GT2599@vkoul-mobl>



On 6/30/20 11:51 AM, Vinod Koul wrote:
> On 24-06-20, 01:35, Bard Liao wrote:
>> From: Rander Wang <rander.wang@intel.com>
>>
>> When system is suspended in clock stop mode on intel platforms, both
>> master and slave are in clock stop mode and soundwire bus is taken
>> over by a glue hardware. The bus message for jack event is processed
>> by this glue hardware, which will trigger an interrupt to resume audio
>> pci device. Then audio pci driver will resume soundwire master and slave,
>> transfer bus ownership to master, finally slave will report jack event
>> to master and codec driver is triggered to check jack status.
>>
>> if a slave has been attached to a bus, the slave->dev_num_sticky
>> should be non-zero, so we can check this value to skip the
>> ghost devices defined in ACPI table but not populated in hardware.
>>
>> Signed-off-by: Rander Wang <rander.wang@intel.com>
>> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
>> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
>> ---
>>   drivers/soundwire/intel.c      | 48 +++++++++++++++++++++++++++++++++-
>>   drivers/soundwire/intel.h      |  1 +
>>   drivers/soundwire/intel_init.c | 22 ++++++++++++++++
>>   3 files changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
>> index 06c553d94890..22d9fd3e34fa 100644
>> --- a/drivers/soundwire/intel.c
>> +++ b/drivers/soundwire/intel.c
>> @@ -13,6 +13,7 @@
>>   #include <linux/io.h>
>>   #include <linux/platform_device.h>
>>   #include <sound/pcm_params.h>
>> +#include <linux/pm_runtime.h>
>>   #include <sound/soc.h>
>>   #include <linux/soundwire/sdw_registers.h>
>>   #include <linux/soundwire/sdw.h>
>> @@ -436,7 +437,7 @@ static int intel_shim_init(struct sdw_intel *sdw, bool clock_stop)
>>   	return ret;
>>   }
>>   
>> -static void __maybe_unused intel_shim_wake(struct sdw_intel *sdw, bool wake_enable)
>> +static void intel_shim_wake(struct sdw_intel *sdw, bool wake_enable)
> 
> why drop __maybe?

the __maybe was used in previous patches to avoid throwing 'defined but 
not used' errors.

In this patch this function is actually used so there's no longer a 
reason to keep it.

>>   {
>>   	void __iomem *shim = sdw->link_res->shim;
>>   	unsigned int link_id = sdw->instance;
>> @@ -1337,6 +1338,51 @@ static int intel_master_remove(struct platform_device *pdev)
>>   	return 0;
>>   }
>>   
>> +int intel_master_process_wakeen_event(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct sdw_intel *sdw;
>> +	struct sdw_bus *bus;
>> +	struct sdw_slave *slave;
>> +	void __iomem *shim;
>> +	u16 wake_sts;
>> +
>> +	sdw = platform_get_drvdata(pdev);
>> +	bus = &sdw->cdns.bus;
>> +
>> +	if (bus->prop.hw_disabled) {
>> +		dev_dbg(dev,
>> +			"SoundWire master %d is disabled, ignoring\n",
>> +			bus->link_id);
> 
> single line pls

ok

>> +		return 0;
>> +	}
>> +
>> +	shim = sdw->link_res->shim;
>> +	wake_sts = intel_readw(shim, SDW_SHIM_WAKESTS);
>> +
>> +	if (!(wake_sts & BIT(sdw->instance)))
>> +		return 0;
>> +
>> +	/* disable WAKEEN interrupt ASAP to prevent interrupt flood */
>> +	intel_shim_wake(sdw, false);
> 
> when & where is this enabled?

in follow-up patches where the clock-stop mode is enabled.

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

		ret = sdw_cdns_clock_stop(cdns, true);
		if (ret < 0) {
			dev_err(dev, "cannot enable clock stop on suspend\n");
			return ret;
		}

		ret = sdw_cdns_enable_interrupt(cdns, false);
		if (ret < 0) {
			dev_err(dev, "cannot disable interrupts on suspend\n");
			return ret;
		}

		ret = intel_link_power_down(sdw);
		if (ret) {
			dev_err(dev, "Link power down failed: %d", ret);
			return ret;
		}

		intel_shim_wake(sdw, true);

>> +
>> +	/*
>> +	 * wake up master and slave so that slave can notify master
>> +	 * the wakeen event and let codec driver check codec status
>> +	 */
>> +	list_for_each_entry(slave, &bus->slaves, node) {
>> +		/*
>> +		 * discard devices that are defined in ACPI tables but
>> +		 * not physically present and devices that cannot
>> +		 * generate wakes
>> +		 */
>> +		if (slave->dev_num_sticky && slave->prop.wake_capable)
>> +			pm_request_resume(&slave->dev);
> 
> Hmmm, shouldn't slave do this? would it not make sense to notify the
> slave thru callback and then slave decides to resume or not..?

In this mode, the bus is clock-stop mode, and events are detected with 
level detector tied to PCI events. The master and slave devices are all 
in pm_runtime suspended states. The codec cannot make any decisions on 
its own since the bus is stopped, it needs to first resume, which 
assumes that the master resumes first and the enumeration re-done before 
it can access any of its registers.

By looping through the list of devices that can generate events, you 
end-up first forcing the master to resume, and then each slave resumes 
and can check who generated the event and what happened while suspended. 
if the codec didn't generate the event it will go back to suspended mode 
after the usual timeout.

We can add a callback but that callback would only be used for Intel 
solutions, but internally it would only do a pm_request_resume() since 
the codec cannot make any decisions before first resuming. In other 
words, it would be an Intel-specific callback that is implemented using 
generic resume operations. It's probably better to keep this in 
Intel-specific code, no?




  reply	other threads:[~2020-06-30 17:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 17:35 [PATCH 0/9] soundwire: intel: revisit SHIM programming Bard Liao
2020-06-23 17:35 ` [PATCH 1/9] soundwire: intel: reuse code for wait loops to set/clear bits Bard Liao
2020-06-23 17:35 ` [PATCH 2/9] soundwire: intel: revisit SHIM programming sequences Bard Liao
2020-06-23 17:35 ` [PATCH 3/9] soundwire: intel: introduce a helper to arm link synchronization Bard Liao
2020-06-23 17:35 ` [PATCH 4/9] soundwire: intel: introduce helper for " Bard Liao
2020-06-23 17:35 ` [PATCH 5/9] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Bard Liao
2020-06-23 17:35 ` [PATCH 6/9] soundwire: intel_init: use EXPORT_SYMBOL_NS Bard Liao
2020-06-23 17:35 ` [PATCH 7/9] soundwire: intel/cadence: merge Soundwire interrupt handlers/threads Bard Liao
2020-06-30 16:24   ` Vinod Koul
2020-06-30 16:46     ` Pierre-Louis Bossart
2020-07-01  5:42       ` Vinod Koul
2020-07-02  7:35         ` Liao, Bard
2020-07-02 15:01           ` Pierre-Louis Bossart
2020-07-15  4:54             ` Vinod Koul
2020-07-15 14:11               ` Pierre-Louis Bossart
2020-06-23 17:35 ` [PATCH 8/9] soundwire: intel: add wake interrupt support Bard Liao
2020-06-30 16:51   ` Vinod Koul
2020-06-30 17:18     ` Pierre-Louis Bossart [this message]
2020-07-01  5:56       ` Vinod Koul
2020-07-01 15:25         ` Pierre-Louis Bossart
2020-07-15  4:50           ` Vinod Koul
2020-07-15 14:22             ` Pierre-Louis Bossart
2020-06-23 17:35 ` [PATCH 9/9] Soundwire: intel_init: save Slave(s) _ADR info in sdw_intel_ctx 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=a69aa5d0-613a-6ef6-9263-378b1e99770a@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=gregkh@linuxfoundation.org \
    --cc=hui.wang@canonical.com \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mengdong.lin@intel.com \
    --cc=rander.wang@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=slawomir.blauciak@intel.com \
    --cc=srinivas.kandagatla@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).