[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191209235520.18727-5-pierre-louis.bossart@linux.intel.com>
Date: Mon, 9 Dec 2019 17:55:12 -0600
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: alsa-devel@...a-project.org
Cc: linux-kernel@...r.kernel.org, tiwai@...e.de, broonie@...nel.org,
vkoul@...nel.org, gregkh@...uxfoundation.org, jank@...ence.com,
srinivas.kandagatla@...aro.org, slawomir.blauciak@...el.com,
Bard liao <yung-chuan.liao@...ux.intel.com>,
Rander Wang <rander.wang@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Sanyog Kale <sanyog.r.kale@...el.com>
Subject: [PATCH v4 04/11] soundwire: sdw_slave: track unattach_request to handle all init sequences
The Slave device initialization can be split in 4 different cases:
1. Master-initiated hardware reset, system suspend-resume and
pm_runtime based on clock-stop mode1. To avoid timeouts and a bad
audio experience, the Slave device resume operations need to wait for
the Slave device to be re-enumerated and its settings restored.
2. Exit from clock-stop mode0. In this case, the Slave device is
required to remain enumerated and its context preserved while the
clock is stopped, so no re-initialization or wait_for_completion() is
necessary.
3. Slave-initiated pm_runtime D3 transition. With the parent child
relationship, it is possible that a Slave device becomes 'suspended'
while its parent is still 'active' with the bus clock still
toggling. In this case, during the pm_runtime resume operation, there
is no need to wait for any settings to be restored.
4. Slave reset (sync loss or implementation-defined). In that case the
bus remains operational and the Slave device will be re-initialized
when it becomes ATTACHED again.
In previous patches, we suggested the use of wait_for_completion() to
deal with the case #1, but case #2 and #3 do not need any wait.
To account for those differences, this patch adds an unattach_request
field. The field is explicitly set by the Master for the case #1, and
if non-zero the Slave device shall wait on resume. In all other cases,
the Slave resume operations can proceed without wait.
The only request tracked so far is Master HardReset, but the request
is declared as a bit mask for future extensions (if needed). The
definition for this value is added in bus.h and does not need to be
exposed in sdw.h
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
---
include/linux/soundwire/sdw.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index ed42cd79eab7..b7c9eca4332a 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -556,6 +556,11 @@ struct sdw_slave_ops {
* Slave device
* @initialization_complete: completion utility to control potential races
* on startup between device enumeration and settings being restored
+ * @unattach_request: mask field to keep track why the Slave re-attached and
+ * was re-initialized. This is useful to deal with potential race conditions
+ * between the Master suspending and the codec resuming, and make sure that
+ * when the Master triggered a reset the Slave is properly enumerated and
+ * initialized
*/
struct sdw_slave {
struct sdw_slave_id id;
@@ -574,6 +579,7 @@ struct sdw_slave {
struct completion probe_complete;
struct completion enumeration_complete;
struct completion initialization_complete;
+ u32 unattach_request;
};
#define dev_to_sdw_dev(_dev) container_of(_dev, struct sdw_slave, dev)
--
2.20.1
Powered by blists - more mailing lists