Align SOF HDA implementation with snd-hda-intel driver and enable
sync_write flag for all supported Intel platforms in SOF. When set,
a sync is issued after each verb write.
Sync after write has helped to overcome intermittent delays in
system resume flow on Intel Coffee Lake systems, and most recently
probe errors related to the HDMI codec on Ice Lake systems.
Matches the snd-hda-intel driver change done in commit 2756d9143a
("ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips").
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/20191008164443.1358-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
When do compile test, if SND_SOC_SOF_OF is not set, we get:
sound/soc/sof/imx/imx8.o: In function `imx8_dsp_handle_request':
imx8.c:(.text+0xb0): undefined reference to `snd_sof_ipc_msgs_rx'
sound/soc/sof/imx/imx8.o: In function `imx8_ipc_msg_data':
imx8.c:(.text+0xf4): undefined reference to `sof_mailbox_read'
sound/soc/sof/imx/imx8.o: In function `imx8_dsp_handle_reply':
imx8.c:(.text+0x160): undefined reference to `sof_mailbox_read'
Make SND_SOC_SOF_IMX_TOPLEVEL always depends on SND_SOC_SOF_OF
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 202acc565a ("ASoC: SOF: imx: Add i.MX8 HW support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190905064400.24800-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We should only select SND_INTEL_NHLT when ACPI is defined. This was
done for the legacy HDAudio driver but not for DSP-enabled cases,
leading to compilation errors with randconfig.
Fix by aligning on the same solution.
For the Skylake driver this is overkill since there is a top-level
dependency on ACPI, but it doesn't hurt and it's better to have
consistency.
Fixes: 68b953aeb5 ('ASoC: SOF: Intel: hda: fixup HDaudio topology name with DMIC number')
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190829214213.11653-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix sparse warnings:
sound/soc/sof/imx/imx8.c:104:6: warning: symbol 'imx8_dsp_handle_reply' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:115:6: warning: symbol 'imx8_dsp_handle_request' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:336:5: warning: symbol 'imx8_get_bar_index' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:341:6: warning: symbol 'imx8_ipc_msg_data' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:348:5: warning: symbol 'imx8_ipc_pcm_params' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20190823125939.30012-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The recent change to remove the bus->io_ops callbacks used an older
version of the SOF code base, and when merged into Mark's for-next it
invalidated changes, resulting in broken compilation identified by
kbuild and reproduced during the weekly SOF rebase.
Restore SOF code overridden by git merge and apply Takashi's intended
change in the 'right' location.
Fixes: c2f16a94a8 ("Merge branch 'topic/hda-bus-ops-cleanup'")
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190812190502.30729-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SOF project maintains 6 topologies for HDaudio (iDisp or
HDaudio+iDisp, no DMIC, 2 DMICs, 4 DMICs). The user is currently
required to manually rename the topology file used in
/lib/firmware/intel/sof-tplg. We can do better to avoid such
renames and use logic to select the relevant file.
The NHLT information can be used to figure out which topology file
should be used.
Alternatively, when NHLT is not present in ACPI tables or is possibly
incorrect, a module parameter can provide that information, e.g. on
Up^2 board with the test DMIC kit.
Tested on Up^2 board and Acer Swift-SF314-55
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190812160623.20821-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently when loading sof process components there's a check if binary
control data is associated with it. If found the data is extracted to be
part of component loading and initialization. If binary data exceeds the
ipc max size, loading fails with error as large message support is only
implemented in set_get_data method. So make the process loading use
set_get_data to enable large parameters in component initialization.
Also refactor the process component loading function as it digs out 3
times almost identical information of related controls. This is
redundant, looks ugly and makes it difficult to understand the
mechanism. So make a function out of fetching the control data and use
it in process loading.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190809231714.20874-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a lot of duplicate code when processing IPC firmware ready
notification and creating memory windows.
First step in reducing the code duplication is to introduce generic
functions:
* sof_get_windows
* sof_fw_ready
that will replace, in the first step, the specific implementation related
to baytrail related platforms:
* byt_get_windows
* byt_fw_ready
So we are basically moving code from intel/byt.c to loader.c keeping
in mind that mbox_offset is a per platform constant so we need to
use newly introduced snd_sof_dsp_get_mailbox_offset /
snd_sof_dsp_get_window_offset in order to get the correct
mbox offset / window offset value.
Also, bar is a per platform constant so we use snd_sof_dsp_get_bar_index
instead of the hardcoded BYT_DSP_BAR.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190807150203.26359-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This is reserved for some historical reason, we didn't enable memory
windows for byt/bdw at the beginning, to make it compatible, we get
those mailbox offsets from fw_ready struct firstly, and then update them
if they existed in the following memory windows, to make sure the
mailbox still can be used if no memory windows are created.
With this change all platforms have the same implementation for
xxx_fw_ready function so that we can refactor it in a common file.
Suggested-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190807150203.26359-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Building with SND_SOC_SOF_HDA_AUDIO_CODEC fails:
sound/soc/sof/intel/hda-bus.c: In function sof_hda_bus_init:
sound/soc/sof/intel/hda-bus.c:16:25: error: implicit declaration of function
snd_soc_hdac_hda_get_ops; did you mean snd_soc_jack_add_gpiods? [-Werror=implicit-function-declaration]
#define sof_hda_ext_ops snd_soc_hdac_hda_get_ops()
Reported-by: Hulk Robot <hulkci@huawei.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Fixes: d4ff1b3917 ('ASoC: SOF: Intel: Initialize hdaudio bus properly")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190809110100.71236-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
