All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <shuahkh@osg.samsung.com>
To: Sakari Ailus <sakari.ailus@linux.intel.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>,
	Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: Media Controller - graph_mutex
Date: Tue, 14 Jul 2015 09:03:00 -0600	[thread overview]
Message-ID: <55A524A4.8090905@osg.samsung.com> (raw)
In-Reply-To: <55A51763.8010506@linux.intel.com>

On 07/14/2015 08:06 AM, Sakari Ailus wrote:
> 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.
> 

I am getting close to sending the RFC patches for review. I am looking
at one last issue in addition to this mutex problem. I have dmesg logs
to send and I will send them when I send the patches, so you have code
to look at as well as the dmesg.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

      reply	other threads:[~2015-07-14 15:03 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
2015-07-14 15:03   ` Shuah Khan [this message]

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=55A524A4.8090905@osg.samsung.com \
    --to=shuahkh@osg.samsung.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=sakari.ailus@linux.intel.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.