'imx_unregister_action' uses 'sdev->pdata->hw_pdata' to fetch the pointer
to the common data structure. As such, if 'sdev->pdata->hw_pdata' is not
set before adding 'imx_unregister_action' to the devres list, we risk
derefrencing a NULL pointer if any of the calls between
'devm_add_action_or_reset' and 'sdev->pdata->hw_pdata = common' fails.
Set 'sdev->pdata->hw_pdata' to point to 'common' as soon as 'common' is
allocated.
Fixes: 651e0ed391 (" ASoC: SOF: imx: introduce more common structures and functions")
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20250211225018.2642-1-laurentiumihalcea111@gmail.com
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When decimation filter bypass mode is enabled, PDM data can be
written into FIFO directly without any processing.
The interface of this mode is DSD big endian format, when
user needs this format, then this mode is enabled.
This mode is only for the i.MX943 platform currently.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20250206030306.2618620-1-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Alexey Charkov <alchark@gmail.com>:
RK3588(s) uses a several SPDIF transmitters which are software
compatible with those found in RK3568. This series adds the required
device tree nodes in SoC .dtsi and enables the dedicated optical
SPDIF output on the H96 Max V58.
Note that only SPDIF 0/1 are meant as externally connected outputs,
while SPDIF 2/3/4/5 are internally routed to the various display
encoders inside the SoC. Thus, using SPDIF 0/1 only requires their
device tree nodes to be enabled (provided that the signal is routed
somewhere usable on the board itself), while the rest rely on driver
support on the display connector side and are therefore not touched
here.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Alexey Charkov (3):
dt-bindings: ASoC: rockchip: Add compatible for RK3588 SPDIF
arm64: dts: rockchip: Add SPDIF nodes to RK3588(s) device trees
arm64: dts: rockchip: Enable SPDIF output on H96 Max V58
.../devicetree/bindings/sound/rockchip-spdif.yaml | 4 ++
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 64 ++++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi | 30 ++++++++++
.../arm64/boot/dts/rockchip/rk3588-h96-max-v58.dts | 24 ++++++++
4 files changed, 122 insertions(+)
---
base-commit: 4ec376748558ba132a2a49513acd3b08774384e3
change-id: 20250109-rk3588-spdif-e49aa49145d3
Best regards,
--
Alexey Charkov <alchark@gmail.com>
Using of_property_read_bool() for non-boolean properties has been
deprecated in favour of of_property_present() and since commit
c141ecc3ce ("of: Warn when of_property_read_bool() is used on
non-boolean properties") this also generates a warning:
OF: /soc@0/soundwire@3330000/wcd9380-tx@0,3: Read of boolean property 'qcom,tx-port-mapping' with a value.
Switch to using of_property_present() to look for "qcom,tx-port-mapping"
properties.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://patch.msgid.link/20250210132128.7734-1-johan+linaro@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
The MIPI SoundWire Device Class for Audio (SDCA) specification defines
most details of the hardware in ACPI using the MIPI Discovery and
Configuration (DisCo) specification. This patch chain adds support for
parsing most of this information into the kernel such that future work
can make use of it to construct CODEC devices and soundcards.
The most notable outstanding work here, is parsing the separate
properties for the Control Numbers (roughly equivalent to channels)
within an individual Control. The separate Control Numbers are
supported but currently only the scheme were a single default etc. is
supplied for all. This should not be super hard to add in the future
but isn't currently required by any of the hardware I am working to
support.
Merge series from Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>:
A rather aggressive but arguably much needed refactorization of the SOF
imx drivers. The refactorization is meant to address the code duplication
in the imx drivers and decrease the coding effort required for introducing
a new imx platform.
After refactorization and imx95 introduction, only two drivers remain:
imx8 (meant for the imx8 series: imx8 (imx8qm), imx8x (imx8qxp), imx8m,
and imx8ulp) and imx9 (meant for the imx9 series: imx95 (for now)).
The series also includes the introduction of the imx95 driver.
Merge series from Vijendar Mukunda <Vijendar.Mukunda@amd.com>:
This patch series includes the below changes
- Refactor existing ACP6.3 platform ACP PCI driver, SoundWire
DMA driver code.
- Add Audio IO support for ACP7.0 and ACP7.1 platforms for
SoundWire IO and ACP PDM controller combination.
- Add SoundWire generic machine driver changes for legacy stack
(No DSP enabled) for ACP7.0 & ACP7.1 platforms.
- Add SoundWire machines for ACP7.0 & ACP7.1 platforms.
Within SDCA collections of Channels are referred to as Clusters, each
Channel within a Cluster can have various properties attached to it.
For example a stereo audio stream, would have a Cluster with 2 Channels
one marked as left and the other as right. Various Clusters are
specified in DisCo/ACPI and controls then allow the class driver to
select between these channel configurations. Add support for parsing
these Cluster definitions.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Each SDCA Entity will contain a number of Controls, these are
basically equivalent to registers. Although a single Control will only
ever contain a single field. Some of these would map directly to ALSA
controls once more of the SDCA class driver is implemented. These
controls are parsed out of the DisCo ACPI tables.
One small todo here is that each Control can have multiple
sub-entries (Control Numbers), these are typically used to represent
channels. Whilst support is present for these, currently the
ACPI properties that would allow differing defaults for each channel
are not parsed. But there is nothing here that should prevent that
being added in the future.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add SOF support for the imx95 chip. Although the support is just
for the imx95 chip, the driver is intended for all chips in the imx9
family.
Note that the imx95 support could have just as easily been added
to the imx8 platform driver but a new platform driver was created
because the intention is to keep the families in separate drivers.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20250207162246.3104-8-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The definition of 'struct sof_dev_desc' has the following properties
for imx chips:
1) FW path is the same for all chips.
2) Topology path is the same for all chips.
3) FW name can be written as: "sof-${machine_name}.ri"
4) IPC3 is the only supported protocol
The structure takes quite a few lines of code. Since the intention
is to add support for more imx8 chips in the same driver, we need
to try and reduce the number of lines taken by information that's
not particularly useful. As such, we can use 'IMX_SOF_DEV_DESC()'
to reduce the declaration of the structure to just one line. The
only information that's particularly useful can be seen from the
parameters of the macro.
Of course, if any of the assumptions don't apply anymore, driver
writers can simply declare the 'struct sof_dev_desc' the "old
fashioned way". No reason to make the macro suit multiple needs.
The same logic applies to the array of 'struct snd_soc_dai_driver'.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20250207162246.3104-4-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The common interface for imx chips (defined in imx-common.c) contains the
definitions for a lot of functions required by the SOF core. As such, the
platform driver can just use the common definitions instead of duplicating
code by re-defining aforementioned functions.
Make the transition to the new common interface. This consists of:
1) Removing unneeded functions, which are already defined in the
common interface.
2) Defining some chip-specific operations/structures required by the
interface to work.
3) Dropping structure definitions that are no longer needed.
4) Adapting some existing functions to the new interface.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20250207162246.3104-3-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
