aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/include/linux/soundwire
diff options
context:
space:
mode:
authorPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>2019-12-11 19:44:58 -0600
committerVinod Koul <vkoul@kernel.org>2019-12-12 09:17:06 +0530
commitfbbff36325079fd9d2fcd30063c84f4b38a0ad9b (patch)
treeb55ba06932c2ff2aa666af785e9cfa49cfdf820c /include/linux/soundwire
parentsoundwire: sdw_slave: add probe_complete structure and new fields (diff)
downloadwireguard-linux-fbbff36325079fd9d2fcd30063c84f4b38a0ad9b.tar.xz
wireguard-linux-fbbff36325079fd9d2fcd30063c84f4b38a0ad9b.zip
soundwire: sdw_slave: add enumeration_complete structure
When the Master starts the bus (be it during the initial boot or system resume), it usually performs a HardReset to make sure electrical levels are correct, then enables the control channel. While the PM framework guarantees that the Slave devices will only become 'active' once the Master completes the bus initialization, there is still a risk of a race condition: the Slave enumeration is handled in a separate interrupt thread triggered by hardware status changes, so the Slave device may not be ready to accept commands when the Slave driver tries to access the registers and restore settings in its resume or pm_runtime_resume callbacks. In those cases, any read/write commands from/to the Slave device will result in a timeout. This patch adds an enumeration_complete structure. When the bus is goes through a HardReset sequence and restarted, the Slave will be marked as UNATTACHED, which will result in a call to init_completion(). When the Slave reports its presence during PING frames as a non-zero Device, the Master hardware will issue an interrupt and the bus driver will invoke complete(). The order between init_completion()/complete() is predictable since this is a Master-initiated transition. The Slave driver may use wait_for_completion() in its resume callback. When regmap is used, the Slave driver will typically set its regmap in cache-only mode on suspend, then on resume block on wait_for_completion(&enumeration_complete) to guarantee it is safe to start read/write transactions. It may then exit the cache-only mode and use a regmap_sync to restore settings. All these steps are optional, their use completely depends on the Slave device capabilities and how the Slave driver is implemented. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191212014507.28050-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Diffstat (limited to 'include/linux/soundwire')
-rw-r--r--include/linux/soundwire/sdw.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index cb1db4a7475d..3fa8d875b16b 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -551,6 +551,9 @@ struct sdw_slave_ops {
* @probe_complete: completion utility to control potential races
* on startup between driver probe/initialization and SoundWire
* Slave state changes/implementation-defined interrupts
+ * @enumeration_complete: completion utility to control potential races
+ * on startup between device enumeration and read/write access to the
+ * Slave device
*/
struct sdw_slave {
struct sdw_slave_id id;
@@ -567,6 +570,7 @@ struct sdw_slave {
u16 dev_num;
bool probed;
struct completion probe_complete;
+ struct completion enumeration_complete;
};
#define dev_to_sdw_dev(_dev) container_of(_dev, struct sdw_slave, dev)