[alsa-devel] [PATCH v4 0/7] soundwire: Add multi link support
Currently, in the SoundWire subsystem, the concept of stream is limited to a Master and one or more Slaves(Codecs). This series aims to add support for multiple Master(s) sharing the same reference clock and synchronized in the hardware.
This patch series adds: - Helpers to lock bus instances part of the stream - Boiler plate conversion of code to support a list of Master runtime - Support multi link bank switch to support synchronization between multiple masters - Add Intel platform ops for pre/post bank switch
changes in v4: - Added changes in sdw_stream_runtime structure to track Masters added to stream - Add changes to support ml_bankswitch only if both the hardware supports and the stream is handled by multiple masters
changes in v3: - Added comments to explain the trigger for multi link bank switch - Added comments in the intel_post_bank_switch ops to explain how synchronous trigger of bank switch is handled.
Sanyog Kale (2): Documentation: soundwire: Add documentation for multi link soundwire: Add support to lock across bus instances
Shreyas NC (4): soundwire: Initialize completion for defer messages soundwire: keep track of Masters in a stream soundwire: Add support for multi link bank switch soundwire: intel: Add pre/post bank switch ops
Vinod Koul (1): soundwire: Handle multiple master instances in a stream
Documentation/driver-api/soundwire/stream.rst | 28 ++ drivers/soundwire/bus.c | 6 + drivers/soundwire/bus.h | 4 + drivers/soundwire/intel.c | 65 ++++ drivers/soundwire/stream.c | 483 +++++++++++++++++++------- include/linux/soundwire/sdw.h | 12 +- 6 files changed, 467 insertions(+), 131 deletions(-)
From: Sanyog Kale sanyog.r.kale@intel.com
Add example and documentation to describe multi link streams
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com --- Documentation/driver-api/soundwire/stream.rst | 28 +++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index 29121aa..19482ee 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -101,6 +101,34 @@ interface. :: +--------------------+ | | +----------------+
+Example 5: Stereo Stream with L and R channel is rendered by 2 Masters, each +rendering one channel, and is received by two different Slaves, each +receiving one channel. Both Masters and both Slaves are using single port. :: + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 1 | | 1 | + | | Data Signal | | + | L +----------------------------------+ L | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 2 | | 2 | + | | Data Signal | | + | R +----------------------------------+ R | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + +Note: In multi-link cases like above, to lock, one would acquire a global +lock and then go on locking bus instances. But, in this case the caller +framework(ASoC DPCM) guarantees that stream operations on a card are +always serialized. So, there is no race condition and hence no need for +global lock. + SoundWire Stream Management flow ================================
Deferred messages are async messages used to synchronize transitions mostly while doing a bank switch on multi links. On successful transitions these messages are marked complete and thereby confirming that all the buses performed bank switch successfully.
So, initialize the completion structure for the same.
Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com --- drivers/soundwire/bus.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index dcc0ff9..dbabd5e 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -175,6 +175,7 @@ static inline int do_transfer_defer(struct sdw_bus *bus,
defer->msg = msg; defer->length = msg->len; + init_completion(&defer->complete);
for (i = 0; i <= retry; i++) { resp = bus->ops->xfer_msg_defer(bus, msg, defer);
From: Sanyog Kale sanyog.r.kale@intel.com
Currently, the stream concept is limited to single Master and one or more Codecs.
This patch extends the concept to support multiple Master(s) sharing the same reference clock and synchronized in the hardware. Modify sdw_stream_runtime to support a list of sdw_master_runtime for the same. The existing reference to a single m_rt is removed in the next patch.
Typically to lock, one would acquire a global lock and then lock bus instances. In this case, the caller framework(ASoC DPCM) guarantees that stream operations on a card are always serialized. So, there is no race condition and hence no need for global lock.
Bus lock(s) are acquired to reconfigure the bus while the stream is set-up. So, we add sdw_acquire_bus_lock()/sdw_release_bus_lock() APIs which are used only to reconfigure the bus.
Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com --- drivers/soundwire/bus.h | 2 ++ drivers/soundwire/stream.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/soundwire/sdw.h | 4 ++++ 3 files changed, 47 insertions(+)
diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h index 3b15c4e..b6cfbdf 100644 --- a/drivers/soundwire/bus.h +++ b/drivers/soundwire/bus.h @@ -99,6 +99,7 @@ struct sdw_slave_runtime { * this stream, can be zero. * @slave_rt_list: Slave runtime list * @port_list: List of Master Ports configured for this stream, can be zero. + * @stream_node: sdw_stream_runtime master_list node * @bus_node: sdw_bus m_rt_list node */ struct sdw_master_runtime { @@ -108,6 +109,7 @@ struct sdw_master_runtime { unsigned int ch_count; struct list_head slave_rt_list; struct list_head port_list; + struct list_head stream_node; struct list_head bus_node; };
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 8974a0f..eb942c6 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -747,6 +747,7 @@ struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name) return NULL;
stream->name = stream_name; + INIT_LIST_HEAD(&stream->master_list); stream->state = SDW_STREAM_ALLOCATED;
return stream; @@ -1234,6 +1235,46 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, return NULL; }
+/** + * sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s) + * + * @stream: SoundWire stream + * + * Acquire bus_lock for each of the master runtime(m_rt) part of this + * stream to reconfigure the bus. + */ +static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{ + struct sdw_master_runtime *m_rt = NULL; + struct sdw_bus *bus = NULL; + + /* Iterate for all Master(s) in Master list */ + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + + mutex_lock(&bus->bus_lock); + } +} + +/** + * sdw_release_bus_lock: Release bus lock for all Master runtime(s) + * + * @stream: SoundWire stream + * + * Release the previously held bus_lock after reconfiguring the bus. + */ +static void sdw_release_bus_lock(struct sdw_stream_runtime *stream) +{ + struct sdw_master_runtime *m_rt = NULL; + struct sdw_bus *bus = NULL; + + /* Iterate for all Master(s) in Master list */ + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + mutex_unlock(&bus->bus_lock); + } +} + static int _sdw_prepare_stream(struct sdw_stream_runtime *stream) { struct sdw_master_runtime *m_rt = stream->m_rt; diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index 962971e..ccd8dcdf 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -769,6 +769,9 @@ struct sdw_stream_params { * @state: Current state of the stream * @type: Stream type PCM or PDM * @m_rt: Master runtime + * @master_list: List of Master runtime(s) in this stream. + * master_list can contain only one m_rt per Master instance + * for a stream */ struct sdw_stream_runtime { char *name; @@ -776,6 +779,7 @@ struct sdw_stream_runtime { enum sdw_stream_state state; enum sdw_stream_type type; struct sdw_master_runtime *m_rt; + struct list_head master_list; };
struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name);
On Mon, 25 Jun 2018 12:58:56 +0200, Shreyas NC wrote:
From: Sanyog Kale sanyog.r.kale@intel.com
Currently, the stream concept is limited to single Master and one or more Codecs.
This patch extends the concept to support multiple Master(s) sharing the same reference clock and synchronized in the hardware. Modify sdw_stream_runtime to support a list of sdw_master_runtime for the same. The existing reference to a single m_rt is removed in the next patch.
Typically to lock, one would acquire a global lock and then lock bus instances. In this case, the caller framework(ASoC DPCM) guarantees that stream operations on a card are always serialized. So, there is no race condition and hence no need for global lock.
Bus lock(s) are acquired to reconfigure the bus while the stream is set-up. So, we add sdw_acquire_bus_lock()/sdw_release_bus_lock() APIs which are used only to reconfigure the bus.
Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com
drivers/soundwire/bus.h | 2 ++ drivers/soundwire/stream.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/soundwire/sdw.h | 4 ++++ 3 files changed, 47 insertions(+)
diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h index 3b15c4e..b6cfbdf 100644 --- a/drivers/soundwire/bus.h +++ b/drivers/soundwire/bus.h @@ -99,6 +99,7 @@ struct sdw_slave_runtime {
- this stream, can be zero.
- @slave_rt_list: Slave runtime list
- @port_list: List of Master Ports configured for this stream, can be zero.
*/
- @stream_node: sdw_stream_runtime master_list node
- @bus_node: sdw_bus m_rt_list node
struct sdw_master_runtime { @@ -108,6 +109,7 @@ struct sdw_master_runtime { unsigned int ch_count; struct list_head slave_rt_list; struct list_head port_list;
- struct list_head stream_node; struct list_head bus_node;
};
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 8974a0f..eb942c6 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -747,6 +747,7 @@ struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name) return NULL;
stream->name = stream_name;
INIT_LIST_HEAD(&stream->master_list); stream->state = SDW_STREAM_ALLOCATED;
return stream;
@@ -1234,6 +1235,46 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, return NULL; }
+/**
- sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Acquire bus_lock for each of the master runtime(m_rt) part of this
- stream to reconfigure the bus.
- */
+static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_lock(&bus->bus_lock);- }
+}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
+/**
- sdw_release_bus_lock: Release bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Release the previously held bus_lock after reconfiguring the bus.
- */
+static void sdw_release_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_unlock(&bus->bus_lock);- }
... and this looks bad. The loop for unlocking should be traversed reversely.
thanks,
Takashi
+/**
- sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Acquire bus_lock for each of the master runtime(m_rt) part of this
- stream to reconfigure the bus.
- */
+static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_lock(&bus->bus_lock);- }
+}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
+/**
- sdw_release_bus_lock: Release bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Release the previously held bus_lock after reconfiguring the bus.
- */
+static void sdw_release_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_unlock(&bus->bus_lock);- }
... and this looks bad. The loop for unlocking should be traversed reversely.
Yes in principle I agree locking should be in reverse, but as explained above in this case, it does not matter much :)
--Shreyas
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote:
+/**
- sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Acquire bus_lock for each of the master runtime(m_rt) part of this
- stream to reconfigure the bus.
- */
+static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_lock(&bus->bus_lock);- }
+}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
+/**
- sdw_release_bus_lock: Release bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Release the previously held bus_lock after reconfiguring the bus.
- */
+static void sdw_release_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_unlock(&bus->bus_lock);- }
... and this looks bad. The loop for unlocking should be traversed reversely.
Yes in principle I agree locking should be in reverse, but as explained above in this case, it does not matter much :)
It does matter when you dealing with the multiple nested mutexes...
thanks,
Takashi
On Tue, Jun 26, 2018 at 10:34:17AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote:
+/**
- sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Acquire bus_lock for each of the master runtime(m_rt) part of this
- stream to reconfigure the bus.
- */
+static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_lock(&bus->bus_lock);- }
+}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
Ok, myy bad, I misunderstood the comment :(
I forgot to add that I did check with mutex debug enabled and lockdep did not complain though :)
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
These are called from PCM stream ops context and the DPCM holds lock(fe->card->mutex) which serializes these operations. So, in the scenario you have mentioned, we would not have concurrent calls to this function.
+/**
- sdw_release_bus_lock: Release bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Release the previously held bus_lock after reconfiguring the bus.
- */
+static void sdw_release_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_unlock(&bus->bus_lock);- }
... and this looks bad. The loop for unlocking should be traversed reversely.
Yes in principle I agree locking should be in reverse, but as explained above in this case, it does not matter much :)
It does matter when you dealing with the multiple nested mutexes...
Ok
--Shreyas
--
On Tue, 26 Jun 2018 11:23:59 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 10:34:17AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote:
+/**
- sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Acquire bus_lock for each of the master runtime(m_rt) part of this
- stream to reconfigure the bus.
- */
+static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_lock(&bus->bus_lock);- }
+}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
Ok, myy bad, I misunderstood the comment :(
I forgot to add that I did check with mutex debug enabled and lockdep did not complain though :)
You didn't test the actual concurrent calls because of FE's mutex below, right?
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
These are called from PCM stream ops context and the DPCM holds lock(fe->card->mutex) which serializes these operations. So, in the scenario you have mentioned, we would not have concurrent calls to this function.
The implementation of soundwire bus is basically independent from ASoC or whatever else. That is, any other drivers may use this API, and it'll be busted.
Takashi
On Tue, Jun 26, 2018 at 11:46:35AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 11:23:59 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 10:34:17AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote:
+/**
- sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s)
- @stream: SoundWire stream
- Acquire bus_lock for each of the master runtime(m_rt) part of this
- stream to reconfigure the bus.
- */
+static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) +{
- struct sdw_master_runtime *m_rt = NULL;
- struct sdw_bus *bus = NULL;
- /* Iterate for all Master(s) in Master list */
- list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;mutex_lock(&bus->bus_lock);- }
+}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
Ok, myy bad, I misunderstood the comment :(
I forgot to add that I did check with mutex debug enabled and lockdep did not complain though :)
You didn't test the actual concurrent calls because of FE's mutex below, right?
Yes
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
These are called from PCM stream ops context and the DPCM holds lock(fe->card->mutex) which serializes these operations. So, in the scenario you have mentioned, we would not have concurrent calls to this function.
The implementation of soundwire bus is basically independent from ASoC or whatever else. That is, any other drivers may use this API, and it'll be busted.
Hmmh, yes. The only way we could think of to protect this is to use a global lock which we wanted to avoid. We did give this a thought and since today no other subsytem can use this, we went ahead with the way it is today. Any suggestions on how to go about this ?
--Shreyas --
On Tue, 26 Jun 2018 11:59:32 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 11:46:35AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 11:23:59 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 10:34:17AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote:
> +/** > + * sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s) > + * > + * @stream: SoundWire stream > + * > + * Acquire bus_lock for each of the master runtime(m_rt) part of this > + * stream to reconfigure the bus. > + */ > +static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) > +{ > + struct sdw_master_runtime *m_rt = NULL; > + struct sdw_bus *bus = NULL; > + > + /* Iterate for all Master(s) in Master list */ > + list_for_each_entry(m_rt, &stream->master_list, stream_node) { > + bus = m_rt->bus; > + > + mutex_lock(&bus->bus_lock); > + } > +}
So it's nested locks? Then you'd need some more trick to deal with the lockdep. I guess you'll get the false-positive deadlock detection by this code when the mutex lock debug is enabled.
Also, is the linked order assured not to lead to a real deadlock?
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
Ok, myy bad, I misunderstood the comment :(
I forgot to add that I did check with mutex debug enabled and lockdep did not complain though :)
You didn't test the actual concurrent calls because of FE's mutex below, right?
Yes
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
These are called from PCM stream ops context and the DPCM holds lock(fe->card->mutex) which serializes these operations. So, in the scenario you have mentioned, we would not have concurrent calls to this function.
The implementation of soundwire bus is basically independent from ASoC or whatever else. That is, any other drivers may use this API, and it'll be busted.
Hmmh, yes. The only way we could think of to protect this is to use a global lock which we wanted to avoid. We did give this a thought and since today no other subsytem can use this, we went ahead with the way it is today. Any suggestions on how to go about this ?
If so, you have to give an explicit big fat warning for the usage in the function description.
Takashi
On Tue, Jun 26, 2018 at 12:16:42PM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 11:59:32 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 11:46:35AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 11:23:59 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 10:34:17AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote:
> > +/** > > + * sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s) > > + * > > + * @stream: SoundWire stream > > + * > > + * Acquire bus_lock for each of the master runtime(m_rt) part of this > > + * stream to reconfigure the bus. > > + */ > > +static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) > > +{ > > + struct sdw_master_runtime *m_rt = NULL; > > + struct sdw_bus *bus = NULL; > > + > > + /* Iterate for all Master(s) in Master list */ > > + list_for_each_entry(m_rt, &stream->master_list, stream_node) { > > + bus = m_rt->bus; > > + > > + mutex_lock(&bus->bus_lock); > > + } > > +} > > So it's nested locks? Then you'd need some more trick to deal with > the lockdep. I guess you'll get the false-positive deadlock detection > by this code when the mutex lock debug is enabled. > > Also, is the linked order assured not to lead to a real deadlock? >
Hi Takashi,
Thanks for the review :)
A multi link SoundWire stream consists of a list of Master runtimes and more importantly only one master runtime per SoundWire bus instance.
So, these mutexes are actually different mutex locks(one per bus instance) and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
Ok, myy bad, I misunderstood the comment :(
I forgot to add that I did check with mutex debug enabled and lockdep did not complain though :)
You didn't test the actual concurrent calls because of FE's mutex below, right?
Yes
In SDW we have a bus instance per Master (link). In multi-link case, a stream may have multiple Masters, thus we need to lock all bus instances before we operate on them.
Now since these are invoked from a stream (pcm ops) they will be always serialized and DPCM ensures we are never racing.
We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
These are called from PCM stream ops context and the DPCM holds lock(fe->card->mutex) which serializes these operations. So, in the scenario you have mentioned, we would not have concurrent calls to this function.
The implementation of soundwire bus is basically independent from ASoC or whatever else. That is, any other drivers may use this API, and it'll be busted.
Hmmh, yes. The only way we could think of to protect this is to use a global lock which we wanted to avoid. We did give this a thought and since today no other subsytem can use this, we went ahead with the way it is today. Any suggestions on how to go about this ?
If so, you have to give an explicit big fat warning for the usage in the function description.
Ok, I had added it in the commit log and documentation. It does make sense to add it in the function description.
Thanks!
--Shreyas --
On Tue, 26 Jun 2018 12:22:01 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 12:16:42PM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 11:59:32 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 11:46:35AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 11:23:59 +0200, Shreyas NC wrote:
On Tue, Jun 26, 2018 at 10:34:17AM +0200, Takashi Iwai wrote:
On Tue, 26 Jun 2018 10:22:01 +0200, Shreyas NC wrote: > > > > +/** > > > + * sdw_acquire_bus_lock: Acquire bus lock for all Master runtime(s) > > > + * > > > + * @stream: SoundWire stream > > > + * > > > + * Acquire bus_lock for each of the master runtime(m_rt) part of this > > > + * stream to reconfigure the bus. > > > + */ > > > +static void sdw_acquire_bus_lock(struct sdw_stream_runtime *stream) > > > +{ > > > + struct sdw_master_runtime *m_rt = NULL; > > > + struct sdw_bus *bus = NULL; > > > + > > > + /* Iterate for all Master(s) in Master list */ > > > + list_for_each_entry(m_rt, &stream->master_list, stream_node) { > > > + bus = m_rt->bus; > > > + > > > + mutex_lock(&bus->bus_lock); > > > + } > > > +} > > > > So it's nested locks? Then you'd need some more trick to deal with > > the lockdep. I guess you'll get the false-positive deadlock detection > > by this code when the mutex lock debug is enabled. > > > > Also, is the linked order assured not to lead to a real deadlock? > > > > Hi Takashi, > > Thanks for the review :) > > A multi link SoundWire stream consists of a list of Master runtimes and > more importantly only one master runtime per SoundWire bus instance. > > So, these mutexes are actually different mutex locks(one per bus instance) > and are not nested.
You take a mutex lock inside a mutex lock, so they are nested. If they take the very same lock, it's called a "deadlock" instead.
Ok, myy bad, I misunderstood the comment :(
I forgot to add that I did check with mutex debug enabled and lockdep did not complain though :)
You didn't test the actual concurrent calls because of FE's mutex below, right?
Yes
> In SDW we have a bus instance per Master (link). In multi-link case, a > stream may have multiple Masters, thus we need to lock all bus instances > before we operate on them. > > Now since these are invoked from a stream (pcm ops) they will be always > serialized and DPCM ensures we are never racing. > > We did add this note here and in Documentation to make it explicit.
Well, my question is whether the order to take the multiple locks is always assured. You're calling like:
list_for_each_entry(m_rt, &stream->master_list, stream_node) mutex_lock();
And it's a linked-list. If a stream has a link of masters like M1->M2->M3 while another stream has a link like M2->M1->M3, it'll lead to a deadlock with the concurrent calls above.
These are called from PCM stream ops context and the DPCM holds lock(fe->card->mutex) which serializes these operations. So, in the scenario you have mentioned, we would not have concurrent calls to this function.
The implementation of soundwire bus is basically independent from ASoC or whatever else. That is, any other drivers may use this API, and it'll be busted.
Hmmh, yes. The only way we could think of to protect this is to use a global lock which we wanted to avoid. We did give this a thought and since today no other subsytem can use this, we went ahead with the way it is today. Any suggestions on how to go about this ?
If so, you have to give an explicit big fat warning for the usage in the function description.
Ok, I had added it in the commit log and documentation. It does make sense to add it in the function description.
Yes. It needs a clear sign showing that the concurrency has to be resolved in the caller side.
Takashi
From: Vinod Koul vkoul@kernel.org
For each SoundWire stream operation, we need to parse master list and operate upon all master runtime.
This is a preparatory patch to do the boilerplate conversion of stream handling from single master runtime to handle a list of master runtime. The code to support bank switch for multiple master instances is added in the next patch.
Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com --- drivers/soundwire/stream.c | 309 +++++++++++++++++++++++++----------------- include/linux/soundwire/sdw.h | 2 - 2 files changed, 186 insertions(+), 125 deletions(-)
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index eb942c6..0e8a2eb5 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -681,35 +681,45 @@ static int sdw_bank_switch(struct sdw_bus *bus)
static int do_bank_switch(struct sdw_stream_runtime *stream) { - struct sdw_master_runtime *m_rt = stream->m_rt; + struct sdw_master_runtime *m_rt = NULL; const struct sdw_master_ops *ops; - struct sdw_bus *bus = m_rt->bus; + struct sdw_bus *bus = NULL; int ret = 0;
- ops = bus->ops;
- /* Pre-bank switch */ - if (ops->pre_bank_switch) { - ret = ops->pre_bank_switch(bus); + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + ops = bus->ops; + + /* Pre-bank switch */ + if (ops->pre_bank_switch) { + ret = ops->pre_bank_switch(bus); + if (ret < 0) { + dev_err(bus->dev, + "Pre bank switch op failed: %d", ret); + return ret; + } + } + + /* Bank switch */ + ret = sdw_bank_switch(bus); if (ret < 0) { - dev_err(bus->dev, "Pre bank switch op failed: %d", ret); + dev_err(bus->dev, "Bank switch failed: %d", ret); return ret; } }
- /* Bank switch */ - ret = sdw_bank_switch(bus); - if (ret < 0) { - dev_err(bus->dev, "Bank switch failed: %d", ret); - return ret; - } + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + ops = bus->ops;
- /* Post-bank switch */ - if (ops->post_bank_switch) { - ret = ops->post_bank_switch(bus); - if (ret < 0) { - dev_err(bus->dev, + /* Post-bank switch */ + if (ops->post_bank_switch) { + ret = ops->post_bank_switch(bus); + if (ret < 0) { + dev_err(bus->dev, "Post bank switch op failed: %d", ret); + } } }
@@ -754,6 +764,21 @@ struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name) } EXPORT_SYMBOL(sdw_alloc_stream);
+static struct sdw_master_runtime +*sdw_find_master_rt(struct sdw_bus *bus, + struct sdw_stream_runtime *stream) +{ + struct sdw_master_runtime *m_rt = NULL; + + /* Retrieve Bus handle if already available */ + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + if (m_rt->bus == bus) + return m_rt; + } + + return NULL; +} + /** * sdw_alloc_master_rt() - Allocates and initialize Master runtime handle * @@ -770,12 +795,11 @@ static struct sdw_master_runtime { struct sdw_master_runtime *m_rt;
- m_rt = stream->m_rt; - /* * check if Master is already allocated (as a result of Slave adding * it first), if so skip allocation and go to configure */ + m_rt = sdw_find_master_rt(bus, stream); if (m_rt) goto stream_config;
@@ -786,7 +810,7 @@ static struct sdw_master_runtime /* Initialization of Master runtime handle */ INIT_LIST_HEAD(&m_rt->port_list); INIT_LIST_HEAD(&m_rt->slave_rt_list); - stream->m_rt = m_rt; + list_add_tail(&m_rt->stream_node, &stream->master_list);
list_add_tail(&m_rt->bus_node, &bus->m_rt_list);
@@ -844,17 +868,21 @@ static void sdw_slave_port_release(struct sdw_bus *bus, struct sdw_stream_runtime *stream) { struct sdw_port_runtime *p_rt, *_p_rt; - struct sdw_master_runtime *m_rt = stream->m_rt; + struct sdw_master_runtime *m_rt; struct sdw_slave_runtime *s_rt;
- list_for_each_entry(s_rt, &m_rt->slave_rt_list, m_rt_node) { - if (s_rt->slave != slave) - continue; + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + list_for_each_entry(s_rt, &m_rt->slave_rt_list, m_rt_node) {
- list_for_each_entry_safe(p_rt, _p_rt, - &s_rt->port_list, port_node) { - list_del(&p_rt->port_node); - kfree(p_rt); + if (s_rt->slave != slave) + continue; + + list_for_each_entry_safe(p_rt, _p_rt, + &s_rt->port_list, port_node) { + + list_del(&p_rt->port_node); + kfree(p_rt); + } } } } @@ -871,16 +899,18 @@ static void sdw_release_slave_stream(struct sdw_slave *slave, struct sdw_stream_runtime *stream) { struct sdw_slave_runtime *s_rt, *_s_rt; - struct sdw_master_runtime *m_rt = stream->m_rt; - - /* Retrieve Slave runtime handle */ - list_for_each_entry_safe(s_rt, _s_rt, - &m_rt->slave_rt_list, m_rt_node) { + struct sdw_master_runtime *m_rt;
- if (s_rt->slave == slave) { - list_del(&s_rt->m_rt_node); - kfree(s_rt); - return; + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + /* Retrieve Slave runtime handle */ + list_for_each_entry_safe(s_rt, _s_rt, + &m_rt->slave_rt_list, m_rt_node) { + + if (s_rt->slave == slave) { + list_del(&s_rt->m_rt_node); + kfree(s_rt); + return; + } } } } @@ -888,6 +918,7 @@ static void sdw_release_slave_stream(struct sdw_slave *slave, /** * sdw_release_master_stream() - Free Master runtime handle * + * @m_rt: Master runtime node * @stream: Stream runtime handle. * * This function is to be called with bus_lock held @@ -895,16 +926,18 @@ static void sdw_release_slave_stream(struct sdw_slave *slave, * handle. If this is called first then sdw_release_slave_stream() will have * no effect as Slave(s) runtime handle would already be freed up. */ -static void sdw_release_master_stream(struct sdw_stream_runtime *stream) +static void sdw_release_master_stream(struct sdw_master_runtime *m_rt, + struct sdw_stream_runtime *stream) { - struct sdw_master_runtime *m_rt = stream->m_rt; struct sdw_slave_runtime *s_rt, *_s_rt;
list_for_each_entry_safe(s_rt, _s_rt, &m_rt->slave_rt_list, m_rt_node) sdw_stream_remove_slave(s_rt->slave, stream);
+ list_del(&m_rt->stream_node); list_del(&m_rt->bus_node); + kfree(m_rt); }
/** @@ -918,13 +951,22 @@ static void sdw_release_master_stream(struct sdw_stream_runtime *stream) int sdw_stream_remove_master(struct sdw_bus *bus, struct sdw_stream_runtime *stream) { + struct sdw_master_runtime *m_rt, *_m_rt; + mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream); - sdw_master_port_release(bus, stream->m_rt); - stream->state = SDW_STREAM_RELEASED; - kfree(stream->m_rt); - stream->m_rt = NULL; + list_for_each_entry_safe(m_rt, _m_rt, + &stream->master_list, stream_node) { + + if (m_rt->bus != bus) + continue; + + sdw_master_port_release(bus, m_rt); + sdw_release_master_stream(m_rt, stream); + } + + if (list_empty(&stream->master_list)) + stream->state = SDW_STREAM_RELEASED;
mutex_unlock(&bus->bus_lock);
@@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus *bus, stream->state = SDW_STREAM_CONFIGURED;
stream_error: - sdw_release_master_stream(stream); + sdw_release_master_stream(m_rt, stream); error: mutex_unlock(&bus->bus_lock); return ret; @@ -1195,7 +1237,7 @@ int sdw_stream_add_slave(struct sdw_slave *slave, * we hit error so cleanup the stream, release all Slave(s) and * Master runtime */ - sdw_release_master_stream(stream); + sdw_release_master_stream(m_rt, stream); error: mutex_unlock(&slave->bus->bus_lock); return ret; @@ -1277,31 +1319,36 @@ static void sdw_release_bus_lock(struct sdw_stream_runtime *stream)
static int _sdw_prepare_stream(struct sdw_stream_runtime *stream) { - struct sdw_master_runtime *m_rt = stream->m_rt; - struct sdw_bus *bus = m_rt->bus; + struct sdw_master_runtime *m_rt = NULL; + struct sdw_bus *bus = NULL; struct sdw_master_prop *prop = NULL; struct sdw_bus_params params; int ret;
- prop = &bus->prop; - memcpy(¶ms, &bus->params, sizeof(params)); + /* Prepare Master(s) and Slave(s) port(s) associated with stream */ + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + prop = &bus->prop; + memcpy(¶ms, &bus->params, sizeof(params));
- /* TODO: Support Asynchronous mode */ - if ((prop->max_freq % stream->params.rate) != 0) { - dev_err(bus->dev, "Async mode not supported"); - return -EINVAL; - } + /* TODO: Support Asynchronous mode */ + if ((prop->max_freq % stream->params.rate) != 0) { + dev_err(bus->dev, "Async mode not supported"); + return -EINVAL; + }
- /* Increment cumulative bus bandwidth */ - /* TODO: Update this during Device-Device support */ - bus->params.bandwidth += m_rt->stream->params.rate * - m_rt->ch_count * m_rt->stream->params.bps; + /* Increment cumulative bus bandwidth */ + /* TODO: Update this during Device-Device support */ + bus->params.bandwidth += m_rt->stream->params.rate * + m_rt->ch_count * m_rt->stream->params.bps; + + /* Program params */ + ret = sdw_program_params(bus); + if (ret < 0) { + dev_err(bus->dev, "Program params failed: %d", ret); + goto restore_params; + }
- /* Program params */ - ret = sdw_program_params(bus); - if (ret < 0) { - dev_err(bus->dev, "Program params failed: %d", ret); - goto restore_params; }
ret = do_bank_switch(stream); @@ -1310,12 +1357,16 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime *stream) goto restore_params; }
- /* Prepare port(s) on the new clock configuration */ - ret = sdw_prep_deprep_ports(m_rt, true); - if (ret < 0) { - dev_err(bus->dev, "Prepare port(s) failed ret = %d", - ret); - return ret; + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + + /* Prepare port(s) on the new clock configuration */ + ret = sdw_prep_deprep_ports(m_rt, true); + if (ret < 0) { + dev_err(bus->dev, "Prepare port(s) failed ret = %d", + ret); + return ret; + } }
stream->state = SDW_STREAM_PREPARED; @@ -1343,35 +1394,40 @@ int sdw_prepare_stream(struct sdw_stream_runtime *stream) return -EINVAL; }
- mutex_lock(&stream->m_rt->bus->bus_lock); + sdw_acquire_bus_lock(stream);
ret = _sdw_prepare_stream(stream); if (ret < 0) pr_err("Prepare for stream:%s failed: %d", stream->name, ret);
- mutex_unlock(&stream->m_rt->bus->bus_lock); + sdw_release_bus_lock(stream); return ret; } EXPORT_SYMBOL(sdw_prepare_stream);
static int _sdw_enable_stream(struct sdw_stream_runtime *stream) { - struct sdw_master_runtime *m_rt = stream->m_rt; - struct sdw_bus *bus = m_rt->bus; + struct sdw_master_runtime *m_rt = NULL; + struct sdw_bus *bus = NULL; int ret;
- /* Program params */ - ret = sdw_program_params(bus); - if (ret < 0) { - dev_err(bus->dev, "Program params failed: %d", ret); - return ret; - } + /* Enable Master(s) and Slave(s) port(s) associated with stream */ + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus;
- /* Enable port(s) */ - ret = sdw_enable_disable_ports(m_rt, true); - if (ret < 0) { - dev_err(bus->dev, "Enable port(s) failed ret: %d", ret); - return ret; + /* Program params */ + ret = sdw_program_params(bus); + if (ret < 0) { + dev_err(bus->dev, "Program params failed: %d", ret); + return ret; + } + + /* Enable port(s) */ + ret = sdw_enable_disable_ports(m_rt, true); + if (ret < 0) { + dev_err(bus->dev, "Enable port(s) failed ret: %d", ret); + return ret; + } }
ret = do_bank_switch(stream); @@ -1400,37 +1456,42 @@ int sdw_enable_stream(struct sdw_stream_runtime *stream) return -EINVAL; }
- mutex_lock(&stream->m_rt->bus->bus_lock); + sdw_acquire_bus_lock(stream);
ret = _sdw_enable_stream(stream); if (ret < 0) pr_err("Enable for stream:%s failed: %d", stream->name, ret);
- mutex_unlock(&stream->m_rt->bus->bus_lock); + sdw_release_bus_lock(stream); return ret; } EXPORT_SYMBOL(sdw_enable_stream);
static int _sdw_disable_stream(struct sdw_stream_runtime *stream) { - struct sdw_master_runtime *m_rt = stream->m_rt; - struct sdw_bus *bus = m_rt->bus; + struct sdw_master_runtime *m_rt = NULL; + struct sdw_bus *bus = NULL; int ret;
- /* Disable port(s) */ - ret = sdw_enable_disable_ports(m_rt, false); - if (ret < 0) { - dev_err(bus->dev, "Disable port(s) failed: %d", ret); - return ret; + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + /* Disable port(s) */ + ret = sdw_enable_disable_ports(m_rt, false); + if (ret < 0) { + dev_err(bus->dev, "Disable port(s) failed: %d", ret); + return ret; + } } - stream->state = SDW_STREAM_DISABLED;
- /* Program params */ - ret = sdw_program_params(bus); - if (ret < 0) { - dev_err(bus->dev, "Program params failed: %d", ret); - return ret; + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + /* Program params */ + ret = sdw_program_params(bus); + if (ret < 0) { + dev_err(bus->dev, "Program params failed: %d", ret); + return ret; + } }
return do_bank_switch(stream); @@ -1452,43 +1513,46 @@ int sdw_disable_stream(struct sdw_stream_runtime *stream) return -EINVAL; }
- mutex_lock(&stream->m_rt->bus->bus_lock); + sdw_acquire_bus_lock(stream);
ret = _sdw_disable_stream(stream); if (ret < 0) pr_err("Disable for stream:%s failed: %d", stream->name, ret);
- mutex_unlock(&stream->m_rt->bus->bus_lock); + sdw_release_bus_lock(stream); return ret; } EXPORT_SYMBOL(sdw_disable_stream);
static int _sdw_deprepare_stream(struct sdw_stream_runtime *stream) { - struct sdw_master_runtime *m_rt = stream->m_rt; - struct sdw_bus *bus = m_rt->bus; + struct sdw_master_runtime *m_rt = NULL; + struct sdw_bus *bus = NULL; int ret = 0;
- /* De-prepare port(s) */ - ret = sdw_prep_deprep_ports(m_rt, false); - if (ret < 0) { - dev_err(bus->dev, "De-prepare port(s) failed: %d", ret); - return ret; - } + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + /* De-prepare port(s) */ + ret = sdw_prep_deprep_ports(m_rt, false); + if (ret < 0) { + dev_err(bus->dev, "De-prepare port(s) failed: %d", ret); + return ret; + }
- stream->state = SDW_STREAM_DEPREPARED; + /* TODO: Update this during Device-Device support */ + bus->params.bandwidth -= m_rt->stream->params.rate * + m_rt->ch_count * m_rt->stream->params.bps;
- /* TODO: Update this during Device-Device support */ - bus->params.bandwidth -= m_rt->stream->params.rate * - m_rt->ch_count * m_rt->stream->params.bps; + /* Program params */ + ret = sdw_program_params(bus); + if (ret < 0) { + dev_err(bus->dev, "Program params failed: %d", ret); + return ret; + }
- /* Program params */ - ret = sdw_program_params(bus); - if (ret < 0) { - dev_err(bus->dev, "Program params failed: %d", ret); - return ret; }
+ stream->state = SDW_STREAM_DEPREPARED; return do_bank_switch(stream); }
@@ -1508,13 +1572,12 @@ int sdw_deprepare_stream(struct sdw_stream_runtime *stream) return -EINVAL; }
- mutex_lock(&stream->m_rt->bus->bus_lock); - + sdw_acquire_bus_lock(stream); ret = _sdw_deprepare_stream(stream); if (ret < 0) pr_err("De-prepare for stream:%d failed: %d", ret, ret);
- mutex_unlock(&stream->m_rt->bus->bus_lock); + sdw_release_bus_lock(stream); return ret; } EXPORT_SYMBOL(sdw_deprepare_stream); diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index ccd8dcdf..03df709 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -768,7 +768,6 @@ struct sdw_stream_params { * @params: Stream parameters * @state: Current state of the stream * @type: Stream type PCM or PDM - * @m_rt: Master runtime * @master_list: List of Master runtime(s) in this stream. * master_list can contain only one m_rt per Master instance * for a stream @@ -778,7 +777,6 @@ struct sdw_stream_runtime { struct sdw_stream_params params; enum sdw_stream_state state; enum sdw_stream_type type; - struct sdw_master_runtime *m_rt; struct list_head master_list; };
/** @@ -918,13 +951,22 @@ static void sdw_release_master_stream(struct sdw_stream_runtime *stream) int sdw_stream_remove_master(struct sdw_bus *bus, struct sdw_stream_runtime *stream) {
- struct sdw_master_runtime *m_rt, *_m_rt;
- mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream);
- sdw_master_port_release(bus, stream->m_rt);
- stream->state = SDW_STREAM_RELEASED;
- kfree(stream->m_rt);
- stream->m_rt = NULL;
- list_for_each_entry_safe(m_rt, _m_rt,
&stream->master_list, stream_node) {if (m_rt->bus != bus)continue;sdw_master_port_release(bus, m_rt);sdw_release_master_stream(m_rt, stream);- }
- if (list_empty(&stream->master_list))
stream->state = SDW_STREAM_RELEASED;
When a master is removed, there is an explicit test to make sure the stream state changes when there are no masters left in the list, but...
mutex_unlock(&bus->bus_lock);
@@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus *bus, stream->state = SDW_STREAM_CONFIGURED;
... it's not symmetrical for the add_master case. The stream state changes on the first added master. In addition the stream state changes both when a slave is added and a master is added. Is this intentional or not - and are there side effects resulting from this inconsistency?
On Mon, Jul 02, 2018 at 03:22:07PM -0500, Pierre-Louis Bossart wrote:
/** @@ -918,13 +951,22 @@ static void sdw_release_master_stream(struct sdw_stream_runtime *stream) int sdw_stream_remove_master(struct sdw_bus *bus, struct sdw_stream_runtime *stream) {
- struct sdw_master_runtime *m_rt, *_m_rt;
- mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream);
- sdw_master_port_release(bus, stream->m_rt);
- stream->state = SDW_STREAM_RELEASED;
- kfree(stream->m_rt);
- stream->m_rt = NULL;
- list_for_each_entry_safe(m_rt, _m_rt,
&stream->master_list, stream_node) {if (m_rt->bus != bus)continue;sdw_master_port_release(bus, m_rt);sdw_release_master_stream(m_rt, stream);- }
- if (list_empty(&stream->master_list))
stream->state = SDW_STREAM_RELEASED;When a master is removed, there is an explicit test to make sure the stream state changes when there are no masters left in the list, but...
mutex_unlock(&bus->bus_lock); @@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus *bus, stream->state = SDW_STREAM_CONFIGURED;
... it's not symmetrical for the add_master case. The stream state changes on the first added master. In addition the stream state changes both when a slave is added and a master is added. Is this intentional or not - and are there side effects resulting from this inconsistency?
For remove_master, we already know the number of Masters in the stream and hence we change the state to RELEASED only when there are no Masters left in stream.
But, in the add_master case, we have no idea on how many master instances are part of the stream and hence how many times add_master would be called. So, we change the stream state to CONFIGURED when the first Master is added. I can add a comment if that helps :)
Yes, it is added intentionally (or rather because we could not think of any other suitable way) and we dont see any side effects. Anything that you could think of?
IIRC, we had this discussion when the stream series was posted. But I am unable to find those mails :(
Thanks for the review!
--Shreyas --
On 7/2/18 8:13 PM, Shreyas NC wrote:
On Mon, Jul 02, 2018 at 03:22:07PM -0500, Pierre-Louis Bossart wrote:
/** @@ -918,13 +951,22 @@ static void sdw_release_master_stream(struct sdw_stream_runtime *stream) int sdw_stream_remove_master(struct sdw_bus *bus, struct sdw_stream_runtime *stream) {
- struct sdw_master_runtime *m_rt, *_m_rt;
- mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream);
- sdw_master_port_release(bus, stream->m_rt);
- stream->state = SDW_STREAM_RELEASED;
- kfree(stream->m_rt);
- stream->m_rt = NULL;
- list_for_each_entry_safe(m_rt, _m_rt,
&stream->master_list, stream_node) {if (m_rt->bus != bus)continue;sdw_master_port_release(bus, m_rt);sdw_release_master_stream(m_rt, stream);- }
- if (list_empty(&stream->master_list))
stream->state = SDW_STREAM_RELEASED;When a master is removed, there is an explicit test to make sure the stream state changes when there are no masters left in the list, but...
mutex_unlock(&bus->bus_lock); @@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus *bus, stream->state = SDW_STREAM_CONFIGURED;
... it's not symmetrical for the add_master case. The stream state changes on the first added master. In addition the stream state changes both when a slave is added and a master is added. Is this intentional or not - and are there side effects resulting from this inconsistency?
For remove_master, we already know the number of Masters in the stream and hence we change the state to RELEASED only when there are no Masters left in stream.
But, in the add_master case, we have no idea on how many master instances are part of the stream and hence how many times add_master would be called. So, we change the stream state to CONFIGURED when the first Master is added. I can add a comment if that helps :)
I get the point, but you currently change the state for the first slave that's added, so there is an inconsistency here (even before we add the multi-master support). If I wanted to split hair I'd also note it's almost like the state is CONFIGURING rather than CONFIGURED if you don't really control when all configurations are complete at the bus level and depend on external transitions (e.g. DAPM/ALSA initiated) to go in PREPARED mode.
Yes, it is added intentionally (or rather because we could not think of any other suitable way) and we dont see any side effects. Anything that you could think of?
We should check what happens if the stream is removed before being enabled, or all cases of testing stream->state.
IIRC, we had this discussion when the stream series was posted. But I am unable to find those mails :(
I've seen SoundWire patches for the last 2 years and don't have the memory of all decisions and directions either...
Thanks for the review!
--Shreyas
- struct sdw_master_runtime *m_rt, *_m_rt;
- mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream);
- sdw_master_port_release(bus, stream->m_rt);
- stream->state = SDW_STREAM_RELEASED;
- kfree(stream->m_rt);
- stream->m_rt = NULL;
- list_for_each_entry_safe(m_rt, _m_rt,
&stream->master_list, stream_node) {if (m_rt->bus != bus)continue;sdw_master_port_release(bus, m_rt);sdw_release_master_stream(m_rt, stream);- }
- if (list_empty(&stream->master_list))
stream->state = SDW_STREAM_RELEASED;When a master is removed, there is an explicit test to make sure the stream state changes when there are no masters left in the list, but...
mutex_unlock(&bus->bus_lock); @@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus
*bus,
stream->state = SDW_STREAM_CONFIGURED;
... it's not symmetrical for the add_master case. The stream state changes on the first added master. In addition the stream state changes both when a slave is added and a master is added. Is this intentional or not - and are there side effects resulting from this inconsistency?
For remove_master, we already know the number of Masters in the stream and hence we change the state to RELEASED only when there are no Masters left in stream.
But, in the add_master case, we have no idea on how many master instances are part of the stream and hence how many times add_master
would be called.
So, we change the stream state to CONFIGURED when the first Master is
added.
I can add a comment if that helps :)
I get the point, but you currently change the state for the first slave that's added, so there is an inconsistency here (even before we add the multi-master support).
When we add a slave, we check if there is an existing m_rt for that bus instance and if It does not exist we create a m_rt for that master instance, add the slave runtime and change the state to CONFIGURED. So technically we still change the state after adding the first m_rt.
If I wanted to split hair I'd also note it's almost like the state is CONFIGURING rather than CONFIGURED if you don't really control when all configurations are complete at the bus level and depend on external transitions (e.g. DAPM/ALSA initiated) to go in PREPARED mode.
Yes, it is added intentionally (or rather because we could not think of any other suitable way) and we dont see any side effects. Anything that you could think of?
We should check what happens if the stream is removed before being enabled, or all cases of testing stream->state.
While releasing the stream we unconditionally clean up things without checking stream state. So, we should be fine that way. But, I can check these :)
--Shreyas
On 07/03/2018 11:03 AM, Nc, Shreyas wrote:
- struct sdw_master_runtime *m_rt, *_m_rt;
- mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream);
- sdw_master_port_release(bus, stream->m_rt);
- stream->state = SDW_STREAM_RELEASED;
- kfree(stream->m_rt);
- stream->m_rt = NULL;
- list_for_each_entry_safe(m_rt, _m_rt,
&stream->master_list, stream_node) {if (m_rt->bus != bus)continue;sdw_master_port_release(bus, m_rt);sdw_release_master_stream(m_rt, stream);- }
- if (list_empty(&stream->master_list))
stream->state = SDW_STREAM_RELEASED;When a master is removed, there is an explicit test to make sure the stream state changes when there are no masters left in the list, but...
mutex_unlock(&bus->bus_lock);@@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus
*bus,
stream->state = SDW_STREAM_CONFIGURED;... it's not symmetrical for the add_master case. The stream state changes on the first added master. In addition the stream state changes both when a slave is added and a master is added. Is this intentional or not - and are there side effects resulting from this inconsistency?
For remove_master, we already know the number of Masters in the stream and hence we change the state to RELEASED only when there are no Masters left in stream.
But, in the add_master case, we have no idea on how many master instances are part of the stream and hence how many times add_master
would be called.
So, we change the stream state to CONFIGURED when the first Master is
added.
I can add a comment if that helps :)
I get the point, but you currently change the state for the first slave that's added, so there is an inconsistency here (even before we add the multi-master support).
When we add a slave, we check if there is an existing m_rt for that bus instance and if It does not exist we create a m_rt for that master instance, add the slave runtime and change the state to CONFIGURED. So technically we still change the state after adding the first m_rt.
If you made no assumption on the order in which slaves and masters are added then you need this assignment to CONFIGURED twice. But if you know the slaves are added first then the second assignment is irrelevant. It's hard to memorize really since there are parts where you assume things are triggered by external events and others where there is no assumption on API use...
If I wanted to split hair I'd also note it's almost like the state is CONFIGURING rather than CONFIGURED if you don't really control when all configurations are complete at the bus level and depend on external transitions (e.g. DAPM/ALSA initiated) to go in PREPARED mode.
Yes, it is added intentionally (or rather because we could not think of any other suitable way) and we dont see any side effects. Anything that you could think of?
We should check what happens if the stream is removed before being enabled, or all cases of testing stream->state.
While releasing the stream we unconditionally clean up things without checking stream state. So, we should be fine that way. But, I can check these :)
A quick check for stream->state gives me this:
stream->state = SDW_STREAM_CONFIGURED;
so here it's a success case but we fallback to an error case...
stream_error: sdw_release_master_stream(m_rt, stream); error: mutex_unlock(&bus->bus_lock); return ret;
You are probably missing a
stream->state = SDW_STREAM_CONFIGURED; goto error; //<<< Add this
as done for the slave?
Wondering how this ever worked, you may want to triple-check the regular stream management before adding the multi-master stuff?
--Shreyas _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 07/03/2018 11:03 AM, Nc, Shreyas wrote:
- struct sdw_master_runtime *m_rt, *_m_rt;
- mutex_lock(&bus->bus_lock);
- sdw_release_master_stream(stream);
- sdw_master_port_release(bus, stream->m_rt);
- stream->state = SDW_STREAM_RELEASED;
- kfree(stream->m_rt);
- stream->m_rt = NULL;
- list_for_each_entry_safe(m_rt, _m_rt,
&stream->master_list, stream_node) {if (m_rt->bus != bus)continue;sdw_master_port_release(bus, m_rt);sdw_release_master_stream(m_rt, stream);- }
- if (list_empty(&stream->master_list))
stream->state = SDW_STREAM_RELEASED;When a master is removed, there is an explicit test to make sure the stream state changes when there are no masters left in the list, but...
mutex_unlock(&bus->bus_lock);@@ -1127,7 +1169,7 @@ int sdw_stream_add_master(struct sdw_bus
*bus,
stream->state = SDW_STREAM_CONFIGURED;... it's not symmetrical for the add_master case. The stream state changes on the first added master. In addition the stream state changes both when a slave is added and a master is added. Is this intentional or not - and are there side effects resulting from this inconsistency?
For remove_master, we already know the number of Masters in the stream and hence we change the state to RELEASED only when there are no Masters left in stream.
But, in the add_master case, we have no idea on how many master instances are part of the stream and hence how many times add_master
would be called.
So, we change the stream state to CONFIGURED when the first Master is
added.
I can add a comment if that helps :)
I get the point, but you currently change the state for the first slave that's added, so there is an inconsistency here (even before we add the multi-master support).
When we add a slave, we check if there is an existing m_rt for that bus instance and if It does not exist we create a m_rt for that master instance, add the slave runtime and change the state to CONFIGURED. So technically we still change the state after adding the first m_rt.
If you made no assumption on the order in which slaves and masters are added then you need this assignment to CONFIGURED twice. But if you know the slaves are added first then the second assignment is irrelevant. It's hard to memorize really since there are parts where you assume things are triggered by external events and others where there is no assumption on API use...
Ok, will fix this. Vinod, would you like to have a patch for fixing this in the same series or a patch later on ?
If I wanted to split hair I'd also note it's almost like the state is CONFIGURING rather than CONFIGURED if you don't really control when all configurations are complete at the bus level and depend on external transitions (e.g. DAPM/ALSA initiated) to go in PREPARED mode.
Yes, it is added intentionally (or rather because we could not think of any other suitable way) and we dont see any side effects. Anything that you could think of?
We should check what happens if the stream is removed before being enabled, or all cases of testing stream->state.
While releasing the stream we unconditionally clean up things without checking stream state. So, we should be fine that way. But, I can check these :)
A quick check for stream->state gives me this:
stream->state = SDW_STREAM_CONFIGURED;
so here it's a success case but we fallback to an error case...
stream_error: sdw_release_master_stream(m_rt, stream); error: mutex_unlock(&bus->bus_lock); return ret;
You are probably missing a
stream->state = SDW_STREAM_CONFIGURED; goto error; //<<< Add this
as done for the slave?
Wondering how this ever worked, you may want to triple-check the regular stream management before adding the multi-master stuff?
Yes, you are right. It works because of the change being a part of another change that is yet to be up streamed :(
Wondering how this slipped, this should have been part of the stream series itself. Will fix this up :)
--Shreyas
On 04-07-18, 00:17, Nc, Shreyas wrote:
On 07/03/2018 11:03 AM, Nc, Shreyas wrote:
Ok, will fix this. Vinod, would you like to have a patch for fixing this in the same series or a patch later on ?
It is a fix, so early on please :)
A multi link bankswitch can be done if the hardware supports and the stream is handled by multiple Master(s).
This preparatory patch adds support to track m_rt in a stream.
Signed-off-by: Shreyas NC shreyas.nc@intel.com --- drivers/soundwire/stream.c | 4 ++++ include/linux/soundwire/sdw.h | 2 ++ 2 files changed, 6 insertions(+)
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 0e8a2eb5..f358b92 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -759,6 +759,7 @@ struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name) stream->name = stream_name; INIT_LIST_HEAD(&stream->master_list); stream->state = SDW_STREAM_ALLOCATED; + stream->m_rt_count = 0;
return stream; } @@ -968,6 +969,7 @@ int sdw_stream_remove_master(struct sdw_bus *bus, if (list_empty(&stream->master_list)) stream->state = SDW_STREAM_RELEASED;
+ stream->m_rt_count--; mutex_unlock(&bus->bus_lock);
return 0; @@ -1166,6 +1168,8 @@ int sdw_stream_add_master(struct sdw_bus *bus, if (ret) goto stream_error;
+ stream->m_rt_count++; + stream->state = SDW_STREAM_CONFIGURED;
stream_error: diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index 03df709..214e146 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -771,6 +771,7 @@ struct sdw_stream_params { * @master_list: List of Master runtime(s) in this stream. * master_list can contain only one m_rt per Master instance * for a stream + * @m_rt_count: Count of Master runtime(s) in this stream */ struct sdw_stream_runtime { char *name; @@ -778,6 +779,7 @@ struct sdw_stream_runtime { enum sdw_stream_state state; enum sdw_stream_type type; struct list_head master_list; + int m_rt_count; };
struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name);
In cases of multiple Masters in a stream, synchronization between multiple Master(s) is achieved by performing bank switch together and using Master methods.
Add sdw_ml_bank_switch() to wait for completion of bank switch.
Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com --- drivers/soundwire/bus.c | 5 ++ drivers/soundwire/bus.h | 2 + drivers/soundwire/stream.c | 141 ++++++++++++++++++++++++++++++++++++++---- include/linux/soundwire/sdw.h | 4 ++ 4 files changed, 140 insertions(+), 12 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index dbabd5e..1cbfedf 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -35,6 +35,11 @@ int sdw_add_bus_master(struct sdw_bus *bus) INIT_LIST_HEAD(&bus->slaves); INIT_LIST_HEAD(&bus->m_rt_list);
+ /* + * Initialize multi_link flag + * TODO: populate this flag by reading property from FW node + */ + bus->multi_link = false; if (bus->ops->read_prop) { ret = bus->ops->read_prop(bus); if (ret < 0) { diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h index b6cfbdf..c77de05 100644 --- a/drivers/soundwire/bus.h +++ b/drivers/soundwire/bus.h @@ -4,6 +4,8 @@ #ifndef __SDW_BUS_H #define __SDW_BUS_H
+#define DEFAULT_BANK_SWITCH_TIMEOUT 3000 + #if IS_ENABLED(CONFIG_ACPI) int sdw_acpi_find_slaves(struct sdw_bus *bus); #else diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index f358b92..fe738a8 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -626,9 +626,10 @@ static int sdw_program_params(struct sdw_bus *bus) return ret; }
-static int sdw_bank_switch(struct sdw_bus *bus) +static int sdw_bank_switch(struct sdw_bus *bus, int m_rt_count) { int col_index, row_index; + bool multi_link; struct sdw_msg *wr_msg; u8 *wbuf = NULL; int ret = 0; @@ -638,6 +639,8 @@ static int sdw_bank_switch(struct sdw_bus *bus) if (!wr_msg) return -ENOMEM;
+ bus->defer_msg.msg = wr_msg; + wbuf = kzalloc(sizeof(*wbuf), GFP_KERNEL); if (!wbuf) { ret = -ENOMEM; @@ -658,17 +661,29 @@ static int sdw_bank_switch(struct sdw_bus *bus) SDW_MSG_FLAG_WRITE, wbuf); wr_msg->ssp_sync = true;
- ret = sdw_transfer(bus, wr_msg); + /* + * Set the multi_link flag only when both the hardware supports + * and there is a stream handled by multiple masters + */ + multi_link = bus->multi_link && (m_rt_count > 1); + + if (multi_link) + ret = sdw_transfer_defer(bus, wr_msg, &bus->defer_msg); + else + ret = sdw_transfer(bus, wr_msg); + if (ret < 0) { dev_err(bus->dev, "Slave frame_ctrl reg write failed"); goto error; }
- kfree(wr_msg); - kfree(wbuf); - bus->defer_msg.msg = NULL; - bus->params.curr_bank = !bus->params.curr_bank; - bus->params.next_bank = !bus->params.next_bank; + if (!bus->multi_link) { + kfree(wr_msg); + kfree(wbuf); + bus->defer_msg.msg = NULL; + bus->params.curr_bank = !bus->params.curr_bank; + bus->params.next_bank = !bus->params.next_bank; + }
return 0;
@@ -679,36 +694,87 @@ static int sdw_bank_switch(struct sdw_bus *bus) return ret; }
+/** + * sdw_ml_sync_bank_switch: Multilink register bank switch + * + * @bus: SDW bus instance + * + * Caller function should free the buffers on error + */ +static int sdw_ml_sync_bank_switch(struct sdw_bus *bus) +{ + unsigned long time_left; + + if (!bus->multi_link) + return 0; + + /* Wait for completion of transfer */ + time_left = wait_for_completion_timeout(&bus->defer_msg.complete, + bus->bank_switch_timeout); + + if (!time_left) { + dev_err(bus->dev, "Controller Timed out on bank switch"); + return -ETIMEDOUT; + } + + bus->params.curr_bank = !bus->params.curr_bank; + bus->params.next_bank = !bus->params.next_bank; + + if (bus->defer_msg.msg) { + kfree(bus->defer_msg.msg->buf); + kfree(bus->defer_msg.msg); + } + + return 0; +} + static int do_bank_switch(struct sdw_stream_runtime *stream) { struct sdw_master_runtime *m_rt = NULL; const struct sdw_master_ops *ops; struct sdw_bus *bus = NULL; + bool multi_link = false; int ret = 0;
- list_for_each_entry(m_rt, &stream->master_list, stream_node) { bus = m_rt->bus; ops = bus->ops;
+ if (bus->multi_link) { + multi_link = true; + mutex_lock(&bus->msg_lock); + } + /* Pre-bank switch */ if (ops->pre_bank_switch) { ret = ops->pre_bank_switch(bus); if (ret < 0) { dev_err(bus->dev, "Pre bank switch op failed: %d", ret); - return ret; + goto msg_unlock; } }
- /* Bank switch */ - ret = sdw_bank_switch(bus); + /* + * Perform Bank switch operation. + * For multi link cases, the actual bank switch is + * synchronized across all Masters and happens later as a + * part of post_bank_switch ops. + */ + ret = sdw_bank_switch(bus, stream->m_rt_count); if (ret < 0) { dev_err(bus->dev, "Bank switch failed: %d", ret); - return ret; + goto error; + } }
+ /* + * For multi link cases, it is expected that the bank switch is + * triggered by the post_bank_switch for the first Master in the list + * and for the other Masters the post_bank_switch() should return doing + * nothing. + */ list_for_each_entry(m_rt, &stream->master_list, stream_node) { bus = m_rt->bus; ops = bus->ops; @@ -719,7 +785,47 @@ static int do_bank_switch(struct sdw_stream_runtime *stream) if (ret < 0) { dev_err(bus->dev, "Post bank switch op failed: %d", ret); + goto error; } + } else if (bus->multi_link && stream->m_rt_count > 1) { + dev_err(bus->dev, + "Post bank switch ops not implemented"); + goto error; + } + + /* Set the bank switch timeout to default, if not set */ + if (!bus->bank_switch_timeout) + bus->bank_switch_timeout = DEFAULT_BANK_SWITCH_TIMEOUT; + + /* Check if bank switch was successful */ + ret = sdw_ml_sync_bank_switch(bus); + if (ret < 0) { + dev_err(bus->dev, + "multi link bank switch failed: %d", ret); + goto error; + } + + mutex_unlock(&bus->msg_lock); + } + + return ret; + +error: + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + + bus = m_rt->bus; + + kfree(bus->defer_msg.msg->buf); + kfree(bus->defer_msg.msg); + } + +msg_unlock: + + if (multi_link) { + list_for_each_entry(m_rt, &stream->master_list, stream_node) { + bus = m_rt->bus; + if (mutex_is_locked(&bus->msg_lock)) + mutex_unlock(&bus->msg_lock); } }
@@ -1170,6 +1276,17 @@ int sdw_stream_add_master(struct sdw_bus *bus,
stream->m_rt_count++;
+ /* + * For multi link streams, add the second master only if + * the bus supports it. + * Check if bus->multi_link is set + */ + if (!bus->multi_link && stream->m_rt_count > 1) { + dev_err(bus->dev, + "Multilink not supported, link %d", bus->link_id); + goto stream_error; + } + stream->state = SDW_STREAM_CONFIGURED;
stream_error: diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index 214e146..df31391 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -678,6 +678,9 @@ struct sdw_master_ops { * @defer_msg: Defer message * @clk_stop_timeout: Clock stop timeout computed * @bank_switch_timeout: Bank switch timeout computed + * @multi_link: Store bus property that indicates if multi links + * are supported. This flag is populated by drivers after reading + * appropriate firmware (ACPI/DT). */ struct sdw_bus { struct device *dev; @@ -694,6 +697,7 @@ struct sdw_bus { struct sdw_defer defer_msg; unsigned int clk_stop_timeout; u32 bank_switch_timeout; + bool multi_link; };
int sdw_add_bus_master(struct sdw_bus *bus);
To support multi link on Intel platforms, we need to update SDW SHIM registers.
So, add pre/post bank switch ops for the same in Intel driver.
Signed-off-by: Sanyog Kale sanyog.r.kale@intel.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Shreyas NC shreyas.nc@intel.com --- drivers/soundwire/intel.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+)
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 0a8990e..da7f91f 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -398,6 +398,69 @@ static int intel_config_stream(struct sdw_intel *sdw, }
/* + * bank switch routines + */ + +static int intel_pre_bank_switch(struct sdw_bus *bus) +{ + struct sdw_cdns *cdns = bus_to_cdns(bus); + struct sdw_intel *sdw = cdns_to_intel(cdns); + void __iomem *shim = sdw->res->shim; + int sync_reg; + + /* Write to register only for multi-link */ + if (!bus->multi_link) + return 0; + + /* Read SYNC register */ + sync_reg = intel_readl(shim, SDW_SHIM_SYNC); + sync_reg |= SDW_SHIM_SYNC_CMDSYNC << sdw->instance; + intel_writel(shim, SDW_SHIM_SYNC, sync_reg); + + return 0; +} + +static int intel_post_bank_switch(struct sdw_bus *bus) +{ + struct sdw_cdns *cdns = bus_to_cdns(bus); + struct sdw_intel *sdw = cdns_to_intel(cdns); + void __iomem *shim = sdw->res->shim; + int sync_reg, ret; + + /* Write to register only for multi-link */ + if (!bus->multi_link) + return 0; + + /* Read SYNC register */ + sync_reg = intel_readl(shim, SDW_SHIM_SYNC); + + /* + * post_bank_switch() ops is called from the bus in loop for + * all the Masters in the steam with the expectation that + * we trigger the bankswitch for the only first Master in the list + * and do nothing for the other Masters + * + * So, set the SYNCGO bit only if CMDSYNC bit is set for any Master. + */ + if (!(sync_reg & SDW_SHIM_SYNC_CMDSYNC_MASK)) + return 0; + + /* + * Set SyncGO bit to synchronously trigger a bank switch for + * all the masters. A write to SYNCGO bit clears CMDSYNC bit for all + * the Masters. + */ + sync_reg |= SDW_SHIM_SYNC_SYNCGO; + + ret = intel_clear_bit(shim, SDW_SHIM_SYNC, sync_reg, + SDW_SHIM_SYNC_SYNCGO); + if (ret < 0) + dev_err(sdw->cdns.dev, "Post bank switch failed: %d", ret); + + return ret; +} + +/* * DAI routines */
@@ -750,6 +813,8 @@ static struct sdw_master_ops sdw_intel_ops = { .xfer_msg_defer = cdns_xfer_msg_defer, .reset_page_addr = cdns_reset_page_addr, .set_bus_conf = cdns_bus_conf, + .pre_bank_switch = intel_pre_bank_switch, + .post_bank_switch = intel_post_bank_switch, };
/*
participants (5)
-
Nc, Shreyas -
Pierre-Louis Bossart -
Shreyas NC
-
Takashi Iwai -
Vinod