kernel/linux.git/sound/soc/sof/ops.h, branch v5.10.257

ASoC: SOF/Intel: clarify SPDX license with GPL-2.0-only

2020-05-01T16:45:24+00:00

Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only tag. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Daniel Baluta Reviewed-by: Kai Vehmanen Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20200501145850.15178-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Generic probe compress operations

2020-02-18T21:52:07+00:00

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 Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200218143924.10565-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown

ASoC: SOF: Move DSP power state transitions to platform-specific ops

2020-02-11T11:48:05+00:00

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 Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200129220726.31792-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Make creation of machine device from SOF core optional

2019-12-09T18:39:35+00:00

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 Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191204211556.12671-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: return -ENOTSUPP if D0I3 is not supported

2019-10-28T14:46:21+00:00

No set_power_state ops means that the platform doesn't support D0i3, return -ENOTSUPP for the case. Signed-off-by: Keyon Jie Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191025224122.7718-25-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: add set_power_state() to dsp_ops for power state update

2019-10-28T14:40:52+00:00

D0i3 is a platform-defined substate of D0, so we need a platform-specific callback in dsp_ops to handle the relevant configurations. Signed-off-by: Keyon Jie Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191025224122.7718-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Introduce snd_sof_dsp_get_window_offset

2019-08-09T12:26:02+00:00

This will allow us to export the offset for a memory window. Signed-off-by: Daniel Baluta Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20190807150203.26359-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Introduce snd_sof_dsp_get_mailbox_offset

2019-08-09T12:25:43+00:00

This will allow us to export mailbox offset in order to read the fw_ready message from. Signed-off-by: Daniel Baluta Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20190807150203.26359-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: remove unused state variable in suspend function

2019-07-23T11:20:21+00:00

Remove unused and no plan to use variable from suspend function. Signed-off-by: Fred Oh Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20190722141402.7194-10-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Introduce snd_sof_dsp_get_bar_index ops

2019-07-23T11:19:29+00:00

FW encapsulates information about section types (e.g DRAM, IRAM) inside module block header. This information can be used in order to correctly load the section to the appropriate place in memory. SOF Linux driver needs to know for each platform how to map the section type with the corresponding memory BAR. So, this patch introduces get_bar_index, a new operation inside snd_sof_dsp_ops. Intel platforms, usually load all the section in a contiguous memory area (usually denoted by sdev->mmio_bar) so things are relatively simple there. Anyhow, on i.MX8 IRAM and DRAM for example are mapped to distinct BARs. By default, if no get_bar function is provided the core implementation will always return sdev->mmio_bar so that there will be no need for a change to existing Intel code. Signed-off-by: Daniel Baluta Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20190722141402.7194-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown