summaryrefslogtreecommitdiff
path: root/sound/soc/sof/core.c
AgeCommit message (Collapse)Author
2020-07-08ASoC: SOF: core: fix null-ptr-deref bug during device removalRanjani Sridharan
The DSP should be notified for device removal only if the probe was successful. Fixes the following KASAN bug: BUG: KASAN: null-ptr-deref in sof_ipc_tx_message+0x80/0x160 [snd_sof] Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200707204027.114169-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-18ASoC: SOF: inform DSP that driver is going to be removedMarcin Rajwa
This patch invokes the DSP power down notifier to inform DSP that driver is going to be removed. The module removal entails DSP power down, disabling of IRQs and more. Therefore it is highly recommended to inform the DSP about this upcoming event. Due to hardware limitations on some Intel platforms it is necessary to power gate all LPSRAM banks that were enabled prior to controller reset. Otherwise, an attempt to write LPSRAM control registers may have no effect. Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20200515135958.17511-4-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-11ASoC: SOF: core: fix error return code in sof_probe_continue()Wei Yongjun
Fix to return negative error code -ENOMEM from the IPC init error handling case instead of 0, as done elsewhere in this function. Fixes: c16211d6226d ("ASoC: SOF: Add Sound Open Firmware driver core") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200509093337.78897-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-01ASoC: SOF/Intel: clarify SPDX license with GPL-2.0-onlyPierre-Louis Bossart
Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only tag. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20200501145850.15178-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-18ASoC: SOF: Generic probe compress operationsCezary Rojewski
Define system-agnostic probe compress flow which serves as a base for actual, hardware-dependent implementations. As per firmware spec, maximum of one extraction stream is allowed, while for injection, there can be plenty. Apart from probe_pointer, all probe compress operations are mandatory. Copy operation is defined as unified as its flow should be shared across all SOF systems. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200218143924.10565-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-11ASoC: SOF: Move DSP power state transitions to platform-specific opsRanjani Sridharan
The DSP device substates such as D0I0/D0I3 are platform-specific. Therefore, the d0_substate field of struct snd_sof_dev is replaced with the dsp_power_state field which represents the current state of the DSP. This field holds both the device state and the platform-specific substate values. With the DSP device substates being platform-specific, the DSP power state transitions need to be performed in the platform-specific suspend/resume ops as well. In order to achieve this, the ops signature has to be modified to pass the target device state as an argument. The target substate will be determined by the platform-specific ops before performing the transition. For example, in the case of the system suspending to S0IX, the top-level SOF device suspend callback needs to only determine if the DSP will be entering D3 or remain in D0. The target substate in case the device needs to remain in D0 (D0I0 or D0I3) will be determined by the platform-specific suspend op. With the addition of the extended set of power states for the DSP, the set_power_state op for HDA platforms has to be extended to handle only the appropriate state transitions. So, the implementation for the Intel HDA platforms is also modified. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200129220726.31792-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-27ASoC: SOF: core: release resources on errors in probe_continuePierre-Louis Bossart
The initial intent of releasing resources in the .remove does not work well with HDaudio codecs. If the probe_continue() fails in a work queue, e.g. due to missing firmware or authentication issues, we don't release any resources, and as a result the kernel oopses during suspend operations. The suggested fix is to release all resources during errors in probe_continue(), and use fw_state to track resource allocation state, so that .remove does not attempt to release the same hardware resources twice. PM operations are also modified so that no action is done if DSP resources have been freed due to an error at probe. Reported-by: Takashi Iwai <tiwai@suse.de> Co-developed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=1161246 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200124213625.30186-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2020-01-27ASoC: SOF: core: free trace on errorsPierre-Louis Bossart
free_trace() is not called on probe errors, fix Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200124213625.30186-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2019-12-18ASoC: SOF: Introduce state machine for FW bootRanjani Sridharan
Add a state machine for FW boot to track the different stages of FW boot and replace the boot_complete field with fw_state field in struct snd_sof_dev. This will be used to determine the actions to be performed during system suspend. One of the main motivations for adding this change is the fact that errors during the top-level SOF device probe cannot be propagated and therefore suspending the SOF device normally during system suspend could potentially run into errors. For example, with the current flow, if the FW boot failed for some reason and the system suspends, the SOF device suspend could fail because the CTX_SAVE IPC would be attempted even though the FW never really booted successfully causing it to time out. Another scenario that the state machine fixes is when the runtime suspend for the SOF device fails and the DSP is powered down nevertheless, the CTX_SAVE IPC during system suspend would timeout because the DSP is already powered down. Reviewed-by: Curtis Malainey <cujomalainey@chromium.org> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191218002616.7652-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: SOF: Make creation of machine device from SOF core optionalDaniel Baluta
Currently, SOF probes machine drivers by creating a platform device and passing the machine description as private data. This is driven by the ACPI restrictions. Ideally, ACPI tables should contain the description for the machine driver. This is not possible because ACPI tables are frozen and used on multiple OS-es (e.g Windows). In the case of Device Tree we don't have this restriction, so we choose to probe the machine drivers by creating a DT node as is the standard ALSA way. This patch makes the probing of machine drivers from SOF core optional allowing for Device Tree platforms to decouple the SOF core from machine driver probing. Along with this, it also consolidates the machine driver selection for Intel platforms by defining optional ops for selecting the machine driver based on the ACPI match for HDA and non-HDA platforms and setting the mach params. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204211556.12671-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: SOF: partition audio-related parts from SOF coreRanjani Sridharan
Move all the audio-specific code in the core, audio-specific logic in the top-level PM callbacks and the core header files into a separate file (sof-audio.*) in preparation for adding an audio client device. In the process of moving all structure definitions for widget, routes, pcm's etc, the snd_sof_dev member in all these structs is replaced with the snd_soc_component member. Also, use the component device instead of the snd_sof_dev device wherever possible in the PCM component driver, control IO functions and the topology parser as the component device will be moved over to the client device later on. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204211556.12671-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: SOF: core: move check for runtime callbacks to coreRanjani Sridharan
For some platforms, the refcount is explicitly incremented to prevent it from entering runtime suspend. This should be be done during probe in the core instead of being done in the PCM driver. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204211556.12671-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: SOF: core: modify the signature for snd_sof_create_page_tableRanjani Sridharan
Modify the signature for snd_sof_create_page_table to take struct device pointer as an argument instead of struct snd_sof_dev as this will be used by both the SOF core device and its clients. Also, move the definition out of core.c to utils.c. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204211556.12671-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-12ASoC: SOF: add helper to check if we should enter d0i3 suspendKeyon Jie
Add helper to check if the DSP should be put in D0i3. This function returns true if a stream has ignored the SUSPEND trigger to keep the pipelines running in the DSP. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191111223343.19986-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-28ASoC: SOF: reset default d0_substate at probe() and resume()Keyon Jie
We initialize/reset d0_substate to default d0i0 value when doing transition D3-->D0, e.g. at success of probing and resuming. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191025224122.7718-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01ASoC: SOF: core: check for mandatory fw_ready op during SOF probeRanjani Sridharan
fw_ready should be a mandatory op. Make sure fw_ready ops is set during probe. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190927200538.660-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01ASoC: SOF: trace: move to opt-in with Kconfig and module parameterPierre-Louis Bossart
In a number of debug cases, the DMA-based trace can add problems (e.g. with HDaudio channel allocation). It also generates additional traffic on the bus and if the DMA handling is unreliable will prevent audio use-cases from working normally. Using the trace also requires tools to be installed on the target. The trace can be instead handled as dynamic debug. We can use a Kconfig to force the trace to be enabled in all cases, or use a module parameter to enable it on a need-basis, e.g. by setting "options snd_sof sof_debug=0x1" in a /etc/modprobe.d file. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190927200538.660-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-07-23ASoC: SOF: core: increase default IPC timeoutsKai Vehmanen
Increase the default timeout values for boot (100ms to 2sec) and IPC message sending (5ms to 500ms). The values should be overridden with values from platform data. There is no functional need to have such short timeouts as both boot and IPC send errors are considered fatal errors. More relaxed timeouts are convenient when running the driver on top of emulation such as QEMU. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190722141402.7194-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-28ASoC: SOF: core: fix error handling with the probe workqueuePierre-Louis Bossart
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: https://github.com/thesofproject/linux/issues/945 Fixes: c16211d6226 ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-28ASoC: SOF: core: remove snd_soc_unregister_component in case of errorRanjani Sridharan
No need to call snd_soc_unregister_component in case of error because the component device is resource-managed. Fixes: c16211d6226 ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-28ASoC: SOF: core: remove DSP after unregistering machine driverRanjani Sridharan
snd_sof_remove() disables the DSP and unmaps the DSP BAR. Removing topology after disabling the DSP results in a kernel panic while unloading the pipeline widget. This is because pipeline widget unload attempts to power down the core it is scheduled on by accessing the DSP registers. So, the suggested fix here is to unregister the machine driver first to remove the topology and then disable the DSP to avoid the situation described above. Note that the kernel panic only happens in cases where the HDaudio link is not managed by the hdac library, e.g. no codec or when HDMI is not supported. When the hdac library is used, snd_sof_remove() calls snd_hdac_ext_bus_device_remove() to remove the codec which unregisters the component driver thereby also removing the topology before the DSP is disabled. Fixes: c16211d6226 ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-09ASoC: SOF: Fix unused variable warningsTakashi Iwai
The recent fix for the build fix caused a couple of unused variable compiler warnings when CONFIG_SND_SOC_SOF_NOCODEC isn't set: sound/soc/sof/core.c:263:6: warning: unused variable ‘ret’ [-Wunused-variable] sound/soc/sof/core.c:262:28: warning: unused variable ‘machine’ [-Wunused-variable] Fix them by adding another ifdef. Fixes: ce38a75089f7 ("ASoC: SOF: core: fix undefined nocodec reference") Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-08ASoC: SOF: core: fix undefined nocodec referencePierre-Louis Bossart
The existing code mistakenly uses IS_ENABLED in C code instead of as in conditional compilation, leading to the following error: ld: sound/soc/sof/core.o: in function `sof_machine_check': sound/soc/sof/core.c:279: undefined reference to `sof_nocodec_setup' Fix by using #if !IS_ENABLED() Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-28ASoC: SOF: Add Sound Open Firmware driver coreLiam Girdwood
The Sound Open Firmware driver core is a generic architecture independent layer that allows SOF to be used on many different architectures and platforms. It abstracts DSP operations and IO methods so that the target DSP can be an internal memory mapped or external SPI or I2C based device. This abstraction also allows SOF to be run on many different VMs on the same physical HW. SOF also requires some data in ASoC PCM runtime data for looking up SOF data during ASoC PCM operations. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>