From: Sanyog Kale <sanyog.r.kale@intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.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: Wed, 11 Jul 2018 09:17:12 +0530 [thread overview]
Message-ID: <20180711034712.GD22349@buildpc-HP-Z230> (raw)
In-Reply-To: <39c187f6-f9d6-4f01-81db-8ddba35572d7@linux.intel.com>
On Tue, Jul 10, 2018 at 01:16:30PM -0500, Pierre-Louis Bossart wrote:
> 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);
> }
Ok. Will update in next version.
Thanks
>
--
next prev parent reply other threads:[~2018-07-11 3:47 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
2018-07-11 3:47 ` Sanyog Kale [this message]
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=20180711034712.GD22349@buildpc-HP-Z230 \
--to=sanyog.r.kale@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=gregkh@linuxfoundation.org \
--cc=patches.audio@intel.com \
--cc=pierre-louis.bossart@linux.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