When `devm_add_action_or_reset()` fails, it is due to a failed memory
allocation and will thus return `-ENOMEM`. `dev_err_probe()` doesn't do
anything when error is `-ENOMEM`. Therefore, remove the useless call to
`dev_err_probe()` when `devm_add_action_or_reset()` fails, and just
return the value instead.
Signed-off-by: Waqar Hameed <waqar.hameed@axis.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/pndpldam7tf.a.out@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the DSP core from i.MX8QM/i.MX8QXP is able to operate while the
firmware image is being loaded. Because of this, the DSP may change the
content of the firmware data just after it was loaded, thus leading to the
data having unexpected values when the DSP is reset (via run()).
Fix this by implementing the core_shutdown() operation that will put the
DSP in stall during suspend(). The stall will be removed during the run()
opertion, thus guaranteeing that the DSP core will not be able to run
while the firmware image is being loaded.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20250613194310.1128733-1-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DSP on i.MX8MP doesn't have a direct reset line so according to hardware
design team in order to handle assert/deassert/reset functionality we
need to use a combination of control bits from two modules. Audio block
control module for Run/Stall control of the DSP and DAP module in order
to do software reset.
In a first step, for i.MX8MP we are switching on using the reset
controller API to handle the DSP Run/Stall bits i.MX8MP. This comes with
the advantage of offering a better probe ordering and a more natural way
of abstracting the Audio block control bits.
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20250505114251.57018-1-daniel.baluta@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
'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>
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>
Merge series from Daniel Baluta <daniel.baluta@nxp.com>:
We introduce SOF support for new board revisions for i.MX8MP/QM/QXP
which wrt audio they replace wm8960 codec with wm8962.
Also add support for cs42888 codec on i.MX8QM/8QXP baseboard.
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all drivers below sound/soc to use .remove(), with the eventual
goal to drop struct platform_driver::remove_new(). As .remove() and
.remove_new() have the same prototypes, conversion is done by just
changing the structure member name in the driver initializer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20240909151230.909818-2-u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
According to Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
fsl,dsp-ctrl is a phandle to syscon block so we need to use correct
function to retrieve it.
Currently there is no SOF DSP DTS merged into mainline so there is no
need to support the old way of retrieving the dsp control node.
Fixes: 9ba23717b2 ("ASoC: SOF: imx8m: Implement DSP start")
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20240715151653.114751-1-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
*-objs suffix is reserved rather for (user-space) host programs while
usually *-y suffix is used for kernel drivers (although *-objs works
for that purpose for now).
Let's correct the old usages of *-objs in Makefiles.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240507155540.24815-25-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The sof imx pcm device is a device which should support
double buffering.
Found this issue with pipewire. When there is no
SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will
set headroom to be zero, and because sof pcm device
don't support residue report, when the latency setting
is small, the "delay" always larger than "target" in
alsa-pcm.c, that reading next period data is not
scheduled on time.
With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire
will select a smaller period size for device, then
the task of reading next period data will be scheduled
on time.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1703669263-13832-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
The SOF platform drivers all use either sof_of_remove() or
sof_acpi_remove() which both return zero unconditionally. Change these
functions to return void and the drivers to use .remove_new(). There is
no semantical change.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20231009155945.285537-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The new IPC4 version is only supported by Intel platforms, iMX, AMD and
MediaTek only uses the standard SOF IPC.
There is no need for these platforms to build kernel support for IPC4 as
it is just dead code for them.
SND_SOC_SOF_IPC3 and SND_SOC_SOF_INTEL_IPC4 is introduced to allow compile
time selection and exclusion of IPC implementations.
To avoid randconfig failures add also support for runtime selection of
the IPC ops in ipc.c based on sdev->pdata->ipc_type
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220614075618.28605-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
