aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-09ASoC: wsa881x: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: wcd938x: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt1316-sdw: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt1308-sdw: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt715-sdca: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt715: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt711-sdca: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt711: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt700: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: wcd9335: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SLIMbus DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: wcd934x: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a SLIMbus DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cros_ec_codec: Add endianness flag in i2s_rx_component_driverCharles Keepax1-3/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: tscs454: Add endianness flag in snd_soc_component_driverCharles Keepax1-6/+6
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: tlv320adc3xxx: Add endianness flag in snd_soc_component_driverCharles Keepax1-5/+6
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt9120: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: rt1019: Add endianness flag in snd_soc_component_driverCharles Keepax1-1/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: pcm3060: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: mt6660: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: mt6359: Add endianness flag in snd_soc_component_driverCharles Keepax1-6/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: mt6358: Add endianness flag in snd_soc_component_driverCharles Keepax1-6/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: mt6351: Add endianness flag in snd_soc_component_driverCharles Keepax1-6/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: lochnagar: Add endianness flag in snd_soc_component_driverCharles Keepax1-2/+3
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cx2072x: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cs35l41: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cs4234: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: adau1372: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: max98504: Add endianness flag in snd_soc_component_driverCharles Keepax1-0/+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 a PDM DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: hdac_hda: Add endianness flag in snd_soc_component_driverCharles Keepax1-7/+8
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: sta350: Remove redundant big endian formatsCharles Keepax1-6/+3
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: sta32x: Remove redundant big endian formatsCharles Keepax1-6/+3
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: hdmi-codec: Remove redundant big endian formatsCharles Keepax1-10/+5
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cs4349: Remove redundant big endian formatsCharles Keepax1-6/+3
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cs42l51: Remove redundant big endian formatsCharles Keepax1-5/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: cs4270: Remove redundant big endian formatsCharles Keepax1-12/+3
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: atmel-classd: Remove endianness flag on class d componentCharles Keepax1-1/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: atmel-pdmic: Remove endianness flag on pdmic componentCharles Keepax1-1/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-09ASoC: soc-component: Add comment for the endianness flagCharles Keepax1-0/+9
Add a comment to make the purpose of the endianness flag on the snd_soc_component structure more clear. Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-05ASoC: SOF: IPC4: Introduce message handling functionalityMark Brown4-1/+1070
Merge series from Peter Ujfalusi <[email protected]>: 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).
2022-05-05ASoC: cs43130: Re-use generic struct u16_fractAndy Shevchenko2-83/+84
Instead of custom data type re-use generic struct u16_fract. No changes intended. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-05ASoC: fsl_micfil: fix the naming style for mask definitionShengjiu Wang1-4/+4
Remove the _SHIFT for the mask definition. Fixes: 17f2142bae4b ("ASoC: fsl_micfil: use GENMASK to define register bit fields") Signed-off-by: Shengjiu Wang <[email protected]> Acked-by: Sascha Hauer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-05ASoC: ti: davinci-mcasp: Add dma-type for bcdmaJayesh Choudhary1-0/+2
Set DMA type for ti-bcdma controller for AM62-SK. Acked-by: Peter Ujfalusi <[email protected]> Signed-off-by: Jayesh Choudhary <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-05ASoC: SOF: ipc4: Add support for mandatory message handling functionalityPeter Ujfalusi3-1/+607
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 <[email protected]> Signed-off-by: Rander Wang <[email protected]> Co-developed-by: Bard Liao <[email protected]> Signed-off-by: Bard Liao <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-05ASoC: SOF: Add initial header file for ipc4Peter Ujfalusi1-0/+460
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 <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-05ASoC: SOF: Add rx_data pointer to snd_sof_ipc_msg structPeter Ujfalusi1-0/+3
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: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-04ASoC: cs35l45: Enable BOOSTRichard Fitzgerald1-4/+0
Do not disable the boost converter during probe. The silicon contains functional default tunings so the boost converter can be left at the chip default enabled state. Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-04ASoC: soc-generic-dmaengine-pcm: Use default config when none is givenSascha Hauer1-32/+25
snd_dmaengine_pcm_register() can be passed a NULL pointer for the config which means that the we have to test for pcm->config being non NULL before accessing it. Make the code more straight forward by providing a default config when none is passed. With this pcm->config is never NULL and we can skip all the if (pcm->config) tests. Signed-off-by: Sascha Hauer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-04ASoC: SOF: ipc3: Remove the ipc3-ops.h header filePeter Ujfalusi9-27/+9
Only the main IPC ops struct should be visible outside of IPC3 code to make sure that the code is correctly abstracted. Instead of keeping the ipc3-ops.h with only the high level ops struct declaration, put the ipc3_ops to sof-priv.h and move all other ops struct declaration into ipc3-priv.h New IPC implementation should follow this route: the main IPC ops should be declared in sof-priv.h and no other IPC version related header be used for generic code. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-04ASoC: Pull in fixesMark Brown22-70/+124
Cleanups for the dmaengine code build on top of current fixes.
2022-05-03ASoC: tpa6130: use i2c_match_id and simple i2c probeStephen Kitt1-10/+11
As part of the ongoing i2c transition to the simple probe ("probe_new"), this patch uses i2c_match_id to retrieve the driver_data for the probed device. The id parameter is thus no longer necessary and the simple probe can be used instead. The i2c id table is moved up before the probe function, as suggested by Wolfram Sang. Signed-off-by: Stephen Kitt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-05-03ASoC: rk3328: fix disabling mclk on pclk probe failureNicolas Frattaroli1-1/+1
If preparing/enabling the pclk fails, the probe function should unprepare and disable the previously prepared and enabled mclk, which it doesn't do. This commit rectifies this. Fixes: c32759035ad2 ("ASoC: rockchip: support ACODEC for rk3328") Signed-off-by: Nicolas Frattaroli <[email protected]> Reviewed-by: Katsuhiro Suzuki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.