wireguard-linux/sound/soc/sof/sof-priv.h, branch jd/unified-crypt-queue

ASoC: SOF: Intel: remove unnecessary waitq before loading firmware

2020-03-13T15:13:25Z

The HDA_DSP_IPC_PURGE_FW IPC from ROM is already handled in cl_dsp_init(), and it will never be received in the IRQ thread, so the wait condition on this IPC will never be satisfied. The wait before loading firmware is redundant and can be removed safely. Signed-off-by: Amery Song Signed-off-by: Pierre-Louis Bossart Reviewed-by: Keyon Jie Reviewed-by: Kai Vehmanen Reviewed-by: Pierre Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20200312200622.24477-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Remove SOF_IPC_EXT_DMA_BUFFER

2020-03-13T15:13:23Z

This enum code, and what's more important, related structures is unused in whole source code, so it shouldn't be kept. Signed-off-by: Karol Trzcinski Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200312200622.24477-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Generic probe compress operations

2020-02-18T21:52:07Z

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: Intel: cnl: Implement feature to support DSP D0i3 in S0

2020-02-11T11:48:07Z

This patch implements support for DSP D0i3 when the system is in S0. The basic idea is to schedule a delayed work after every successful IPC TX that checks if there are only D0I3-compatible streams active and if so transition the DSP to D0I3. With the introduction of DSP D0I3 in S0, we need to ensure that the DSP is in D0I0 before sending any new IPCs. The exception for this would be the compact IPCs that are used to set the DSP in D0I3/D0I0 states. Signed-off-by: Keyon Jie Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200129220726.31792-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

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

2020-02-11T11:48:05Z

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: pm: Introduce DSP power states

2020-02-11T11:48:04Z

Add a new enum sof_dsp_power_states for all the possible the DSP device states. The SOF driver currently handles only the D0 and D3 states and support for other states will be added later as needed. Also, add a helper to determine the target DSP power state based on the system suspend target. The snd_sof_dsp_d0i3_on_suspend() function is renamed to snd_sof_stream_suspend_ignored() to be more indicative of what it does and it used to determine the target DSP state during system suspend. Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200129220726.31792-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Add system_suspend_target field to struct snd_sof_dev

2020-02-11T11:48:03Z

Add the system_suspend_target field to struct snd_sof_dev to track the intended system suspend power target. This will be used as one of the criteria for determining the final DSP power state. Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200129220726.31792-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: move arch_ops under ops

2019-12-18T20:02:02Z

The current structures are not well designed. We include Xtensa information from the ACPI and PCI levels, but at the Kconfig/module level everything Xtensa related is included at the sof/intel level. Move the arch_ops under ops so that Xtensa is hidden in the DSP ops, with a structure that follows the Kconfig/module partition. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191217202231.18259-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: log compiler name and version information

2019-12-18T19:52:57Z

Log information about used compilator and optimization level in sof firmware to host system. It will be helful to catch some compiler dependent bugs. Signed-off-by: Karol Trzcinski Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191218002616.7652-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Introduce state machine for FW boot

2019-12-18T19:52:20Z

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