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>
The sparse tool complains as follows:
sound/soc/fsl/imx-card.c:121:27: warning:
symbol 'ak4458_fs_mul' was not declared. Should it be static?
sound/soc/fsl/imx-card.c:138:31: warning:
symbol 'ak4458_tdm_fs_mul' was not declared. Should it be static?
sound/soc/fsl/imx-card.c:149:27: warning:
symbol 'ak4497_fs_mul' was not declared. Should it be static?
sound/soc/fsl/imx-card.c:166:27: warning:
symbol 'ak5558_fs_mul' was not declared. Should it be static?
sound/soc/fsl/imx-card.c:180:31: warning:
symbol 'ak5558_tdm_fs_mul' was not declared. Should it be static?
Those symbols are not used outside of imx-card.c, so marks
them static.
Fixes: aa736700f4 ("ASoC: imx-card: Add imx-card machine driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Message-Id: <20210524133553.2366502-1-weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
Hi Mark, Rob
These adds R-Car D3 support for rsnd driver.
[1/3] is tidyup patch for dt-bindings (not only for D3).
[2/3], [3/3] are for R-Car D3.
Kuninori Morimoto (3):
ASoC: dt-bindings: renesas: rsnd: tidyup properties
ASoC: rsnd: tidyup loop on rsnd_adg_clk_query()
ASoC: rsnd: add null CLOCKIN support
.../bindings/sound/renesas,rsnd.yaml | 10 ++++-
sound/soc/sh/rcar/adg.c | 37 ++++++++++++++++---
2 files changed, 41 insertions(+), 6 deletions(-)
--
2.25.1
NXP's TFA98xx (now part of Goodix) are fairly popular speaker amplifiers
used in many smartphones and tablets. Most of them are sold as "smart
amplifiers" with built-in "CoolFlux DSP" that is used for volume control,
plus a "sophisticated speaker-boost and protection algorithm".
Unfortunately, they are also almost entirely undocumented. The short
datasheets (e.g. [1] for TFA9897) describe the available features,
but do not provide any information about the registers or how to use
the "CoolFlux DSP".
The amplifiers are most often configured through proprietary userspace
libraries. There are also some (rather complex) kernel drivers (e.g. [2])
but even those rely on obscure firmware blobs for configuration (so-called
"containers"). They seem to contain different "profiles" with tuned speaker
settings, sample rates and volume steps (which would be better exposed
as separate ALSA mixers).
The format of the firmware files seems to have changed a lot over the time,
so it's not even possible to simply re-use the firmware originally provided
by the vendor.
Overall, it seems close to impossible to develop a proper mainline driver
for these amplifiers that could make proper use of the built-in DSP.
This commit implements a compromise: At least the TFA1 family of the
TFA98xx amplifiers (usually called TFA989x) provide a way to *bypass*
the DSP using a special register sequence. The register sequence can be
found in similar variations in the kernel drivers from lots of vendors
e.g. in [3] and was probably mainly used for factory testing.
With the DSP bypassed, the amplifier acts mostly like a dumb standard
speaker amplifier, without (hardware) volume control. However, the setup
is much simpler and it works without any obscure firmware.
This driver implements the DSP bypass combined with chip-specific
initialization sequences adapted from [2]. Only TFA9895 is supported in
this initial commit. Except for the lack of volume control I can not hear
any difference with or without the DSP, it works just fine.
This driver allows the speaker to work on mainline Linux running on the
Samsung Galaxy A3/A5 (2015) [TFA9895] and Alcatel Idol 3 [TFA9897].
TFA9897 support will be added in separate patch set later.
[1]: https://product.goodix.com/en/docview/TFA9897%20SDS_Rev.3.1?objectId=47&objectType=document&version=78
[2]: https://source.codeaurora.org/external/mas/tfa98xx
[3]: 57b5050e34/sound/soc/codecs/tfa98xx.c (L1422-L1462)
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210513104129.36583-2-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
NXP/Goodix TFA989X (TFA1) amplifiers are controlled via an I2C bus.
Add simple device tree bindings that describe how to set them up
in the device tree.
Right now only nxp,tfa9895 is supported but this will be extended
to at least nxp,tfa9897 in the near future.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210513104129.36583-1-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
