From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Cc: broonie@kernel.org, cw00.choi@samsung.com,
dmitry.torokhov@gmail.com, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
myungjoo.ham@samsung.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 1/5] ASoC: core: Add component pin control functions
Date: Tue, 29 Nov 2016 09:23:12 +0000 [thread overview]
Message-ID: <20161129092312.GE1867@localhost.localdomain> (raw)
In-Reply-To: <1480354350-24978-2-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Nov 28, 2016 at 05:32:26PM +0000, Richard Fitzgerald wrote:
> It's often the case that a codec driver will need to control its
> own pins. However, if a name_prefix has been applied to this codec it
> must be included in the name passed to any of the snd_soc_dapm_x_pin()
> functions.
>
> The behaviour of the existing pin control functions is reasonable, since
> you may want to search for a fully-specified name within the scope of an
> entire card. This means that we can't apply the prefix in these functions
> because it will break card-scope searches.
>
> Constructing a prefixed string "manually" in codec drivers leads to a lot
> of repetition of the same code.
>
> To make this tidier in codec drivers this patch adds a new set of
> equivalent functions that take a struct snd_soc_component instead of a
> dapm context and automatically add the component's name_prefix to the
> given name. This makes it a simple change in codec drivers to be
> prefix-safe.
>
> The new functions are not quite trivial enough to be inlines and the
> compiler won't be able to compile-away any part of them.
>
> Although it looks somewhat inefficient to have to allocate a temporary
> buffer and combine strings, the current design of the widget list
> doesn't lend itself to a more optimized implementation - it's a single
> list of all widgets on a card and is searched linearly for a matching
> string. As pin state changes are generally low-frequency events it's
> unlikely to be a significant issue - at least not enough to rewrite the
> widget list handling just for this.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> include/sound/soc.h | 25 +++++++
> sound/soc/soc-utils.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 224 insertions(+)
>
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index 795e6c4..a46d0774 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -1718,4 +1718,29 @@ static inline void snd_soc_dapm_mutex_unlock(struct snd_soc_dapm_context *dapm)
> mutex_unlock(&dapm->card->dapm_mutex);
> }
>
> +extern int snd_soc_component_enable_pin(struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_enable_pin_unlocked(
> + struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_disable_pin(struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_disable_pin_unlocked(
> + struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_nc_pin(struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_nc_pin_unlocked(
> + struct snd_soc_component *component,
> + const char *pin);
> +
> +extern int snd_soc_component_get_pin_status(struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_force_enable_pin(
> + struct snd_soc_component *component,
> + const char *pin);
> +extern int snd_soc_component_force_enable_pin_unlocked(
> + struct snd_soc_component *component,
> + const char *pin);
> +
I don't believe we need these extern's C defaults to external
linkage.
Thanks,
Charles
next prev parent reply other threads:[~2016-11-29 9:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-28 17:32 [PATCH 0/5] ASoC/arizona: Ensure pin searches use widget name prefix Richard Fitzgerald
2016-11-28 17:32 ` [PATCH 1/5] ASoC: core: Add component pin control functions Richard Fitzgerald
2016-11-29 9:23 ` Charles Keepax [this message]
2016-11-28 17:32 ` [PATCH 2/5] ASoC: arizona: Use " Richard Fitzgerald
2016-11-29 9:25 ` Charles Keepax
2016-11-28 17:32 ` [PATCH 3/5] regulator: arizona-micsupp: Use SoC " Richard Fitzgerald
2016-12-15 18:28 ` Applied "regulator: arizona-micsupp: Use SoC component pin control functions" to the regulator tree Mark Brown
2016-11-28 17:32 ` [PATCH 4/5] extcon: arizona: Use SoC component pin control functions Richard Fitzgerald
2016-12-01 21:46 ` Applied "extcon: arizona: Use SoC component pin control functions" to the asoc tree Mark Brown
2016-11-28 17:32 ` [PATCH 5/5] Input: arizona-haptics - Use SoC component pin control functions Richard Fitzgerald
2016-11-28 18:53 ` Dmitry Torokhov
2016-12-01 21:48 ` Applied "Input: arizona-haptics - Use SoC component pin control functions" to the asoc tree Mark Brown
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=20161129092312.GE1867@localhost.localdomain \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=patches@opensource.wolfsonmicro.com \
--cc=rf@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;
as well as URLs for NNTP newsgroup(s).