alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Sanyog Kale <sanyog.r.kale@intel.com>
Cc: patches.audio@intel.com, gregkh@linuxfoundation.org,
	alsa-devel@alsa-project.org, vkoul@kernel.org,
	Shreyas NC <shreyas.nc@intel.com>
Subject: Re: [PATCH v5 6/9] soundwire: Handle multiple master instances in a stream
Date: Tue, 10 Jul 2018 13:16:30 -0500	[thread overview]
Message-ID: <39c187f6-f9d6-4f01-81db-8ddba35572d7@linux.intel.com> (raw)
In-Reply-To: <20180710170229.GB22349@buildpc-HP-Z230>

On 7/10/18 12:02 PM, Sanyog Kale wrote:
> On Mon, Jul 09, 2018 at 06:42:34PM -0500, Pierre-Louis Bossart wrote:
>> Sorry, another issue that I found while reviewing the entire section.
>>>   }
>>> @@ -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);
>>>
>> So the sequence is
>>
>> mutex_lock
>> sdw_master_port_release()
>> sdw_release_master_stream()
>> ?????? sdw_stream_remove_slave()
>> ?????? ?????? mutex_lock
>>
>> Is this intentional to take the same mutex twice (not sure if it even
>> works).
> 
> sdw_stream_remove_slave is called from sdw_release_master_stream to make
> sure all Slave(s) resources are freed up before freeing Master.
> sdw_stream_remove_slave is also called by Slave driver to free up Slave
> resources. In either case, we wanted to make sure the bus_lock is held
> hence the bus lock is held in sdw_stream_remove_slave API as well.

Yes, it's fine to take the lock from sdw_stream_remove_slave(), the 
point was to avoid taking the lock twice when the master is removed first.

> 
> It doesnt look correct to take same mutex twice. Will check on this.
> 
>> what you probably wanted is to replace sdw_stream_remove_slave() by the
>> equivalent sequence
>>
>> sdw_slave_port_release()
>> sdw_release_slave_stream()
>>
>> which are both supposed to be called with a bus_lock held.
> 
> you mean to say perform sdw_slave_port_release and
> sdw_release_slave_stream in sdw_release_master_stream instead of calling
> sdw_stream_remove_slave??

Yes, something like the change below:

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);
+		sdw_slave_port_release()
+		sdw_release_slave_stream()
	list_del(&m_rt->stream_node);
  	list_del(&m_rt->bus_node);
	kfree(m_rt);
  }

  reply	other threads:[~2018-07-10 18:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 11:46 [PATCH v5 0/9] soundwire: Add multi link support Shreyas NC
2018-07-05 11:46 ` [PATCH v5 1/9] soundwire: Fix duplicate stream state assignment Shreyas NC
2018-07-09 23:41   ` Pierre-Louis Bossart
2018-07-10 17:03     ` Sanyog Kale
2018-07-05 11:46 ` [PATCH v5 2/9] soundwire: fix incorrect exit after configuring stream Shreyas NC
2018-07-05 11:46 ` [PATCH v5 3/9] Documentation: soundwire: Add documentation for multi link Shreyas NC
2018-07-05 11:46 ` [PATCH v5 4/9] soundwire: Initialize completion for defer messages Shreyas NC
2018-07-05 11:46 ` [PATCH v5 5/9] soundwire: Add support to lock across bus instances Shreyas NC
2018-07-05 11:46 ` [PATCH v5 6/9] soundwire: Handle multiple master instances in a stream Shreyas NC
2018-07-09 23:42   ` Pierre-Louis Bossart
2018-07-10 17:02     ` Sanyog Kale
2018-07-10 18:16       ` Pierre-Louis Bossart [this message]
2018-07-11  3:47         ` Sanyog Kale
2018-07-05 11:46 ` [PATCH v5 7/9] soundwire: keep track of Masters " Shreyas NC
2018-07-05 11:46 ` [PATCH v5 8/9] soundwire: Add support for multi link bank switch Shreyas NC
2018-07-09 23:22   ` Pierre-Louis Bossart
2018-07-10 16:37     ` Sanyog Kale
2018-07-05 11:46 ` [PATCH v5 9/9] soundwire: intel: Add pre/post bank switch ops Shreyas NC
2018-07-09 23:47 ` [PATCH v5 0/9] soundwire: Add multi link support Pierre-Louis Bossart

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=39c187f6-f9d6-4f01-81db-8ddba35572d7@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=patches.audio@intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=shreyas.nc@intel.com \
    --cc=vkoul@kernel.org \
    /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).