History log of /openbmc/linux/sound/soc/soc-component.c (Results 76 – 100 of 147)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 9d415fbf 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: move snd_soc_component_seq_notifier()

Current soc-dapm / soc-core are using a long way round to call
.seq_notifier.

if (driver->seq_notifier)
dapm->seq_notifier = ...;
...

ASoC: soc-component: move snd_soc_component_seq_notifier()

Current soc-dapm / soc-core are using a long way round to call
.seq_notifier.

if (driver->seq_notifier)
dapm->seq_notifier = ...;
...
if (dapm->seq_notifier)
ret = dapm->seq_notifier(...);

We can directly call it via driver->seq_notifier.
One note here is that both Card and Component have dapm,
but, Card's dapm doesn't have dapm->component.
We need to check it.

This patch moves snd_soc_component_seq_notifier() to soc-component.c,
and updates parameters.
dapm->seq_notifier is no longer needed

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wog54d0v.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# a2a34175 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_of_xlate_dai_name()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good f

ASoC: soc-component: add snd_soc_component_of_xlate_dai_name()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_of_xlate_dai_name() and use it

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87y30l4d0z.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 2c7b1704 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_of_xlate_dai_id()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for

ASoC: soc-component: add snd_soc_component_of_xlate_dai_id()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_of_xlate_dai_id() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhl14d14.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 03b34dd7 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_remove()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsul

ASoC: soc-component: add snd_soc_component_remove()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_remove() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871ryd5rlo.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 08e837dd 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_probe()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsula

ASoC: soc-component: add snd_soc_component_probe()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_probe() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736it5rlt.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# e40fadbc 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_is_suspended()

Current ALSA SoC is directly using component->xxx,
But, it is not good for encapsulation.
This patch adds new snd_soc_component_is_suspended

ASoC: soc-component: add snd_soc_component_is_suspended()

Current ALSA SoC is directly using component->xxx,
But, it is not good for encapsulation.
This patch adds new snd_soc_component_is_suspended() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874l395rlx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 9a840cba 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_resume()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsul

ASoC: soc-component: add snd_soc_component_resume()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_resume() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875znp5rm2.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 66c51573 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_suspend()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsu

ASoC: soc-component: add snd_soc_component_suspend()

Current ALSA SoC is directly using component->driver->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_suspend() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e855rn0.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 5693d50c 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_trigger()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for en

ASoC: soc-component: add snd_soc_component_trigger()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_trigger() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878ssl5rn5.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# eae7136a 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_hw_free()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for en

ASoC: soc-component: add snd_soc_component_hw_free()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_hw_free() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a7d15rna.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 245c539a 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_hw_params()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for

ASoC: soc-component: add snd_soc_component_hw_params()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_hw_params() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blxh5rnf.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 6d537233 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_prepare()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for en

ASoC: soc-component: add snd_soc_component_prepare()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_prepare() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87d0hx5rnm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 3672beb8 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_close()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for enca

ASoC: soc-component: add snd_soc_component_close()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_close() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87ef2d5rnr.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# ae2f4849 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_open()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encap

ASoC: soc-component: add snd_soc_component_open()

Current ALSA SoC is directly using component->driver->ops->xxx,
thus, it is deep nested, and makes code difficult to read,
and is not good for encapsulation.
This patch adds new snd_soc_component_open() and use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87ftmt5rnx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 4a81e8f3 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add snd_soc_component_get/put()

ALSA SoC is calling try_module_get()/module_put() based on
component->driver->module_get_upon_open.
To keep simple and readable code, we should c

ASoC: soc-component: add snd_soc_component_get/put()

ALSA SoC is calling try_module_get()/module_put() based on
component->driver->module_get_upon_open.
To keep simple and readable code, we should create its function.
This patch adds new snd_soc_component_get/put().

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h8795ro4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 4ff1fef1 25-Jul-2019 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: add soc-component.c

ALSA SoC has many snd_soc_component_xxx(), but these are randomly
located in many files. Because of it, code is difficult to read.
This patch creates new soc-component.c, a

ASoC: add soc-component.c

ALSA SoC has many snd_soc_component_xxx(), but these are randomly
located in many files. Because of it, code is difficult to read.
This patch creates new soc-component.c, and moves existing
snd_soc_component_xxx() into it.
But not yet fully. We need more cleanup it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87imrp5roa.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 0af6a9f8 26-Jul-2021 Mark Brown <broonie@kernel.org>

ASoC: component: Remove misplaced prefix handling in pin control functions

[ Upstream commit 31428c78748cafdd9352e1f622eb89bf453d9700 ]

When the component level pin control function

ASoC: component: Remove misplaced prefix handling in pin control functions

[ Upstream commit 31428c78748cafdd9352e1f622eb89bf453d9700 ]

When the component level pin control functions were added they for some
no longer obvious reason handled adding prefixing of widget names. This
meant that when the lack of prefix handling in the DAPM level pin
operations was fixed by ae4fc532244b3bb4d (ASoC: dapm: use component
prefix when checking widget names) the one device using the component
level API ended up with the prefix being applied twice, causing all
lookups to fail.

Fix this by removing the redundant prefixing from the component code,
which has the nice side effect of also making that code much simpler.

Reported-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Tested-by: Lucas Tanure <tanureal@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210726194123.54585-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


# 939a5cfb 27-Sep-2020 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add mark for snd_soc_pcm_component_pm_runtime_get/put()

soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().

sta

ASoC: soc-component: add mark for snd_soc_pcm_component_pm_runtime_get/put()

soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().

static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;

^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}

The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.

This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.

Now, soc_pcm_open/close() are handling
1) snd_soc_dai_startup/shutdown()
2) snd_soc_link_startup/shutdown()
3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close()
=> 5) pm_runtime_put/get()

This patch is for 5) pm_runtime_put/get().

The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.

To avoid such case, this patch marks substream pointer when get() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.

One note here is that it cares *current* get() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h7ribwnb.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 51aff91a 27-Sep-2020 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: add mark for soc_pcm_components_open/close()

soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().

static int soc

ASoC: soc-component: add mark for soc_pcm_components_open/close()

soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().

static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;

^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}

The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.

This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.

Now, soc_pcm_open/close() are handling
1) snd_soc_dai_startup/shutdown()
2) snd_soc_link_startup/shutdown()
=> 3) snd_soc_component_module_get/put()
=> 4) snd_soc_component_open/close()
5) pm_runtime_put/get()

This patch is for 3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close().

The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.

To avoid such case, this patch marks substream pointer when open() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.

One note here is that it cares *current* open() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87imbybwno.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58
# efc913c8 10-Aug-2020 Takashi Iwai <tiwai@suse.de>

ASoC: Make soc_component_read() returning an error code again

Along with the recent unification of snd_soc_component_read*()
functions, the behavior of snd_soc_component_read() was chang

ASoC: Make soc_component_read() returning an error code again

Along with the recent unification of snd_soc_component_read*()
functions, the behavior of snd_soc_component_read() was changed
slightly; namely it returns the register read value directly, and even
if an error happens, it returns zero (but it prints an error
message). That said, the caller side can't know whether it's an error
or not any longer.

Ideally this shouldn't matter much, but in practice this seems causing
a regression, as John reported. And, grepping the tree revealed that
there are still plenty of callers that do check the error code, so
we'll need to deal with them in anyway.

As a quick band-aid over the regression, this patch changes the return
value of snd_soc_component_read() again to the negative error code.
It can't work, obviously, for 32bit register values, but it should be
enough for the known regressions, so far.

Fixes: cf6e26c71bfd ("ASoC: soc-component: merge snd_soc_component_read() and snd_soc_component_read32()")
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200810134631.19742-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55
# 08ff7209 31-Jul-2020 Cezary Rojewski <cezary.rojewski@intel.com>

ASoC: core: Relocate and expose snd_soc_component_initialize

To allow for two-step component registration, expose
snd_soc_component_initialize function and move it back to soc-core.c.

ASoC: core: Relocate and expose snd_soc_component_initialize

To allow for two-step component registration, expose
snd_soc_component_initialize function and move it back to soc-core.c.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200731144146.6678-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v5.7.11, v5.4.54
# cc4d8ceb 23-Jul-2020 Jerome Brunet <jbrunet@baylibre.com>

ASoC: soc-component: don't report of_xlate_dai_name failures

With commit e2329eeba45f ("ASoC: soc-component: add soc_component_err()")
every error different for ENOTSUPP or EPROBE_DEFER

ASoC: soc-component: don't report of_xlate_dai_name failures

With commit e2329eeba45f ("ASoC: soc-component: add soc_component_err()")
every error different for ENOTSUPP or EPROBE_DEFER will log an error.

However, as explained in snd_soc_get_dai_name(), this callback may error
to indicate that the DAI is not matched by the component tested. If the
device provides other components, those may still match. Logging an error
in this case is misleading.

Don't use soc_component_ret() in snd_soc_component_of_xlate_dai_name()
to avoid spamming the log.

Fixes: e2329eeba45f ("ASoC: soc-component: add soc_component_err()")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200723142020.1338740-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v5.7.10, v5.4.53
# 0ceef681 19-Jul-2020 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-xxx: add asoc_substream_to_rtd()

Current soc-xxx are getting rtd from substream by

rtd = substream->private_data;

But, getting data from "private_data" is

ASoC: soc-xxx: add asoc_substream_to_rtd()

Current soc-xxx are getting rtd from substream by

rtd = substream->private_data;

But, getting data from "private_data" is very unclear.
This patch adds asoc_substream_to_rtd() macro which is
easy to understand that rtd from substream.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wo2z0yve.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v5.4.52, v5.7.9
# be75db57 16-Jul-2020 Shengjiu Wang <shengjiu.wang@nxp.com>

ASoC: soc-component: Add missed return for calling soc_component_ret

Add missed return for calling soc_component_ret, otherwise the return
value is wrong.

Fixes: e2329eeba45f ("

ASoC: soc-component: Add missed return for calling soc_component_ret

Add missed return for calling soc_component_ret, otherwise the return
value is wrong.

Fixes: e2329eeba45f ("ASoC: soc-component: add soc_component_err()")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/1594876028-1845-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47
# e8712315 16-Jun-2020 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: soc-component: use io_mutex correctly

component has io_mutex, but it had been used at
snd_soc_component_update_bits_legacy() only which does read and write.

static

ASoC: soc-component: use io_mutex correctly

component has io_mutex, but it had been used at
snd_soc_component_update_bits_legacy() only which does read and write.

static int snd_soc_component_update_bits_legacy(...)
{
...
=> mutex_lock(&component->io_mutex);
...
old = snd_soc_component_read(...);
...
ret = snd_soc_component_write(...);
...
=> mutex_unlock(&component->io_mutex);
...
}

It is pointless if it is not used with both read and write functions.
This patch uses io_mutex correctly with read/write.
Here, xxx_no_lock() is local functions.

static int snd_soc_component_read(...)
{
...
=> mutex_lock(&component->io_mutex);
val = soc_component_read_no_lock(...);
=> mutex_unlock(&component->io_mutex);
...
}

static int snd_soc_component_write(...)
{
...
=> mutex_lock(&component->io_mutex);
ret = soc_component_write_no_lock(...);
=> mutex_unlock(&component->io_mutex);
...
}

static int snd_soc_component_update_bits_legacy(...)
{
...
=> mutex_lock(&component->io_mutex);
...
old = soc_component_read_no_lock(...);
...
ret = soc_component_write_no_lock(...);
...
=> mutex_unlock(&component->io_mutex);
...
}

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1uf4mfa.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


123456