This patchset adds support to MBHC(Multi Button Headset Control) block found in
Qualcomm WCD codecs. MBHC support headset type detection, both Mechanical and
electrical insert/removal detection along with 8 buttons detection,
Over current interrupts on HPHL/R, Impedance Measurements on HPHL/R.
Eventhough MBHC block supports things like OverCurrent detection, Currently its
reported as a kernel debug message. Should this be reported as an uevent to
userspace? like the way USB reports?
Any suggestions?
First patch adds a common mbhc driver and the second one wcd934x specific driver
changes along with sdm845 soundcard related changes.
Common wcd-mbhc-v2 driver should be reusable across multiple codecs like
WCD9335, WCD934x, WCD937x and WCD938x.
Most of the work is derived from downstream Qualcomm kernels.
Credits to various Qualcomm authors from Patrick Lai's team who have
contributed to this code.
Changes since v2:
- switched to EXPORT_SYMBOL_GPL from EXPORT_SYMBOL
- converted one of the if else to switch case.
Srinivas Kandagatla (4):
ASoC: dt-bindings: wcd934x: add bindings for Headset Button detection
ASoC: codecs: wcd: add multi button Headset detection support
ASoC: codecs: wcd934x: add mbhc support
ASoC: qcom: sdm845: add jack support for WCD934x
.../bindings/sound/qcom,wcd934x.yaml | 30 +
include/linux/mfd/wcd934x/registers.h | 57 +
sound/soc/codecs/Kconfig | 4 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/wcd-mbhc-v2.c | 1475 +++++++++++++++++
sound/soc/codecs/wcd-mbhc-v2.h | 340 ++++
sound/soc/codecs/wcd934x.c | 884 +++++++++-
sound/soc/qcom/sdm845.c | 8 +
8 files changed, 2785 insertions(+), 15 deletions(-)
create mode 100644 sound/soc/codecs/wcd-mbhc-v2.c
create mode 100644 sound/soc/codecs/wcd-mbhc-v2.h
--
2.21.0
With CONFIG_SND_SOC_LPASS_RX_MACRO=m and CONFIG_REGMAP_MMIO undefined,
build fails with the following error
make -f /var/tmp/portage/sys-kernel/stable-sources-5.12.8/work/linux-5.12.8-stable/scripts/Makefile.modpost
sed 's/\.ko$/\.o/' modules.order | scripts/mod/modpost -E -o modules-only.symvers -i vmlinux.symvers -T -
ERROR: modpost: "__devm_regmap_init_mmio_clk" [sound/soc/codecs/snd-soc-lpass-rx-macro.ko] undefined!
This does also apply to other Qualcomm Macro LPASS all making call to
devm_regmap_init_mmio()
Signed-off-by: Bertrand Jacquin <bertrand@jacquin.bzh>
Link: https://lore.kernel.org/r/20210603221816.2642402-1-bertrand@jacquin.bzh
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi Mark
I noticed that adg can be more clean code.
And rsnd.h header comment was not so good
because patch has been randomly added.
This patch tidyup these.
Kuninori Morimoto (5):
ASoC: rsnd: adg: supply __printf(x, y) formatting for dbg_msg()
ASoC: rsnd: adg: tidyup rsnd_adg_get_clkin/out() parameter
ASoC: rsnd: adg: use more simple method for null_clk
ASoC: rsnd: adg: check return value for rsnd_adg_get_clkin/out()
ASoC: rsnd: tidyup __rsnd_mod_xxx macro comments
sound/soc/sh/rcar/adg.c | 139 +++++++++++++++++++++++++--------------
sound/soc/sh/rcar/rsnd.h | 21 ++----
2 files changed, 97 insertions(+), 63 deletions(-)
--
2.25.1
Current rsnd_adg_get_clkin/out() are void function,
thus adg->clk/clkout[i] might be NULL.
But, for_each_rsnd_clk/clkout() macros are assuming
all clks are non NULL.
Because of this mismatch, code can be complex and/or buggy.
These functions return error by this patch,
and make sure all clks are non NULL.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pmx5i20m.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 965386c976 ("ASoC: rsnd: call unregister for null_hw when
removed") tried unregister null_clk, but it has some issues.
1st issue is kernel will indicate below message when unregistering,
because of its timing. unregistering should be happen after clk_disable().
clk_unregister: unregistering prepared clock: rsnd_adg_null
2nd issue is, it is using priv->null_clk, but it should be adg->null_clk.
3rd issue is it is using very complex clk registering method.
more simple clk_register/unregister_fixed_rate() should be OK.
This patch fixes these.
Fixes: 965386c976 ("ASoC: rsnd: call unregister for null_hw when removed")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1hli215.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only use of the static and global snd_compress_ops structs is to
assign their address to the compress_ops field in the
snd_soc_component_driver struct which is a pointer to const. Make them
const to allow the compiler to put them in read-only memory.
Rikard Falkeborn (5):
ASoC: cs47125: Constify static struct snd_compress_ops
ASoC: wm5102: Constify static struct snd_compress_ops
ASoC: wm5110: Constify static struct snd_compress_ops
ASoC: qcom: q6asm-dai: Constify static struct snd_compress_ops
ASoC: SOF: Intel: Constify sof_probe_compressed_ops
sound/soc/codecs/cs47l24.c | 2 +-
sound/soc/codecs/wm5102.c | 2 +-
sound/soc/codecs/wm5110.c | 2 +-
sound/soc/qcom/qdsp6/q6asm-dai.c | 2 +-
sound/soc/sof/compress.c | 2 +-
sound/soc/sof/compress.h | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
--
2.31.1
In general Renesas SoC's SSI/SRC are all enabled, but some SoC is not.
H2 E2
SRC0 <=
SRC1 SRC1
SRC2 SRC2
... ...
Renesas Sound driver is assuming that *all* modules are
enabled, and thus it is using *data array* to access each modules.
Because of it, we have been using "status = disabled" at DT,
and using *full size* array but avoiding disabled module.
ex)
rcar_sound,src {
src-0 {
=> status = "disabled";
};
src1: src-1 {
...
};
...
But R-Car D3 have many disabled modules (It has SSI3/SSI4, SRC5/SRC6),
and Renesas SoC maintainer don't want above style on DT.
ex)
rcar_sound,src {
=> src0: src-0 { status = "disabled"; };
=> src1: src-1 { status = "disabled"; };
=> src2: src-2 { status = "disabled"; };
=> src3: src-3 { status = "disabled"; };
=> src4: src-4 { status = "disabled"; };
src5: src-5 {
...
};
src6: src-6 {
...
};
};
rcar_sound,ssi {
=> ssi0: ssi-0 { status = "disabled"; };
=> ssi1: ssi-1 { status = "disabled"; };
=> ssi2: ssi-2 { status = "disabled"; };
ssi3: ssi-3 {
...
};
ssi4: ssi-4 {
...
};
};
To adjust it, it needs to care about related for_each_child_of_node()
loop on rsnd driver, and it is used from...
> grep -l for_each_child_of_node sound/soc/sh/rcar/*
sound/soc/sh/rcar/core.c
sound/soc/sh/rcar/ctu.c
sound/soc/sh/rcar/dma.c
sound/soc/sh/rcar/dvc.c
sound/soc/sh/rcar/mix.c
sound/soc/sh/rcar/src.c
sound/soc/sh/rcar/ssi.c
sound/soc/sh/rcar/ssiu.c
This patch adjust to this situation.
By this patch, we can avoid disabled modules on DT
rcar_sound,src {
src5: src-5 {
...
};
src6: src-6 {
...
};
};
rcar_sound,ssi {
ssi3: ssi-3 {
...
};
ssi4: ssi-4 {
...
};
};
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875yyzk017.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Renesas Sound uses many modules (SSI/SSIU/SRC/CTU/MIX/DVC/DMA),
and supports complex connections/path.
Thus each modules needs to save its status to correctly control it.
This status is updated when by .trigger, and .hw_params/.hw_free.
Renesas Sound is protecting modules by using lock when .trigger,
but it was not enough to protecting each modules "status" if it was
used from many paths.
1) .hw_params/.hw_free update status
2) another doesn't update status, but overwrites by same value
This patch do
1) protects .hw_params/.hw_free by lock
2) do nothing if no status update
Without this patch, protected mod->status (= .trigger) might be
overwrote by non protected mod->status (= .hw_params / .hw_free),
and in such case, CTU/MIX/DVC/SSIU/SSI which are used from
many paths might get damage.
If above issue happens, Renesas Sound will be hung (= silence)
and never be recoverd.
I could reproduce this issue by continue playing very short sound
with loop very long term (3-4 hours) through 2 inputs (= MIXer).
For updating rsnd_status_update(), this patch removes rsnd_dai_call()
debug message. Because we already have debugfs support, and is not
good match to new code.
Reported-by: Linh Phung T. Y <linh.phung.jy@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Message-Id: <87wnrklwyh.wl-kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
