- 09 May, 2022 33 commits
-
-
Charles Keepax authored
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> Link: https://lore.kernel.org/r/20220504170905.332415-34-ckeepax@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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: 1dfdbe73 ("ASoC: atmel-classd: remove codec component") Signed-off-by:
-
Charles Keepax authored
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: f3c66807 ("ASoC: atmel-pdmic: remove codec component") Signed-off-by:
-
Charles Keepax authored
Add a comment to make the purpose of the endianness flag on the snd_soc_component structure more clear. Signed-off-by:
-
- 05 May, 2022 7 commits
-
-
Mark Brown authored
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: The series adds the basic IPC4 message handling code, implementing the ipc callbacks. Due to the difference between IPC3 and IPC4 messaging we need to introduce new message container for IPC4, but the SOF internal callbacks and structures can be kept as they were and leaving it for the IPC specific code to handle the differences. The series provides the foundation for both lowe level (sound/soc/sof/intel) and high level IPC4 implementation (topologies, firmware loading, control handling, etc).
-
Andy Shevchenko authored
Instead of custom data type re-use generic struct u16_fract. No changes intended. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Shengjiu Wang authored
Remove the _SHIFT for the mask definition. Fixes: 17f2142b ("ASoC: fsl_micfil: use GENMASK to define register bit fields") Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/1651736047-28809-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by:
-
Jayesh Choudhary authored
Set DMA type for ti-bcdma controller for AM62-SK. Acked-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by:
Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by:
Jai Luthra <j-luthra@ti.com> Link: https://lore.kernel.org/r/20220505111226.29217-1-j-luthra@ti.comSigned-off-by:
-
Peter Ujfalusi authored
Introduce the initial and mandatory IPC ops support for IPC4 to enable IPC communication with this new IPC protocol. This patch implements the following ops: tx_msg, rx_msg, set_get_data and get_reply. Co-developed-by:
Rander Wang <rander.wang@intel.com> Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220505094818.10346-4-peter.ujfalusi@linux.intel.comSigned-off-by:
-
Peter Ujfalusi authored
The header file contains essential structure definitions, description of bit fields and bits in the ipc4 header and an internally used ipc4 message container definition. Signed-off-by:
-
Peter Ujfalusi authored
The rx_data pointer can be used by IPC implementations to pass the received message (or part of the message, like the header) from platform code to generic, high level IPC code. IPC4 is going to be the first user of this as its implementation on Intel platforms detaches the header and payload and the rx cannot be handled in a similar way as it is implemented for ipc3. If the rx_data is dynamically allocated, it is up to the platform code to free it up. After the message reception handling (rx_msg ops) returned, the pointer via the msg->rx_data should be considered as invalid. Signed-off-by:
-
