mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: lgirdwood@gmail.com, dmitry.torokhov@gmail.com,
	myungjoo.ham@samsung.com, cw00.choi@samsung.com,
	alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: dapm: Add locking to snd_soc_dapm_xxxx_pin functions
Date: Wed, 12 Feb 2014 15:44:14 +0000	[thread overview]
Message-ID: <20140212154414.GW28112@sirena.org.uk> (raw)
In-Reply-To: <20140212112409.GD16684@opensource.wolfsonmicro.com>

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Wed, Feb 12, 2014 at 11:24:09AM +0000, Charles Keepax wrote:
> On Mon, Feb 10, 2014 at 12:08:03PM +0000, Mark Brown wrote:

> > Unfortunately the fix needs to be in the callers to some extent - there
> > are situations where you want to do atomic updates of multiple pins so
> > that we don't end up bouncing the power up and down too much, we need
> > the unlocked version for things that care.  This means we need to at
> > least preserve an unlocked version and translate those callers that
> > might care over to it (not sure if any of them are in mainline).

> There are indeed none in mainline at the moment, or at least if
> there are any they are not holding the lock at the moment so it
> is not obviously they require atomic update.

Anything doing this off jack detection probably falls into that category
so the core jack detection code ought to be doing a bulk update.  For
safety I'd say that anything that's doing multiple updates at once
should be assumed to expect them to go through together (that is the
most likely outcome after all and the whole update then sync idiom means
the code looks that way).

> How would you feel about adding an extra functions that allows the
> caller to hold the lock and adding locking into the DAPM core for
> the existing users? Feels like the intention would be more clear
> and will allow out of mainline users requiring atomic updates to
> still do that.

That was roughly what I was suggesting, yes.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-02-12 15:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 11:05 Charles Keepax
2014-02-10 12:08 ` Mark Brown
2014-02-12 11:24   ` Charles Keepax
2014-02-12 15:44     ` Mark Brown [this message]
2014-02-10 13:05 ` [alsa-devel] " Takashi Iwai
2014-02-12 11:26   ` Charles Keepax
2014-02-12 11:31     ` Takashi Iwai
2014-02-10 13:47 ` Takashi Iwai

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=20140212154414.GW28112@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=ckeepax@opensource.wolfsonmicro.com \
    --cc=cw00.choi@samsung.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=patches@opensource.wolfsonmicro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®