All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Shuah Khan <shuahkh@osg.samsung.com>,
	"Mauro Carvalho Chehab (m.chehab@samsung.com)"
	<m.chehab@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Media Controller - graph_mutex
Date: Tue, 14 Jul 2015 17:06:27 +0300	[thread overview]
Message-ID: <55A51763.8010506@linux.intel.com> (raw)
In-Reply-To: <55A432D1.9060008@osg.samsung.com>

Hi Shuah,

Shuah Khan wrote:
> All,
> 
> ALSA has to make media_entity_pipeline_start() call in irq
> path. I am seeing warnings that the graph_mutex is unsafe irq
> lock as expected. We have to update MC start/stop pipeline
> to be irq safe for ALSA. Maybe there are other MC interfaces
> that need to be irq safe, but I haven't seen any problems with
> my limited testing.
> 
> So as per options, graph_mutex could be changed to a spinlock.
> It looks like drivers hold this lock and it isn't abstracted to
> MC API. Unfortunate, this would require changes to drivers that
> directly hold the lock for graph walks if this mutex is changed
> to spinlock.
> 
> e.g: drivers/media/platform/exynos4-is/fimc-isp-video.c
> 
> Changes aren't complex, just that the scope isn't limited
> to MC API.
> 
> Other ideas??

Do you have (preliminary?) patches and / or more information? I'd like
to understand why would ALSA need this.

The graph_mutex is currently also taken when the link state is modified,
and the callbacks to the drivers may involve power state changes and
device initialisation. On some busses such as I2C these are blocking
operations.

-- 
Kind regards,

Sakari Ailus
sakari.ailus@linux.intel.com

  reply	other threads:[~2015-07-14 14:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13 21:51 Media Controller - graph_mutex Shuah Khan
2015-07-14 14:06 ` Sakari Ailus [this message]
2015-07-14 15:03   ` Shuah Khan

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=55A51763.8010506@linux.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=shuahkh@osg.samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.