summaryrefslogtreecommitdiff
path: root/sound/soc/sof/intel/hda.c
AgeCommit message (Collapse)Author
2021-01-19ASoC: SOF: intel: Simplify with dma_set_mask_and_coherent()Takashi Iwai
ASoC Intel SOF driver still has explicit calls of dma_set_mask() and dma_set_coherent_mask(). Let's simplify with dma_set_mask_and_coherent(). Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20210114133337.1039-3-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-11ASoC: SOF: Intel: hda: fix the condition passed to sof_dev_dbg_or_errRanjani Sridharan
The condition boot_iteration == HDA_FW_BOOT_ATTEMPTS to determine the log level for the DSP status dump would only work in the case of DSP init failure after maximum number of attempts to initialize the DSP. If DSP init succeeds in less than HDA_FW_BOOT_ATTEMPTS attempts and FW loading fails, the ROM status dump would end up getting logged as debug instead of an error. So, add a new flag, SOF_DBG_DUMP_LOG_ERROR, to explicitly specify the log level for DSP status dump. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20201211100743.3188821-4-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-17ASoC: SOF: Intel: hda: reduce verbosity of boot error logsPierre-Louis Bossart
Previous commits reduced the verbosity of errors during boot iterations, but there are still a couple remaining which generate false positives. Errors should only be logged when after last attempt to download firmware failed. Duplicating logs and assigning them different levels based on the iteration number isn't really elegant, use macro as suggested by Guennadi. Suggested-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200917105633.2579047-9-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-11ASoC: SOF: rename cores_mask to host_managed_cores_maskRanjani Sridharan
Rename the cores_mask in struct sof_intel_dsp_desc to host_managed_cores_mask to be more indicative of the fact that only these cores can be powered up/down by the host. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Keyon Jie <yang.jie@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200910164125.2033062-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-26ASoC: SOF: Intel: hda: add extended rom status dump to error logRanjani Sridharan
Dump the extended ROM status information to the error logs to aid with remote support. The analysis of these logs requires access to non-public technical information. Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20200825235040.1586478-6-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-26ASoC: SOF: intel: hda: support also devices with 1 and 3 dmicsJaska Uimonen
Currently the dmic check code supports only devices with 2 or 4 dmics. With other dmic counts the function will return 0. Lately we've seen devices with only 1 dmic thus enable also configurations with 1, and possibly 3, dmics. Add also topology postfix -1ch and -3ch for new dmic configuration. Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20200825235040.1586478-4-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-24ASoC: SOF: Add topology filename override based on dmi data matchSathyanarayana Nujella
Add topology filename override based on system DMI data matching, typically to account for a different hardware layout. In ACPI based systems, the tplg_filename is pre-defined in an ACPI machine table. When a DMI quirk is detected, the sof_pdata->tplg_filename is not set with the hard-coded ACPI value, and instead is set with the DMI-specific filename. Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200821195603.215535-14-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-08-20ASoC: SOF: Intel: hda: import SOUNDWIRE_INIT namespacePierre-Louis Bossart
Make sure the SoundWire driver can be loaded Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20200819124404.3734-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-18ASoC: SOF: Intel: sdw: relax sdw machine select constraintsranderwang
On some platforms such as Up Extreme all links are enabled but only one link can be used by external codec. Instead of exact match of two masks, first check whether link_mask of mach is subset of link_mask supported by hw and then go on searching link_adr. Signed-off-by: randerwang <rander.wang@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20200515135958.17511-6-kai.vehmanen@linux.intel.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-04-24ASoC: snd-sof-intel-hda-common - add hda_model parameter and pass it to HDA ↵Jaroslav Kysela
codec driver It may be useful to pass the specific model to the generic HDA codec routines like the legacy HDA driver (snd-hda-intel) allows. The model name "sofbus" is tricky anyway. Original proposal: https://lore.kernel.org/alsa-devel/20191203161908.7496-1-perex@perex.cz/ Signed-off-by: Jaroslav Kysela <perex@perex.cz> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200424092520.23989-1-perex@perex.cz Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: SOF: Intel: hda: log number of microphones detected in NHLT tablesPierre-Louis Bossart
Log the information extracted from NHLT tables to help support users who report non-functional digital mics with SOF. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200409184416.15591-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: SOF: Intel: hda: reduce verbosity on SoundWire detectionPierre-Louis Bossart
No need to report an error when SoundWire is not detected (not present in hardware or not exposed in ACPI). Move to dev_dbg to state that SoundWire is skipped. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200409184416.15591-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27Asoc: SOF: Intel: hda: check SoundWire wakeen interrupt in irq threadRander Wang
If pci device is in D0, wakeen interrupt will be aggregated at cAVS level as interrupt. This commit check the wakeen status and process it in irq thread Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27ASoC: SOF: Intel: hda: add WAKEEN interrupt support for SoundWireRander Wang
When a SoundWire link is in clock stop state, a Slave device may wake up the Master for some events such as jack detection. The WAKEEN interrupt will be triggered and processed by the audio pci device. If audio device is in D3, the interrupt will be routed to PME, or aggregated at cAVS level as interrupt when audio device is in D0. This patch only supports D3 case, where the audio pci device will be resumed by a PME event and the WAKEEN interrupt will be processed after audio pci device is powered up and ROM is initialized successfully. The WAKEEN handling is only enabled after the first boot due to dependencies on a shim_lock mutex being initialized. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-10-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27ASoC: SOF: Intel: hda: add parameter to control SoundWire clock stop quirksPierre-Louis Bossart
Add module parameter so that the different modes can be quickly tested. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27ASoC: SOF: Intel: hda: merge IPC, stream and SoundWire interrupt handlersBard Liao
We have a single irq handler for SOF interrupts. We can further merge SoundWire ones to completely remove MSI interrupts handling issues leading to timeouts. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27ASoC: SOF: Intel: hda: initial SoundWire machine driver autodetectPierre-Louis Bossart
For now we have a limited number of machine driver configurations, and we can detect them based on the link configuration returned after checking hardware and firmware (BIOS) configurations. The link configuration is checked with a link_mask as well as a list of _ADR descriptors for each link. There is a chance that in extreme cases where the BIOS contains too much information we would need to detect which Slave devices actually report as 'attached'. This would be more accurate than static table-based solutions, but it also introduces timing dependencies since we don't know when those devices might become attached, so will only be only be looked at if we see limitations with static methods and the usual quirks based e.g. on DMI information. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27ASoC: SOF: Intel: hda: add SoundWire stream config/free callbacksPierre-Louis Bossart
These callbacks are invoked when a matching hw_params/hw_free() DAI operation takes place, and will result in IPC operations with the SOF firmware. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27ASoC: SOF: Intel: add SoundWire configuration interfacePierre-Louis Bossart
Now that the SoundWire core supports the multi-step initialization, call the relevant APIs. The actual hardware enablement can be done in two places, ideally we'd want to startup the SoundWire IP as soon as possible (while still taking power rail dependencies into account) However when suspend/resume is implemented, the DSP device will be resumed first, and only when the DSP firmware is downloaded/booted would the SoundWire child devices be resumed, so there are only marginal benefits in starting the IP earlier for the first probe. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200325215027.28716-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13Merge series "ASoC: SOF: multi-cpu dais, IPC and Intel improvements for 5.7" ↵Mark Brown
from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: Corrections for compatibility with the multi-cpu dai check for min-channels, IPC simplifications, and removal of unnecessary boot-related code for Intel platforms. Amery Song (2): ASoC: SOF: Intel: hda: remove unnecessary ROM IPC filter function ASoC: SOF: Intel: remove unnecessary waitq before loading firmware Bard Liao (2): ASoC: SOF: Intel: hda-dai: add stream capability ASoC: SOF: topology: connect dai widget to all cpu-dais Karol Trzcinski (2): ASoC: SOF: Make sof_ipc_ext_data enum more rigid ASoC: SOF: Remove SOF_IPC_EXT_DMA_BUFFER include/sound/sof/info.h | 22 +------- sound/soc/sof/intel/cnl.c | 5 -- sound/soc/sof/intel/hda-dai.c | 96 ++++++++++++++++++++++++++++++++ sound/soc/sof/intel/hda-ipc.c | 20 +------ sound/soc/sof/intel/hda-loader.c | 3 - sound/soc/sof/intel/hda.c | 3 - sound/soc/sof/intel/hda.h | 1 - sound/soc/sof/loader.c | 6 -- sound/soc/sof/sof-priv.h | 5 -- sound/soc/sof/topology.c | 8 ++- 10 files changed, 108 insertions(+), 61 deletions(-) base-commit: 101247a3b86e1cc0e382b7e887a56176290fc957 -- 2.20.1
2020-03-13ASoC: SOF: Intel: hda: remove SND_SOC_SOF_HDA_COMMON_HDMI_CODECKai Vehmanen
To help user-space with HDMI codec driver transition, both a kernel module parameter and a kernel option were initially provided to configure default behaviour of SOF on Intel hardware with commit 139c7febad1a ("ASoC: SOF: Intel: add support for snd-hda-codec-hdmi"). As hdac-hdmi is already now lagging in features compared to snd-hda-codec-hdmi, move ahead with the transition and remove the build option to select between the two, and instead default to snd-hda-codec-hdmi if it is enabled in kernel build. The old behaviour of using hdac-hdmi driver can still be forced via the kernel module parameter. 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/20200312194859.4051-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13ASoC: SOF: Intel: remove unnecessary waitq before loading firmwareAmery Song
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 <chao.song@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Keyon Jie <yang.jie@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20200312200622.24477-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-20ASoC: SOF: Intel: hda: allow operation without i915 gfxKai Vehmanen
Add support to configure the HDA controller with an external HDA codec even if iDisp codec in i915 is not available. This can happen for multiple reasons: - internal graphics is disabled on the system - i915 driver is not enabled in kernel or it fails to init - i915 codec reports error in HDA codec probe - HDA codec driver probe fails Address all these scenarios, but keep using the existing topology. In case failures occur, HDMI PCM nodes are created, but they will report error if application tries to use them. No ALSA mixer controls are created. If the external HDA codec init fails as well, SOF probe will return error as before. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206085 BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1163677 BugLink: https://github.com/thesofproject/linux/issues/1658 Link: https://lore.kernel.org/r/20200220171028.22023-3-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-11Merge branch 'for-5.6' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-5.7
2020-02-11ASoC: SOF: Intel: cnl: Implement feature to support DSP D0i3 in S0Ranjani Sridharan
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 <yang.jie@linux.intel.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/20200129220726.31792-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-10ASoC: SOF: Intel: hda: move i915 init earlierKai Vehmanen
To be compliant with i915 display driver requirements, i915 power-up must be done before any HDA communication takes place, including parsing the bus capabilities. Otherwise the initial codec probe may fail. Move i915 initialization earlier in the SOF HDA sequence. This sequence is now aligned with the snd-hda-intel driver where the display_power() call is before snd_hdac_bus_parse_capabilities() and rest of the capability parsing. Also remove unnecessary ifdef around hda_codec_i915_init(). There's a dummy implementation provided if CONFIG_SND_SOC_SOF_HDA is not enabled. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200206200223.7715-3-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-10ASoC: SOF: Intel: hda: fix ordering bug in resume flowKai Vehmanen
When HDA controller is resumed from suspend, i915 HDMI/DP codec requires that following order of actions is kept: - i915 display power up and configuration of link params - hda link reset and setup Current SOF HDA code delegates display codec power control to the codec driver. This works most of the time, but in runtime PM sequences, the above constraint may be violated. On platforms where BIOS values for HDA link parameters do not match hardware reset defaults, this may lead to errors in HDA verb transactions after resume. Fix the issue by explicitly powering the display codec in the HDA controller resume/suspend calls, thus ensuring correct ordering. Special handling is needed for the D0i3 flow, where display power must be turned off even though DSP is left powered. Now that we have more invocations of the display power helper functions, the conditional checks surrounding each call have been moved inside hda_codec_i915_display_power(). The two special cases of display powering at initial probe are handled separately. The intent is to avoid powering the display whenever no display codecs are used. Note that early powering of display was removed in commit 687ae9e287b3 ("ASoC: intel: skl: Fix display power regression"). This change was also copied to the SOF driver. No failures have resulted as hardware default values for link parameters have worked out of the box. However with recent i915 driver changes like done in commit 87c1694533c9 ("drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend"), this does not hold anymore and errors are hit. Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200206200223.7715-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-27ASoC: SOF: Intel: do not disable i915 power during probeKai Vehmanen
Change HDA probe behaviour slightly so that i915 power is not turned off if i915 audio codecs are found in the initial probe done by SOF Intel driver, and power is kept on until HDA codec driver probe runs. This will reduce number of mode sets on platforms with low minimum CDCLK (like GLK) and brings the SOF probe sequence closer to legacy HDA driver in terms of i915 audio codec power management. BugLink: https://github.com/thesofproject/linux/issues/1642 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200120160117.29130-3-kai.vehmanen@linux.intel.com Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-27ASoC: SOF: Intel: refactor i915_get/put functionsKai Vehmanen
The current interface to control i915 display power is misleading. The hda_codec_i915_get() and hda_codec_i915_put() names suggest a refcounting based interface. This is confusing as no refcounting is done and the underlying HDAC library interface does not support refcounts eithers. Clarify the code by replacing the functions with a single hda_codec_i915_display_power() that is aligned with snd_hdac_display_power(). Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200120160117.29130-2-kai.vehmanen@linux.intel.com Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-18ASoC: SOF: Intel: add namespace for XTENSAPierre-Louis Bossart
Now that Xtensa stuff is only referenced in Intel stuff, define namespace and import it in Intel BYT/BDW/HDaudio modules Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191217202231.18259-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-18ASoC: SOF: Intel: hda: add namespace for hda-codec functionalityPierre-Louis Bossart
Define namespaces (one generic and one dedicated for i915) and include them in HDaudio top-level module. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191217202231.18259-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@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: intel: hda: Modify signature for hda_codec_probe_bus()Ranjani Sridharan
The machine driver selection for HDA platforms will be consolidated and moved out of the SOF DSP probe callback. In preparation for that, modify the signature for hda_codec_probe_bus() to pass the hda_codec_use_common_hdmi as a variable while probing the HDA codecs. 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-10-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: intel/skl/hda - export number of digital microphones via control ↵Jaroslav Kysela
components It is required for the auto-detection in the user space (for UCM). Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20191204211556.12671-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: SOF: Intel: hda: solve MSI issues by merging ipc and stream irq handlersBard Liao
The existing code uses two handlers for a shared edge-based MSI interrupts. In corner cases, interrupts are lost, leading to IPC timeouts. Those timeouts do not appear in legacy mode. This patch merges the two handlers and threads into a single one, and simplifies the mask/unmask operations by using a single top-level mask (Global Interrupt Enable). The handler only checks for interrupt sources using the Global Interrupt Status (GIS) field, and all the actual work happens in the thread. This also enables us to remove the use of spin locks. Stream events are prioritized over IPC ones. This patch was tested with HDaudio and SoundWire platforms, and all known IPC timeout issues are solved in MSI mode. The SoundWire-specific patches will be provided in follow-up patches, where the SoundWire interrupts are handled in the same thread as IPC and stream interrupts. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204212859.13239-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-12ASoC: SOF: Intel: hda: use fallback for firmware namePierre-Louis Bossart
We have platforms such as CFL with no known I2S codec being used, and the ACPI tables are currently empty, so fall-back to using the firmware filename used in nocodec mode Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191111222901.19892-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-29ASoC: SOF: Intel: add support for snd-hda-codec-hdmiKai Vehmanen
Add support to implement HDMI/DP audio by using the common snd-hda-codec-hdmi driver. Change of codec driver affects user-space as the two drivers expose different mixer controls. A new kernel module option "use_common_hdmi" is added to user-space to indicate which interface should be used. The default driver can be selected via a Kconfig option. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191029134017.18901-6-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10Revert "ASoC: SOF: Force polling mode on CFL and CNL"Kai Vehmanen
This reverts commit 64ca9d9fcb3e3c86b1417e3d17a90b43dd660f81. The workaround is no longer needed after configuring HDAC bus with sync_write=1. 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-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: enable sync_write in hdac_busKai Vehmanen
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 2756d9143aa5 ("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>
2019-10-01ASoC: SOF: Intel: initialise and verify FW crash dump data.Liam Girdwood
FW mailbox offset was not set before use and HDR size was not validated. Fix this. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190927200538.660-12-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-20Merge branch 'asoc-5.3' into asoc-5.4Mark Brown
2019-08-12ASoC: SOF: Intel: hda: fixup HDaudio topology name with DMIC numberPierre-Louis Bossart
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>
2019-08-09ASoC: SOF: Intel: Add missing include file hdac_hda.hYueHaibing
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: d4ff1b3917a5 ('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>
2019-08-08Merge branch 'topic/hda-bus-ops-cleanup' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into asoc-5.4
2019-08-08ASoC: SOF: Intel: Initialize hdaudio bus properlyTakashi Iwai
The SOF HD-audio bus has its house-made initialization code. It's supposedly for making the code independent from HD-audio bus drivers. However, this is error-prone, and above all, the SOF driver has already dependency on HD-audio bus driver when CONFIG_SND_SOF_HDA is set. That is, if this Kconfig is set, there is no reason to avoid the call to the proper bus init function. Also, the ext_ops that is set at bus initialization can be better handled inside sof_hda_bus_init(). We don't need to refer this outside the bus initialization. So this patch addresses these issues: - sof_hda_bus_init() calls nothing but snd_hdac_ext_bus_init() when CONFIG_SND_SOF_HDA is set. Otherwise some fields are initialized locally like before for avoiding the dependency. - ext_ops is referred inside sof_hda_bus_init(). The ext_ops argument of snd_hda_bus_init() is dropped. Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-07ASoC: SOF: Intel: hda: fix MSI handlingPierre-Louis Bossart
The addition of a kernel module parameter to optionally disable MSI had the side effect of permanently disabling it. The return value of pci_alloc_irq_vectors() is the number of allocated vectors or a negative number on error, so testing with the ! operator is not quite right. It was one optimization too far. Restore previous behavior to use MSI by default, unless the user selects not to do so or the allocation of irq_vectors fails. Fixes: 672ff5e3596ee ('ASoC: SOF: Intel: hda: add a parameter to disable MSI') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190806170603.10815-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-07ASoC: SOF: Intel: hda: Initialize HDA controller after i915 initRanjani Sridharan
On some platforms, sound card registration fails when a HDMI monitor is not connected. This is caused by a recent commit that switched the order in which the HDA controller and the i915 are initialized. Initializing the i915 before initializing the HDA controller fixes the problem. Fixes: be1b577d01787c ("ASoC: SOF: Intel: hda: fix the hda init chip" Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 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/20190806221958.19180-1-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-07-23ASoC: SOF: Intel: hda: add a parameter to disable MSIGuennadi Liakhovetski
Enabling MSI on HDA can fail, in which case the legacy PCI IRQ mode will be used. To make testing this mode easier add an "enable_msi" module parameter, which is only enabled if debugging is enabled too. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190722141402.7194-17-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-14 00:32:55 +0000