Hello Charles,
In the [PATCH 00/38] of this patch set, you write:
> 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).
From my experience with some PCM codecs by TI, they can not care about the
endianness. For example, in driver [1], if I allow BE format as well,
and configure
the sound card to use BE, it will not work. I have no sound with BE.
In these cases, the codec HW supports *only* LE. That's why their
`snd_soc_dai_driver`
structures provide only LE in the `format` field.
If such drivers specify `endianness = 1`, then `soc-core` will extend
their supported
formats with BE counter-parts, see [2]. AFAIU, it will have the same
effect, as if the
drivers themselves provided their formats in both LE | BE.
I don't think adding `endianness = 1` to such codecs will work as expected.
Unfortunately, I don't have an easy access to HW today, to confirm or
disprove
this understanding.
Best regards,
Kirill
---
[1]
https://elixir.bootlin.com/linux/latest/source/sound/soc/codecs/pcm3060.c#L189
[2]
https://elixir.bootlin.com/linux/latest/source/sound/soc/soc-core.c#L2540
On 5/4/22 7:08 PM, Charles Keepax wrote:
Add a comment to make the purpose of the endianness flag on the
snd_soc_component structure more clear.
Signed-off-by: Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxx>
---
include/sound/soc-component.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/sound/soc-component.h b/include/sound/soc-component.h
index 766dc6f009c0b..5a764c3099d3e 100644
--- a/include/sound/soc-component.h
+++ b/include/sound/soc-component.h
@@ -169,6 +169,15 @@ struct snd_soc_component_driver {
unsigned int idle_bias_on:1;
unsigned int suspend_bias_off:1;
unsigned int use_pmdown_time:1; /* care pmdown_time at stop */
+ /*
+ * Indicates that the component does not care about the endianness of
+ * PCM audio data and the core will ensure that both LE and BE variants
+ * of each used format are present. Typically this is because the
+ * component sits behind a bus that abstracts away the endian of the
+ * original data, ie. one for which the transmission endian is defined
+ * (I2S/SLIMbus/SoundWire), or the concept of endian doesn't exist (PDM,
+ * analogue).
+ */
unsigned int endianness:1;
unsigned int non_legacy_dai_naming:1;
