[PATCH 00/38] Clean up usage of the endianness flag
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.
Thanks, Charles
Charles Keepax (38): ASoC: soc-component: Add comment for the endianness flag ASoC: atmel-pdmic: Remove endianness flag on pdmic component ASoC: atmel-classd: Remove endianness flag on class d component ASoC: cs4270: Remove redundant big endian formats ASoC: cs42l51: Remove redundant big endian formats ASoC: cs4349: Remove redundant big endian formats ASoC: hdmi-codec: Remove redundant big endian formats ASoC: sta32x: Remove redundant big endian formats ASoC: sta350: Remove redundant big endian formats ASoC: hdac_hda: Add endianness flag in snd_soc_component_driver ASoC: max98504: Add endianness flag in snd_soc_component_driver ASoC: adau1372: Add endianness flag in snd_soc_component_driver ASoC: cs4234: Add endianness flag in snd_soc_component_driver ASoC: cs35l41: Add endianness flag in snd_soc_component_driver ASoC: cx2072x: Add endianness flag in snd_soc_component_driver ASoC: lochnagar: Add endianness flag in snd_soc_component_driver ASoC: mt6351: Add endianness flag in snd_soc_component_driver ASoC: mt6358: Add endianness flag in snd_soc_component_driver ASoC: mt6359: Add endianness flag in snd_soc_component_driver ASoC: mt6660: Add endianness flag in snd_soc_component_driver ASoC: pcm3060: Add endianness flag in snd_soc_component_driver ASoC: rt1019: Add endianness flag in snd_soc_component_driver ASoC: rt9120: Add endianness flag in snd_soc_component_driver ASoC: tlv320adc3xxx: Add endianness flag in snd_soc_component_driver ASoC: tscs454: Add endianness flag in snd_soc_component_driver ASoC: cros_ec_codec: Add endianness flag in i2s_rx_component_driver ASoC: wcd934x: Add endianness flag in snd_soc_component_driver ASoC: wcd9335: Add endianness flag in snd_soc_component_driver ASoC: rt700: Add endianness flag in snd_soc_component_driver ASoC: rt711: Add endianness flag in snd_soc_component_driver ASoC: rt711-sdca: Add endianness flag in snd_soc_component_driver ASoC: rt715: Add endianness flag in snd_soc_component_driver ASoC: rt715-sdca: Add endianness flag in snd_soc_component_driver ASoC: rt1308-sdw: Add endianness flag in snd_soc_component_driver ASoC: rt1316-sdw: Add endianness flag in snd_soc_component_driver ASoC: wcd938x: Add endianness flag in snd_soc_component_driver ASoC: wsa881x: Add endianness flag in snd_soc_component_driver ASoC: sdw-mockup: Add endianness flag in snd_soc_component_driver
include/sound/soc-component.h | 9 +++++++++ sound/soc/atmel/atmel-classd.c | 1 - sound/soc/atmel/atmel-pdmic.c | 1 - sound/soc/codecs/adau1372.c | 1 + sound/soc/codecs/cros_ec_codec.c | 7 ++++--- sound/soc/codecs/cs35l41.c | 2 ++ sound/soc/codecs/cs4234.c | 1 + sound/soc/codecs/cs4270.c | 15 +++------------ sound/soc/codecs/cs42l51.c | 7 ++----- sound/soc/codecs/cs4349.c | 9 +++------ sound/soc/codecs/cx2072x.c | 1 + sound/soc/codecs/hdac_hda.c | 15 ++++++++------- sound/soc/codecs/hdmi-codec.c | 15 +++++---------- sound/soc/codecs/lochnagar-sc.c | 5 +++-- sound/soc/codecs/max98504.c | 1 + sound/soc/codecs/mt6351.c | 10 ++++------ sound/soc/codecs/mt6358.c | 10 ++++------ sound/soc/codecs/mt6359.c | 10 ++++------ sound/soc/codecs/mt6660.c | 1 + sound/soc/codecs/pcm3060.c | 1 + sound/soc/codecs/rt1019.c | 3 ++- sound/soc/codecs/rt1308-sdw.c | 1 + sound/soc/codecs/rt1316-sdw.c | 1 + sound/soc/codecs/rt700.c | 1 + sound/soc/codecs/rt711-sdca.c | 1 + sound/soc/codecs/rt711.c | 1 + sound/soc/codecs/rt715-sdca.c | 1 + sound/soc/codecs/rt715.c | 1 + sound/soc/codecs/rt9120.c | 1 + sound/soc/codecs/sdw-mockup.c | 1 + sound/soc/codecs/sta32x.c | 9 +++------ sound/soc/codecs/sta350.c | 9 +++------ sound/soc/codecs/tlv320adc3xxx.c | 11 ++++++----- sound/soc/codecs/tscs454.c | 12 ++++++------ sound/soc/codecs/wcd9335.c | 1 + sound/soc/codecs/wcd934x.c | 1 + sound/soc/codecs/wcd938x.c | 1 + sound/soc/codecs/wsa881x.c | 1 + 38 files changed, 90 insertions(+), 89 deletions(-)
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@opensource.cirrus.com --- 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;
Hello Charles,
In the [PATCH 00/38] of this patch set, you write:
- 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#L1...
[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@opensource.cirrus.com
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).*/
On Sun, May 08, 2022 at 10:34:12PM +0200, Kirill Marinushkin wrote:
In the [PATCH 00/38] of this patch set, you write:
- 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.
This sounds like an error on the CPU side of the DAI link rather than the CODEC side of the DAI link. The formats that will be supported on the link are the union of the CPU and CODEC supported formats, ie. a format must be supported on both for the DAI to support it.
The CPU I2S hardware should be sending out the bits in the same order regardless of if the data you feed it is BE or LE, as I2S specifies an ordering for the bits. If this is not the case then the host I2S controller is claiming to support an endian it does not, and the problem should be fixed on that side by removing the supported endian.
Thanks, Charles
Hello Charles,
On 5/9/22 10:37 AM, Charles Keepax wrote:
On Sun, May 08, 2022 at 10:34:12PM +0200, Kirill Marinushkin wrote:
In the [PATCH 00/38] of this patch set, you write:
- 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.
This sounds like an error on the CPU side of the DAI link rather than the CODEC side of the DAI link. The formats that will be supported on the link are the union of the CPU and CODEC supported formats, ie. a format must be supported on both for the DAI to support it.
Yes, agree, both sides of the DAI link should provide only endianness they support.
This works currently, but, from my understending, it will break, after we set `endianness = 1`.
As soon as we start setting `endianness = 1`, the function `convert_endianness_formats()` will extend LE to (LE | BE), right?
If so, setting `endianness = 1` is the source of an error, right?
I could be missing something. Let's see what other reviewers think.
The CPU I2S hardware should be sending out the bits in the same order regardless of if the data you feed it is BE or LE, as I2S specifies an ordering for the bits.
What does the endianness in the driver configure, then?
If this is not the case then the host I2S controller is claiming to support an endian it does not, and the problem should be fixed on that side by removing the supported endian.
I think we have a misundersanding of my example.
In my example, i don't mean, that my CPU part of the DAI link is broken.
What i tried to demonstrate - is that if i set the unsupported endianness, i wouldn't expect that "the CODEC probably can care about the endian", as the message in [PATCH 00/38] suggests. I would expect, that i will have no sound.
Best regards,
Kirill
Thanks, Charles
On Mon, May 09, 2022 at 09:22:42PM +0200, Kirill Marinushkin wrote:
On 5/9/22 10:37 AM, Charles Keepax wrote:
This sounds like an error on the CPU side of the DAI link rather than the CODEC side of the DAI link. The formats that will be supported on the link are the union of the CPU and CODEC supported formats, ie. a format must be supported on both for the DAI to support it.
Yes, agree, both sides of the DAI link should provide only endianness they support.
This works currently, but, from my understending, it will break, after we set `endianness = 1`.
As soon as we start setting `endianness = 1`, the function `convert_endianness_formats()` will extend LE to (LE | BE), right?
If so, setting `endianness = 1` is the source of an error, right?
If doing this for the CODEC side of the link causes an issue it's just exposing an existing bug on the CPU side of the link which may already be affecting other systems - like Charles says the CODEC is expecting a fixed bit order regardless of the memory layout of the data.
The CPU I2S hardware should be sending out the bits in the same order regardless of if the data you feed it is BE or LE, as I2S specifies an ordering for the bits.
What does the endianness in the driver configure, then?
On the CODEC driver side it is meaningless. On the CPU side it controls the in memory layout of the data.
If this is not the case then the host I2S controller is claiming to support an endian it does not, and the problem should be fixed on that side by removing the supported endian.
I think we have a misundersanding of my example.
In my example, i don't mean, that my CPU part of the DAI link is broken.
What i tried to demonstrate - is that if i set the unsupported endianness, i wouldn't expect that "the CODEC probably can care about the endian", as the message in [PATCH 00/38] suggests. I would expect, that i will have no sound.
If the CPU side of the link is fine then there should be no problem, we simply start supporting both endian settings all the way through the chain, if userspace chooses something that wasn't supported before then the CPU side driver will look at what's being configured and set up the hardware appropriately.
Hello Charles, Mark,
Thank you for the clarification!
Without such a deep understanding of ASoC, as you have, I see a risk in a bulk enable of `endianness = 1`, the way we do in this patch set.
Here, we enable an extra feature. Worst case, if some codec doesn't support the feature, we will have a system, which thinks that it's supported, but in reality, it doesn't work. And we will not even have a error message, because the driver advertises the feature as supported.
Maybe my carefulness is not applicable here. I see that i don't have enough expertise in `endianness = 1`, to participate in making the decision here. But at least i want to ensure, that we all understand the risk.
Best Regards,
Kirill
On 5/9/22 9:30 PM, Mark Brown wrote:
On Mon, May 09, 2022 at 09:22:42PM +0200, Kirill Marinushkin wrote:
On 5/9/22 10:37 AM, Charles Keepax wrote:
This sounds like an error on the CPU side of the DAI link rather than the CODEC side of the DAI link. The formats that will be supported on the link are the union of the CPU and CODEC supported formats, ie. a format must be supported on both for the DAI to support it.
Yes, agree, both sides of the DAI link should provide only endianness they support. This works currently, but, from my understending, it will break, after we set `endianness = 1`. As soon as we start setting `endianness = 1`, the function `convert_endianness_formats()` will extend LE to (LE | BE), right? If so, setting `endianness = 1` is the source of an error, right?
If doing this for the CODEC side of the link causes an issue it's just exposing an existing bug on the CPU side of the link which may already be affecting other systems - like Charles says the CODEC is expecting a fixed bit order regardless of the memory layout of the data.
The CPU I2S hardware should be sending out the bits in the same order regardless of if the data you feed it is BE or LE, as I2S specifies an ordering for the bits.
What does the endianness in the driver configure, then?
On the CODEC driver side it is meaningless. On the CPU side it controls the in memory layout of the data.
If this is not the case then the host I2S controller is claiming to support an endian it does not, and the problem should be fixed on that side by removing the supported endian.
I think we have a misundersanding of my example. In my example, i don't mean, that my CPU part of the DAI link is broken. What i tried to demonstrate - is that if i set the unsupported endianness, i wouldn't expect that "the CODEC probably can care about the endian", as the message in [PATCH 00/38] suggests. I would expect, that i will have no sound.
If the CPU side of the link is fine then there should be no problem, we simply start supporting both endian settings all the way through the chain, if userspace chooses something that wasn't supported before then the CPU side driver will look at what's being configured and set up the hardware appropriately.
On Mon, May 09, 2022 at 10:11:03PM +0200, Kirill Marinushkin wrote:
Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed.
Without such a deep understanding of ASoC, as you have, I see a risk in a bulk enable of `endianness = 1`, the way we do in this patch set.
Here, we enable an extra feature. Worst case, if some codec doesn't support the feature, we will have a system, which thinks that it's supported, but in reality, it doesn't work. And we will not even have a error message, because the driver advertises the feature as supported.
Maybe my carefulness is not applicable here. I see that i don't have enough expertise in `endianness = 1`, to participate in making the decision here. But at least i want to ensure, that we all understand the risk.
The risk here is that we expose a preexisting bug in some CPU side driver to a wider set of users, but those drivers would still be buggy no matter what and may already be causing problems on some systems even if that's not been reported so if there is a problem it's always possible that we end up helping some users who currently have issues by helping someone realise what the problem is. However most likely nobody will notice anything either way and most systems will continue using exactly the same formats they already were.
On Mon, May 09, 2022 at 09:22:42PM +0200, Kirill Marinushkin wrote:
On 5/9/22 10:37 AM, Charles Keepax wrote:
On Sun, May 08, 2022 at 10:34:12PM +0200, Kirill Marinushkin wrote: This sounds like an error on the CPU side of the DAI link rather than the CODEC side of the DAI link. The formats that will be supported on the link are the union of the CPU and CODEC supported formats, ie. a format must be supported on both for the DAI to support it.
Yes, agree, both sides of the DAI link should provide only endianness they support.
This works currently, but, from my understending, it will break, after we set `endianness = 1`.
It will break if the CPU side claims it supports endians which it doesn't which I believe is what you have in your system.
As soon as we start setting `endianness = 1`, the function `convert_endianness_formats()` will extend LE to (LE | BE), right?
Correct.
If so, setting `endianness = 1` is the source of an error, right?
No, potentially it exposes an error but it is not the source of the error. Endian should have no meaning once you cross an I2S bus.
If this is not the case then the host I2S controller is claiming to support an endian it does not, and the problem should be fixed on that side by removing the supported endian.
I think we have a misundersanding of my example.
In my example, i don't mean, that my CPU part of the DAI link is broken.
Why are you sure the CPU part of the DAI link isn't broken? I2S defines the order bits should be sent out on the bus, this means if the CPU side recieves big endian or little endian data it doesn't matter, the actual bus signals should be identical in both cases. If only one endian works the actual signals on the bus must have been different depending on which endian you played in which case the host side doesn't match the I2S specification.
My point is that what you are seeing is exactly what you get if your CPU DAI claimed to support both big and little endian but just puts that data directly out on the bus, rather than adapting to the endian of data it receives.
And to be fair this is exactly what I am trying to tackle with this series. The fact we have so many CODECs that are incorrectly not specifying the endianness flag means that it is very easy for the host side guys to do testing and not realise that the CODEC is the one limiting the supported endians on the DAI link and thus miss they have claimed to support endians they don't.
I believe you are right that there is a reasonable chance will see some breakage after these patches, but that breakage should be exposing host side bugs which we need to fix anyway.
What i tried to demonstrate - is that if i set the unsupported endianness, i wouldn't expect that "the CODEC probably can care about the endian", as the message in [PATCH 00/38] suggests.
That comment in my original post was in respect to CODECs that recieve/transmit audio directly over a SPI bus rather than a normal audio bus. The is no standard governing how audio data is transmitted over the SPI bus, thus endian could be important, although I need to do some more work to analyse how people are using these links. Often they are implemented effectively as a CPU side DAI anyway.
Thanks, Charles
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 ckeepax@opensource.cirrus.com --- sound/soc/atmel/atmel-pdmic.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/sound/soc/atmel/atmel-pdmic.c b/sound/soc/atmel/atmel-pdmic.c index 42117de299e74..ea34efac2fff5 100644 --- a/sound/soc/atmel/atmel-pdmic.c +++ b/sound/soc/atmel/atmel-pdmic.c @@ -481,7 +481,6 @@ static const struct snd_soc_component_driver atmel_pdmic_cpu_dai_component = { .num_controls = ARRAY_SIZE(atmel_pdmic_snd_controls), .idle_bias_on = 1, .use_pmdown_time = 1, - .endianness = 1, };
/* ASoC sound card */
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 ckeepax@opensource.cirrus.com --- sound/soc/atmel/atmel-classd.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/sound/soc/atmel/atmel-classd.c b/sound/soc/atmel/atmel-classd.c index a9f9f449c48c2..74b7b2611aa70 100644 --- a/sound/soc/atmel/atmel-classd.c +++ b/sound/soc/atmel/atmel-classd.c @@ -458,7 +458,6 @@ static const struct snd_soc_component_driver atmel_classd_cpu_dai_component = { .num_controls = ARRAY_SIZE(atmel_classd_snd_controls), .idle_bias_on = 1, .use_pmdown_time = 1, - .endianness = 1, };
/* ASoC sound card */
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cs4270.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/sound/soc/codecs/cs4270.c b/sound/soc/codecs/cs4270.c index 07cac01f87bdc..531f63b015547 100644 --- a/sound/soc/codecs/cs4270.c +++ b/sound/soc/codecs/cs4270.c @@ -32,18 +32,9 @@ #include <linux/gpio/consumer.h> #include <linux/of_device.h>
-/* - * The codec isn't really big-endian or little-endian, since the I2S - * interface requires data to be sent serially with the MSbit first. - * However, to support BE and LE I2S devices, we specify both here. That - * way, ALSA will always match the bit patterns. - */ -#define CS4270_FORMATS (SNDRV_PCM_FMTBIT_S8 | \ - SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE | \ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE | \ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE) +#define CS4270_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S20_3LE | \ + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_LE)
/* CS4270 registers addresses */ #define CS4270_CHIPID 0x01 /* Chip ID */
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cs42l51.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index e9c3cb4e2bfcb..aff618513c753 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -51,11 +51,8 @@ struct cs42l51_private { struct regmap *regmap; };
-#define CS42L51_FORMATS ( \ - SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE | \ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE) +#define CS42L51_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S18_3LE | \ + SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE)
static int cs42l51_get_chan_mix(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol)
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cs4349.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/cs4349.c b/sound/soc/codecs/cs4349.c index 4ec4bed9ee08b..7069e9b548576 100644 --- a/sound/soc/codecs/cs4349.c +++ b/sound/soc/codecs/cs4349.c @@ -223,12 +223,9 @@ static const struct snd_soc_dapm_route cs4349_routes[] = { {"OutputB", NULL, "HiFi DAC"}, };
-#define CS4349_PCM_FORMATS (SNDRV_PCM_FMTBIT_S8 | \ - SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE | \ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE | \ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE | \ +#define CS4349_PCM_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S20_3LE | \ + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_LE | \ SNDRV_PCM_FMTBIT_S32_LE)
#define CS4349_PCM_RATES SNDRV_PCM_RATE_8000_192000
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/hdmi-codec.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c index b07607a9ecea4..b773466619b23 100644 --- a/sound/soc/codecs/hdmi-codec.c +++ b/sound/soc/codecs/hdmi-codec.c @@ -727,10 +727,8 @@ static const struct snd_soc_dai_ops hdmi_codec_spdif_dai_ops = { SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 |\ SNDRV_PCM_RATE_192000)
-#define SPDIF_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE) +#define SPDIF_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE |\ + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_LE)
/* * This list is only for formats allowed on the I2S bus. So there is @@ -740,12 +738,9 @@ static const struct snd_soc_dai_ops hdmi_codec_spdif_dai_ops = { * problems, we should add the video side driver an option to disable * them. */ -#define I2S_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE |\ - SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE) +#define I2S_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE |\ + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_LE |\ + SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE)
static struct snd_kcontrol_new hdmi_codec_controls[] = { {
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/sta32x.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/sta32x.c b/sound/soc/codecs/sta32x.c index 0ba6eab991c4e..8585cbef4c9be 100644 --- a/sound/soc/codecs/sta32x.c +++ b/sound/soc/codecs/sta32x.c @@ -48,12 +48,9 @@ SNDRV_PCM_RATE_192000)
#define STA32X_FORMATS \ - (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE | \ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE | \ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE | \ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE) + (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S18_3LE | \ + SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_3LE | \ + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
/* Power-up register defaults */ static const struct reg_default sta32x_regs[] = {
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/sta350.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/sta350.c b/sound/soc/codecs/sta350.c index 1fb370fc0ae38..9189fb3648f7d 100644 --- a/sound/soc/codecs/sta350.c +++ b/sound/soc/codecs/sta350.c @@ -48,12 +48,9 @@ SNDRV_PCM_RATE_192000)
#define STA350_FORMATS \ - (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE | \ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE | \ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE | \ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE) + (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S18_3LE | \ + SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_3LE | \ + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
/* Power-up register defaults */ static const struct reg_default sta350_regs[] = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an HDA DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/hdac_hda.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/hdac_hda.c b/sound/soc/codecs/hdac_hda.c index a9f61c7e44ee7..8debcee592247 100644 --- a/sound/soc/codecs/hdac_hda.c +++ b/sound/soc/codecs/hdac_hda.c @@ -571,13 +571,14 @@ static const struct snd_soc_dapm_widget hdac_hda_dapm_widgets[] = { };
static const struct snd_soc_component_driver hdac_hda_codec = { - .probe = hdac_hda_codec_probe, - .remove = hdac_hda_codec_remove, - .idle_bias_on = false, - .dapm_widgets = hdac_hda_dapm_widgets, - .num_dapm_widgets = ARRAY_SIZE(hdac_hda_dapm_widgets), - .dapm_routes = hdac_hda_dapm_routes, - .num_dapm_routes = ARRAY_SIZE(hdac_hda_dapm_routes), + .probe = hdac_hda_codec_probe, + .remove = hdac_hda_codec_remove, + .dapm_widgets = hdac_hda_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(hdac_hda_dapm_widgets), + .dapm_routes = hdac_hda_dapm_routes, + .num_dapm_routes = ARRAY_SIZE(hdac_hda_dapm_routes), + .idle_bias_on = false, + .endianness = 1, };
static int hdac_hda_dev_probe(struct hdac_device *hdev)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a PDM DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/max98504.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98504.c b/sound/soc/codecs/max98504.c index 9da7381472e3b..0daa2a3dd6215 100644 --- a/sound/soc/codecs/max98504.c +++ b/sound/soc/codecs/max98504.c @@ -291,6 +291,7 @@ static const struct snd_soc_component_driver max98504_component_driver = { .num_dapm_widgets = ARRAY_SIZE(max98504_dapm_widgets), .dapm_routes = max98504_dapm_routes, .num_dapm_routes = ARRAY_SIZE(max98504_dapm_routes), + .endianness = 1, };
static const struct regmap_config max98504_regmap = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/adau1372.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/adau1372.c b/sound/soc/codecs/adau1372.c index 1faa4c4263650..a9f89e8565ec6 100644 --- a/sound/soc/codecs/adau1372.c +++ b/sound/soc/codecs/adau1372.c @@ -859,6 +859,7 @@ static const struct snd_soc_component_driver adau1372_driver = { .num_dapm_widgets = ARRAY_SIZE(adau1372_dapm_widgets), .dapm_routes = adau1372_dapm_routes, .num_dapm_routes = ARRAY_SIZE(adau1372_dapm_routes), + .endianness = 1, };
static const struct snd_soc_dai_ops adau1372_dai_ops = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cs4234.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/cs4234.c b/sound/soc/codecs/cs4234.c index b44939166e5d8..881c5ba70c0ed 100644 --- a/sound/soc/codecs/cs4234.c +++ b/sound/soc/codecs/cs4234.c @@ -663,6 +663,7 @@ static const struct snd_soc_component_driver soc_component_cs4234 = { .non_legacy_dai_naming = 1, .idle_bias_on = 1, .suspend_bias_off = 1, + .endianness = 1, };
static const struct regmap_config cs4234_regmap = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cs35l41.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c index 6b784a62df0ce..de6f96bd8daf4 100644 --- a/sound/soc/codecs/cs35l41.c +++ b/sound/soc/codecs/cs35l41.c @@ -1113,6 +1113,8 @@ static const struct snd_soc_component_driver soc_component_dev_cs35l41 = { .controls = cs35l41_aud_controls, .num_controls = ARRAY_SIZE(cs35l41_aud_controls), .set_sysclk = cs35l41_component_set_sysclk, + + .endianness = 1, };
static int cs35l41_handle_pdata(struct device *dev, struct cs35l41_platform_data *pdata)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cx2072x.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c index 0d3a00434c6d6..b35debb5818db 100644 --- a/sound/soc/codecs/cx2072x.c +++ b/sound/soc/codecs/cx2072x.c @@ -1527,6 +1527,7 @@ static const struct snd_soc_component_driver soc_codec_driver_cx2072x = { .num_dapm_widgets = ARRAY_SIZE(cx2072x_dapm_widgets), .dapm_routes = cx2072x_intercon, .num_dapm_routes = ARRAY_SIZE(cx2072x_intercon), + .endianness = 1, };
/*
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/lochnagar-sc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/lochnagar-sc.c b/sound/soc/codecs/lochnagar-sc.c index 54426a90bc0bf..54a8ba7ed3c20 100644 --- a/sound/soc/codecs/lochnagar-sc.c +++ b/sound/soc/codecs/lochnagar-sc.c @@ -212,12 +212,13 @@ static struct snd_soc_dai_driver lochnagar_sc_dai[] = { };
static const struct snd_soc_component_driver lochnagar_sc_driver = { - .non_legacy_dai_naming = 1, - .dapm_widgets = lochnagar_sc_widgets, .num_dapm_widgets = ARRAY_SIZE(lochnagar_sc_widgets), .dapm_routes = lochnagar_sc_routes, .num_dapm_routes = ARRAY_SIZE(lochnagar_sc_routes), + + .non_legacy_dai_naming = 1, + .endianness = 1, };
static int lochnagar_sc_probe(struct platform_device *pdev)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
As the core will now expand the formats to cover both endian types, remove the redundant manual specification of both.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/mt6351.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c index 5c0536eb1044f..d2cf4847eead1 100644 --- a/sound/soc/codecs/mt6351.c +++ b/sound/soc/codecs/mt6351.c @@ -282,12 +282,9 @@ static const struct snd_soc_dai_ops mt6351_codec_dai_ops = { .hw_params = mt6351_codec_dai_hw_params, };
-#define MT6351_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\ - SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE |\ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\ - SNDRV_PCM_FMTBIT_U24_LE | SNDRV_PCM_FMTBIT_U24_BE |\ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE |\ - SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE) +#define MT6351_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_U16_LE |\ + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_U24_LE |\ + SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_U32_LE)
static struct snd_soc_dai_driver mt6351_dai_driver[] = { { @@ -1448,6 +1445,7 @@ static const struct snd_soc_component_driver mt6351_soc_component_driver = { .num_dapm_widgets = ARRAY_SIZE(mt6351_dapm_widgets), .dapm_routes = mt6351_dapm_routes, .num_dapm_routes = ARRAY_SIZE(mt6351_dapm_routes), + .endianness = 1, };
static int mt6351_codec_driver_probe(struct platform_device *pdev)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
As the core will now expand the formats to cover both endian types, remove the redundant manual specification of both.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/mt6358.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c index 4c7b5d940799b..60b209efe52d1 100644 --- a/sound/soc/codecs/mt6358.c +++ b/sound/soc/codecs/mt6358.c @@ -2340,12 +2340,9 @@ static const struct snd_soc_dai_ops mt6358_codec_dai_ops = { .hw_params = mt6358_codec_dai_hw_params, };
-#define MT6358_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\ - SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE |\ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\ - SNDRV_PCM_FMTBIT_U24_LE | SNDRV_PCM_FMTBIT_U24_BE |\ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE |\ - SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE) +#define MT6358_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_U16_LE |\ + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_U24_LE |\ + SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_U32_LE)
static struct snd_soc_dai_driver mt6358_dai_driver[] = { { @@ -2433,6 +2430,7 @@ static const struct snd_soc_component_driver mt6358_soc_component_driver = { .num_dapm_widgets = ARRAY_SIZE(mt6358_dapm_widgets), .dapm_routes = mt6358_dapm_routes, .num_dapm_routes = ARRAY_SIZE(mt6358_dapm_routes), + .endianness = 1, };
static void mt6358_parse_dt(struct mt6358_priv *priv)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
As the core will now expand the formats to cover both endian types, remove the redundant manual specification of both.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/mt6359.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c index f8532aa7e4aa0..23709b180409c 100644 --- a/sound/soc/codecs/mt6359.c +++ b/sound/soc/codecs/mt6359.c @@ -2576,12 +2576,9 @@ static const struct snd_soc_dai_ops mt6359_codec_dai_ops = { .shutdown = mt6359_codec_dai_shutdown, };
-#define MT6359_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\ - SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE |\ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\ - SNDRV_PCM_FMTBIT_U24_LE | SNDRV_PCM_FMTBIT_U24_BE |\ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE |\ - SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE) +#define MT6359_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_U16_LE |\ + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_U24_LE |\ + SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_U32_LE)
static struct snd_soc_dai_driver mt6359_dai_driver[] = { { @@ -2739,6 +2736,7 @@ static const struct snd_soc_component_driver mt6359_soc_component_driver = { .num_dapm_widgets = ARRAY_SIZE(mt6359_dapm_widgets), .dapm_routes = mt6359_dapm_routes, .num_dapm_routes = ARRAY_SIZE(mt6359_dapm_routes), + .endianness = 1, };
static int mt6359_parse_dt(struct mt6359_priv *priv)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/mt6660.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/mt6660.c b/sound/soc/codecs/mt6660.c index c84a0b850f89a..ba11555796ad8 100644 --- a/sound/soc/codecs/mt6660.c +++ b/sound/soc/codecs/mt6660.c @@ -323,6 +323,7 @@ static const struct snd_soc_component_driver mt6660_component_driver = { .num_dapm_routes = ARRAY_SIZE(mt6660_component_dapm_routes),
.idle_bias_on = false, /* idle_bias_off = true */ + .endianness = 1, };
static int mt6660_component_aif_hw_params(struct snd_pcm_substream *substream,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/pcm3060.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/pcm3060.c b/sound/soc/codecs/pcm3060.c index 4e3bfb9fa4442..586ec8c7246ca 100644 --- a/sound/soc/codecs/pcm3060.c +++ b/sound/soc/codecs/pcm3060.c @@ -255,6 +255,7 @@ static const struct snd_soc_component_driver pcm3060_soc_comp_driver = { .num_dapm_widgets = ARRAY_SIZE(pcm3060_dapm_widgets), .dapm_routes = pcm3060_dapm_map, .num_dapm_routes = ARRAY_SIZE(pcm3060_dapm_map), + .endianness = 1, };
/* regmap */
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt1019.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt1019.c b/sound/soc/codecs/rt1019.c index d45d14fe5c427..f3f15fbe85d0e 100644 --- a/sound/soc/codecs/rt1019.c +++ b/sound/soc/codecs/rt1019.c @@ -515,7 +515,7 @@ static struct snd_soc_dai_driver rt1019_dai[] = { };
static const struct snd_soc_component_driver soc_component_dev_rt1019 = { - .probe = rt1019_probe, + .probe = rt1019_probe, .controls = rt1019_snd_controls, .num_controls = ARRAY_SIZE(rt1019_snd_controls), .dapm_widgets = rt1019_dapm_widgets, @@ -523,6 +523,7 @@ static const struct snd_soc_component_driver soc_component_dev_rt1019 = { .dapm_routes = rt1019_dapm_routes, .num_dapm_routes = ARRAY_SIZE(rt1019_dapm_routes), .non_legacy_dai_naming = 1, + .endianness = 1, };
static const struct regmap_config rt1019_regmap = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt9120.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt9120.c b/sound/soc/codecs/rt9120.c index 6e0d7cf0c8c92..cdf8ad2f23a43 100644 --- a/sound/soc/codecs/rt9120.c +++ b/sound/soc/codecs/rt9120.c @@ -178,6 +178,7 @@ static const struct snd_soc_component_driver rt9120_component_driver = { .num_dapm_widgets = ARRAY_SIZE(rt9120_dapm_widgets), .dapm_routes = rt9120_dapm_routes, .num_dapm_routes = ARRAY_SIZE(rt9120_dapm_routes), + .endianness = 1, };
static int rt9120_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/tlv320adc3xxx.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/tlv320adc3xxx.c b/sound/soc/codecs/tlv320adc3xxx.c index a5e9f80cfa321..82532ad00c3c8 100644 --- a/sound/soc/codecs/tlv320adc3xxx.c +++ b/sound/soc/codecs/tlv320adc3xxx.c @@ -1152,20 +1152,20 @@ static int adc3xxx_hw_params(struct snd_pcm_substream *substream, return i;
/* select data word length */ - switch (params_format(params)) { - case SNDRV_PCM_FORMAT_S16_LE: + switch (params_width(params)) { + case 16: iface_len = ADC3XXX_IFACE_16BITS; width = 16; break; - case SNDRV_PCM_FORMAT_S20_3LE: + case 20: iface_len = ADC3XXX_IFACE_20BITS; width = 20; break; - case SNDRV_PCM_FORMAT_S24_LE: + case 24: iface_len = ADC3XXX_IFACE_24BITS; width = 24; break; - case SNDRV_PCM_FORMAT_S32_LE: + case 32: iface_len = ADC3XXX_IFACE_32BITS; width = 32; break; @@ -1335,6 +1335,7 @@ static const struct snd_soc_component_driver soc_component_dev_adc3xxx = { .num_dapm_widgets = ARRAY_SIZE(adc3xxx_dapm_widgets), .dapm_routes = adc3xxx_intercon, .num_dapm_routes = ARRAY_SIZE(adc3xxx_intercon), + .endianness = 1, };
static const struct i2c_device_id adc3xxx_i2c_id[] = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied.
A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported. It is worth noting this changes the behaviour of S24_LE to use a word length of 24 rather than 32. This would appear to be a correction since the fact S24_LE is stored as 32 bits should not be presented over the bus.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/tscs454.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/tscs454.c b/sound/soc/codecs/tscs454.c index b34a8b5164848..38622bc247fc8 100644 --- a/sound/soc/codecs/tscs454.c +++ b/sound/soc/codecs/tscs454.c @@ -3120,18 +3120,17 @@ static int set_aif_sample_format(struct snd_soc_component *component, unsigned int width; int ret;
- switch (format) { - case SNDRV_PCM_FORMAT_S16_LE: + switch (snd_pcm_format_width(format)) { + case 16: width = FV_WL_16; break; - case SNDRV_PCM_FORMAT_S20_3LE: + case 20: width = FV_WL_20; break; - case SNDRV_PCM_FORMAT_S24_3LE: + case 24: width = FV_WL_24; break; - case SNDRV_PCM_FORMAT_S24_LE: - case SNDRV_PCM_FORMAT_S32_LE: + case 32: width = FV_WL_32; break; default: @@ -3326,6 +3325,7 @@ static const struct snd_soc_component_driver soc_component_dev_tscs454 = { .num_dapm_routes = ARRAY_SIZE(tscs454_intercon), .controls = tscs454_snd_controls, .num_controls = ARRAY_SIZE(tscs454_snd_controls), + .endianness = 1, };
#define TSCS454_RATES SNDRV_PCM_RATE_8000_96000
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. The i2s_rx component receives audio over an I2S DAI and as such should have endianness applied.
A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/cros_ec_codec.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c index 9b92e1a0d1a3a..8b0a9c788a264 100644 --- a/sound/soc/codecs/cros_ec_codec.c +++ b/sound/soc/codecs/cros_ec_codec.c @@ -232,11 +232,11 @@ static int i2s_rx_hw_params(struct snd_pcm_substream *substream, if (params_rate(params) != 48000) return -EINVAL;
- switch (params_format(params)) { - case SNDRV_PCM_FORMAT_S16_LE: + switch (params_width(params)) { + case 16: depth = EC_CODEC_I2S_RX_SAMPLE_DEPTH_16; break; - case SNDRV_PCM_FORMAT_S24_LE: + case 24: depth = EC_CODEC_I2S_RX_SAMPLE_DEPTH_24; break; default: @@ -387,6 +387,7 @@ static const struct snd_soc_component_driver i2s_rx_component_driver = { .num_dapm_widgets = ARRAY_SIZE(i2s_rx_dapm_widgets), .dapm_routes = i2s_rx_dapm_routes, .num_dapm_routes = ARRAY_SIZE(i2s_rx_dapm_routes), + .endianness = 1, };
static void *wov_map_shm(struct cros_ec_codec_priv *priv,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SLIMbus DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/wcd934x.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/wcd934x.c b/sound/soc/codecs/wcd934x.c index 6298ebe96e941..f56907d0942db 100644 --- a/sound/soc/codecs/wcd934x.c +++ b/sound/soc/codecs/wcd934x.c @@ -5847,6 +5847,7 @@ static const struct snd_soc_component_driver wcd934x_component_drv = { .dapm_routes = wcd934x_audio_map, .num_dapm_routes = ARRAY_SIZE(wcd934x_audio_map), .set_jack = wcd934x_codec_set_jack, + .endianness = 1, };
static int wcd934x_codec_parse_data(struct wcd934x_codec *wcd)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SLIMbus DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/wcd9335.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/wcd9335.c b/sound/soc/codecs/wcd9335.c index 1e60db4056ada..617a36a89dfed 100644 --- a/sound/soc/codecs/wcd9335.c +++ b/sound/soc/codecs/wcd9335.c @@ -4924,6 +4924,7 @@ static const struct snd_soc_component_driver wcd9335_component_drv = { .num_dapm_widgets = ARRAY_SIZE(wcd9335_dapm_widgets), .dapm_routes = wcd9335_audio_map, .num_dapm_routes = ARRAY_SIZE(wcd9335_audio_map), + .endianness = 1, };
static int wcd9335_probe(struct wcd9335_codec *wcd)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt700.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt700.c b/sound/soc/codecs/rt700.c index e61a8257bf647..af32295fa9b93 100644 --- a/sound/soc/codecs/rt700.c +++ b/sound/soc/codecs/rt700.c @@ -853,6 +853,7 @@ static const struct snd_soc_component_driver soc_codec_dev_rt700 = { .dapm_routes = rt700_audio_map, .num_dapm_routes = ARRAY_SIZE(rt700_audio_map), .set_jack = rt700_set_jack_detect, + .endianness = 1, };
static int rt700_set_sdw_stream(struct snd_soc_dai *dai, void *sdw_stream,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt711.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt711.c b/sound/soc/codecs/rt711.c index ea25fd58d43a9..9838fb4d5b9c0 100644 --- a/sound/soc/codecs/rt711.c +++ b/sound/soc/codecs/rt711.c @@ -950,6 +950,7 @@ static const struct snd_soc_component_driver soc_codec_dev_rt711 = { .num_dapm_routes = ARRAY_SIZE(rt711_audio_map), .set_jack = rt711_set_jack_detect, .remove = rt711_remove, + .endianness = 1, };
static int rt711_set_sdw_stream(struct snd_soc_dai *dai, void *sdw_stream,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt711-sdca.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt711-sdca.c b/sound/soc/codecs/rt711-sdca.c index bdb1375f03388..57629c18db384 100644 --- a/sound/soc/codecs/rt711-sdca.c +++ b/sound/soc/codecs/rt711-sdca.c @@ -1208,6 +1208,7 @@ static const struct snd_soc_component_driver soc_sdca_dev_rt711 = { .num_dapm_routes = ARRAY_SIZE(rt711_sdca_audio_map), .set_jack = rt711_sdca_set_jack_detect, .remove = rt711_sdca_remove, + .endianness = 1, };
static int rt711_sdca_set_sdw_stream(struct snd_soc_dai *dai, void *sdw_stream,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt715.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt715.c b/sound/soc/codecs/rt715.c index a64d11a747513..418e006b19ef5 100644 --- a/sound/soc/codecs/rt715.c +++ b/sound/soc/codecs/rt715.c @@ -745,6 +745,7 @@ static const struct snd_soc_component_driver soc_codec_dev_rt715 = { .num_dapm_widgets = ARRAY_SIZE(rt715_dapm_widgets), .dapm_routes = rt715_audio_map, .num_dapm_routes = ARRAY_SIZE(rt715_audio_map), + .endianness = 1, };
static int rt715_set_sdw_stream(struct snd_soc_dai *dai, void *sdw_stream,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt715-sdca.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt715-sdca.c b/sound/soc/codecs/rt715-sdca.c index bfa536bd71960..5857d08663073 100644 --- a/sound/soc/codecs/rt715-sdca.c +++ b/sound/soc/codecs/rt715-sdca.c @@ -765,6 +765,7 @@ static const struct snd_soc_component_driver soc_codec_dev_rt715_sdca = { .num_dapm_widgets = ARRAY_SIZE(rt715_sdca_dapm_widgets), .dapm_routes = rt715_sdca_audio_map, .num_dapm_routes = ARRAY_SIZE(rt715_sdca_audio_map), + .endianness = 1, };
static int rt715_sdca_set_sdw_stream(struct snd_soc_dai *dai, void *sdw_stream,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt1308-sdw.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt1308-sdw.c b/sound/soc/codecs/rt1308-sdw.c index 1ef836a68a56f..1c11b42dd76e0 100644 --- a/sound/soc/codecs/rt1308-sdw.c +++ b/sound/soc/codecs/rt1308-sdw.c @@ -615,6 +615,7 @@ static const struct snd_soc_component_driver soc_component_sdw_rt1308 = { .num_dapm_widgets = ARRAY_SIZE(rt1308_dapm_widgets), .dapm_routes = rt1308_dapm_routes, .num_dapm_routes = ARRAY_SIZE(rt1308_dapm_routes), + .endianness = 1, };
static const struct snd_soc_dai_ops rt1308_aif_dai_ops = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/rt1316-sdw.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt1316-sdw.c b/sound/soc/codecs/rt1316-sdw.c index c66d7b20cb4dd..60baa9ff19070 100644 --- a/sound/soc/codecs/rt1316-sdw.c +++ b/sound/soc/codecs/rt1316-sdw.c @@ -597,6 +597,7 @@ static const struct snd_soc_component_driver soc_component_sdw_rt1316 = { .num_dapm_widgets = ARRAY_SIZE(rt1316_dapm_widgets), .dapm_routes = rt1316_dapm_routes, .num_dapm_routes = ARRAY_SIZE(rt1316_dapm_routes), + .endianness = 1, };
static const struct snd_soc_dai_ops rt1316_aif_dai_ops = {
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/wcd938x.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/wcd938x.c b/sound/soc/codecs/wcd938x.c index 898b2887fa637..c1b61b997f696 100644 --- a/sound/soc/codecs/wcd938x.c +++ b/sound/soc/codecs/wcd938x.c @@ -4168,6 +4168,7 @@ static const struct snd_soc_component_driver soc_codec_dev_wcd938x = { .dapm_routes = wcd938x_audio_map, .num_dapm_routes = ARRAY_SIZE(wcd938x_audio_map), .set_jack = wcd938x_codec_set_jack, + .endianness = 1, };
static void wcd938x_dt_parse_micbias_info(struct device *dev, struct wcd938x_priv *wcd)
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/wsa881x.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/wsa881x.c b/sound/soc/codecs/wsa881x.c index 616b26c70c3b2..f3a56f3ce4871 100644 --- a/sound/soc/codecs/wsa881x.c +++ b/sound/soc/codecs/wsa881x.c @@ -1066,6 +1066,7 @@ static const struct snd_soc_component_driver wsa881x_component_drv = { .num_dapm_widgets = ARRAY_SIZE(wsa881x_dapm_widgets), .dapm_routes = wsa881x_audio_map, .num_dapm_routes = ARRAY_SIZE(wsa881x_audio_map), + .endianness = 1, };
static int wsa881x_update_status(struct sdw_slave *slave,
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied.
Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com --- sound/soc/codecs/sdw-mockup.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/sdw-mockup.c b/sound/soc/codecs/sdw-mockup.c index 7c612aaf31c75..288b55368d2a4 100644 --- a/sound/soc/codecs/sdw-mockup.c +++ b/sound/soc/codecs/sdw-mockup.c @@ -38,6 +38,7 @@ static void sdw_mockup_component_remove(struct snd_soc_component *component) static const struct snd_soc_component_driver snd_soc_sdw_mockup_component = { .probe = sdw_mockup_component_probe, .remove = sdw_mockup_component_remove, + .endianness = 1, };
static int sdw_mockup_set_sdw_stream(struct snd_soc_dai *dai, void *sdw_stream,
On Wed, 4 May 2022 18:08:27 +0100, Charles Keepax wrote:
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.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[01/38] ASoC: soc-component: Add comment for the endianness flag commit: 5c832efdbf8651e2800a0169a870786bd85ee230 [02/38] ASoC: atmel-pdmic: Remove endianness flag on pdmic component commit: 52857c3baa0e5ddeba7b2c84e56bb71c9674e048 [03/38] ASoC: atmel-classd: Remove endianness flag on class d component commit: 0104d52a6a69b06b0e8167f7c1247e8c76aca070 [04/38] ASoC: cs4270: Remove redundant big endian formats commit: 99a4b91ae967d22158d3f4d4f9564ac63295930e [05/38] ASoC: cs42l51: Remove redundant big endian formats commit: 2bf1e87b9338e8986f78b675a201f7f02a3c43d5 [06/38] ASoC: cs4349: Remove redundant big endian formats commit: 8a85e2fca6476968f8558163b95c2df38930e523 [07/38] ASoC: hdmi-codec: Remove redundant big endian formats commit: 6edfed8f2cce012e87277c8a1786a2de7d5cae35 [08/38] ASoC: sta32x: Remove redundant big endian formats commit: a9b5bef89a68ec45ec198e2d316cd8b9b9bf6655 [09/38] ASoC: sta350: Remove redundant big endian formats commit: 2ac5b98284b3744514dcf75909a3bb3c3d5ab7d4 [10/38] ASoC: hdac_hda: Add endianness flag in snd_soc_component_driver commit: 1324cd8d14f06ff933c825ca5a51139604bc6b97 [11/38] ASoC: max98504: Add endianness flag in snd_soc_component_driver commit: a0556e3ad0c40359d5fa3dc72de14ad2efb9dfda [12/38] ASoC: adau1372: Add endianness flag in snd_soc_component_driver commit: ac6f26c18f2d231e4006b2f12e0e46aeb6430cbb [13/38] ASoC: cs4234: Add endianness flag in snd_soc_component_driver commit: de88ca441a3066668cae62741a52042f0273d364 [14/38] ASoC: cs35l41: Add endianness flag in snd_soc_component_driver commit: f0688b567fb88ba7636e87a5daed8a175275aa2e [15/38] ASoC: cx2072x: Add endianness flag in snd_soc_component_driver commit: 1c3cbc1dacecdb427b693992f1a05b5837b33a70 [16/38] ASoC: lochnagar: Add endianness flag in snd_soc_component_driver commit: ba7328f31cd508964cf2a0b62edfb0b8339c1e77 [17/38] ASoC: mt6351: Add endianness flag in snd_soc_component_driver commit: 39723d3493edd60ed41f9891391d4335b65547b9 [18/38] ASoC: mt6358: Add endianness flag in snd_soc_component_driver commit: a5f956e221e92a0e93f036651cdab80a2eb6bb18 [19/38] ASoC: mt6359: Add endianness flag in snd_soc_component_driver commit: d990af7422761fa58713e2f56664f7c8c2bf6383 [20/38] ASoC: mt6660: Add endianness flag in snd_soc_component_driver commit: 8044910bc28e06e0dc0194f160118e00964d8b6a [21/38] ASoC: pcm3060: Add endianness flag in snd_soc_component_driver commit: f0488349c1183a3a524434958d909f38628e1d4b [22/38] ASoC: rt1019: Add endianness flag in snd_soc_component_driver commit: 3816069538d54a9c45345f45b569bb2e42846561 [23/38] ASoC: rt9120: Add endianness flag in snd_soc_component_driver commit: 80827c123f2a5f5e0fbcc6cb33b102666acec08e [24/38] ASoC: tlv320adc3xxx: Add endianness flag in snd_soc_component_driver commit: f5e0084b5beed00f11fb7cd1e90b8b91fcd06e9f [25/38] ASoC: tscs454: Add endianness flag in snd_soc_component_driver commit: ff69ec96b87dccb3a29edef8cec5d4fefbbc2055 [26/38] ASoC: cros_ec_codec: Add endianness flag in i2s_rx_component_driver commit: cfacadbdca23f1a8d9c5db2a8f1bb3c6a1dd4dd8 [27/38] ASoC: wcd934x: Add endianness flag in snd_soc_component_driver commit: 6b1b1579aa9879bbf729f75c386cb3c932b1f5b3 [28/38] ASoC: wcd9335: Add endianness flag in snd_soc_component_driver commit: e230b1b1819f2941b8b31174a3839388641920f8 [29/38] ASoC: rt700: Add endianness flag in snd_soc_component_driver commit: 4982fc1def317febc74398e839dab2a4059692fa [30/38] ASoC: rt711: Add endianness flag in snd_soc_component_driver commit: 33f06beac3ade10834a82ad4105dcd91d4b00d61 [31/38] ASoC: rt711-sdca: Add endianness flag in snd_soc_component_driver commit: 3e50a5001055d79c04ea1c79fe4b4ff937a3339c [32/38] ASoC: rt715: Add endianness flag in snd_soc_component_driver commit: 1a6750123b5d2f05200fb55633b32c81c840f681 [33/38] ASoC: rt715-sdca: Add endianness flag in snd_soc_component_driver commit: e8f4ddcb33de9b1eaf74d150234a2cd07dddcfad [34/38] ASoC: rt1308-sdw: Add endianness flag in snd_soc_component_driver commit: 9b536b34693c8ab9caf0612bf4fdbc09fd51f126 [35/38] ASoC: rt1316-sdw: Add endianness flag in snd_soc_component_driver commit: 7fb6f48351c896fc6c18f9d3e7b0b4fb689e73cb [36/38] ASoC: wcd938x: Add endianness flag in snd_soc_component_driver commit: ff7f9aa523d1699663cbeec4b0e69aaeab5e6bba [37/38] ASoC: wsa881x: Add endianness flag in snd_soc_component_driver commit: 96bc59d097047a8a013cb77b2a1215cc4877fa96 [38/38] ASoC: sdw-mockup: Add endianness flag in snd_soc_component_driver commit: e2d61f6255a26a09d4fe2458fa93a33a71db1024
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (3)
-
Charles Keepax -
Kirill Marinushkin -
Mark Brown