linux-toradex.git/sound/soc/atmel, branch v5.19

Clean up usage of the endianness flag

2022-05-10T11:12:50+00:00

Merge series from Charles Keepax :

Before componentisation any part registered as a CODEC would have
automatically supported both little and big endian, ie. the core
would duplicate any supported LE or BE PCM format to support the other
endian as well. As componentisation removed the distinction between
CODEC drivers and platform drivers, a flag was added to specify
if this behaviour is required for a particular component. However,
as most systems tend to use little endian the absence of the flag
is rarely noticed. Also the naming of the flag "endianness" is a
little unobvious as to if it should be applied to a particular
component.

This series adds a comment to better explain the meaning of the
flag and then tidys up the usage of the flag. A couple of uses
of the flag are removed where is has been used inappropriately
on the CPU side of the DAI link, this is clearly not valid in the
cases it has been used, and I suspect never would be valid. Then
some redundant formats are removed, since they would be covered by
existing endianness flags. And finally a bunch of devices that are
missing the flag have it added.

It is worth noting that since componenisation there are now a couple
of cases where it is not entire clear to me that the flag should
be applied to all CODECs as it was before. In those cases I haven't
updated the driver to add the flag and they are outlined here:

1) Build into the AP CODECs, these are actual silicon inside the main
processor and they typically receive audio directly from an internal
bus. It is not obvious to me that these can happily ignore endian. On
the CODEC side these include: jz4725b.c, jz4760.c, jz4770.c,
rk3328_codec.c, lpass-va-macro.c, lpass-rx-macro.c, lpass-tx-macro.c,
lpass-wsa-macro.c. There are also some examples of this scattered
around the various platform support directories in sound/soc.

2) Devices behind non-audio buses, SPI just moves bits and doesn't
really define an endian for audio data on the bus. Thus it seems the
CODEC probably can care about the endian. The only devices that fall
into this group (mostly for AoV) are: rt5514-spi.c, rt5677-spi.c,
cros_ec_codec.c (only the AoV).

3) CODECs with no DAIs, these could specify the flag and plenty of
them do; CODECs from the initial conversion to componentisation. But
the flag makes no difference here since there is nothing for it to
apply to. This includes purely analogue CODECs: aw8738.c, ssm2305.c,
tpa6130a2.c, tda7419.c, max9759.c, max9768.c, max9877.c, lm4857.c,
simple-mux.c, simple-amplifier.c. And devices that only do jack
detection: ts3a227e.c, mt6359-accdet.c.

If there are any opinions on adding the flag to any of those three
groups they would be greatfully received. But I am leaning towards
leaving 1,2 without endianness flags since it feels inappropriate,
and removing the endian flag from devices in catagory 3 that already
have it. Assuming no one objects to that I will do a follow up
series for that.

ASoC: sam9g20_wm8731: Use dev_err_probe() for snd_soc_register_card()

2022-05-09T18:46:35+00:00

Log the error code when snd_soc_regster_card() fails, but fold in the
silencing of deferred probe errors.

Signed-off-by: Mark Brown 
Reviewed-by: Codrin Ciubotariu 
Link: https://lore.kernel.org/r/20220506130349.451452-1-broonie@kernel.org

ASoC: atmel-classd: Remove endianness flag on class d component

2022-05-09T11:46:08+00:00

The endianness flag should have been removed when the driver was
ported across from having both a CODEC and CPU side component, to
just having a CPU component and using the dummy for the CODEC. The
endianness flag is used to indicate that the device is completely
ambivalent to the endianness of the data, typically due to the
endianness being lost over the hardware link (ie. the link defines
bit ordering). It's usage didn't have any effect when the driver
had both a CPU and CODEC component, since the union of those equals
the CPU side settings, but now causes the driver to falsely report
it supports big endian. Correct this by removing the flag.

Fixes: 1dfdbe73ccf9 ("ASoC: atmel-classd: remove codec component")
Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20220504170905.332415-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown

ASoC: atmel-pdmic: Remove endianness flag on pdmic component

2022-05-09T11:46:07+00:00

The endianness flag should have been removed when the driver was
ported across from having both a CODEC and CPU side component, to
just having a CPU component and using the dummy for the CODEC. The
endianness flag is used to indicate that the device is completely
ambivalent to the endianness of the data, typically due to the
endianness being lost over the hardware link (ie. the link defines
bit ordering). It's usage didn't have any effect when the driver
had both a CPU and CODEC component, since the union of those equals
the CPU side settings, but now causes the driver to falsely report
it supports big endian. Correct this by removing the flag.

Fixes: f3c668074a04 ("ASoC: atmel-pdmic: remove codec component")
Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20220504170905.332415-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown

ASoC: Pull in fixes

2022-05-04T14:30:32+00:00

Cleanups for the dmaengine code build on top of current fixes.

ASoC: atmel: mchp-pdmc: set prepare_slave_config

2022-04-25T12:58:17+00:00

Since a pointer to struct snd_dmaengine_pcm_config is passed,
snd_dmaengine_pcm_prepare_slave_config() is no longer called unless it's
explicitly set in prepare_slave_config.

Fixes: 50291652af52 ("ASoC: atmel: mchp-pdmc: add PDMC driver")
Suggested-by: Sascha Hauer 
Signed-off-by: Codrin Ciubotariu 
Link: https://lore.kernel.org/r/20220421125403.2180824-2-codrin.ciubotariu@microchip.com
Signed-off-by: Mark Brown

ASoC: wm8731: Overhaul of the driver

2022-04-05T09:25:00+00:00

Merge series from Mark Brown :

This series contains a bunch of fairly minor changes which overhaul and
modernise the WM8731 driver, there should be no impact on the driver's
functionality.

ASoC: atmel: Don't squash error codes from atmel_ssc_set_audio()

2022-04-04T13:24:20+00:00

The AT91SAM9G20-EK audio driver is replacing any error code returned by
atmel_ssc_set_audio() with -EINVAL which could be unhelpful for debugging.
Pass through the error code, and include it in the log message we print for
good measure.

Signed-off-by: Mark Brown 
Reviewed-by: Codrin Ciubotariu 
Link: https://lore.kernel.org/r/20220325154241.1600757-4-broonie@kernel.org

ASoC: atmel: Fix error handling in at91samg20ek probe()

2022-04-04T13:24:10+00:00

The error handling in the AT91SAM9G20-EK machine driver probe did not
consistently free the SSC in error paths, sometimes immediately returning
an error rather than doing cleanup. Fix this.

Signed-off-by: Mark Brown 
Reviewed-by: Codrin Ciubotariu 
Link: https://lore.kernel.org/r/20220325154241.1600757-3-broonie@kernel.org

ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek

2022-04-04T13:24:03+00:00

The MCLK of the WM8731 on the AT91SAM9G20-EK board is connected to the
PCK0 output of the SoC, intended in the reference software to be supplied
using PLLB and programmed to 12MHz. As originally written for use with a
board file the audio driver was responsible for configuring the entire tree
but in the conversion to the common clock framework the registration of
the named pck0 and pllb clocks was removed so the driver has failed to
instantiate ever since.

Since the WM8731 driver has had support for managing a MCLK provided via
the common clock framework for some time we can simply drop all the clock
management code from the machine driver other than configuration of the
sysclk rate, the CODEC driver still respects that configuration from the
machine driver.

Fixes: ff78a189b0ae55f ("ARM: at91: remove old at91-specific clock driver")
Signed-off-by: Mark Brown 
Reviewed-by: Codrin Ciubotariu 
Link: https://lore.kernel.org/r/20220325154241.1600757-2-broonie@kernel.org