The ACPI scan capabilities is called from the intel-dspconfig as well
as the SOF/HDaudio drivers. This creates dependencies and randconfig issues
when HDaudio and SOF/SoundWire are not all configured as modules.

To simplify Kconfig dependencies between HDAudio, SoundWire, SOF and
intel-dspconfig, move the ACPI scan helpers to a dedicated
module. This follows the same idea as NHLT helpers which are already
handled as a dedicated module.

The only functional change is that the kernel parameter to filter
links is now handled by a different module, but that was only provided
for developers needing work-arounds for early BIOS releases.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: NBard Liao <bard.liao@intel.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210302003125.1178419-7-pierre-louis.bossart@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

There is no reason why we should call the intel_dspcfg helpers from
common code, this should be moved in Intel-specific code and only
called from platforms where a conflict may occur with the HDaudio or
SST/Skylake driver.
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: NBard Liao <bard.liao@intel.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210302003125.1178419-5-pierre-louis.bossart@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

It's useful for debug and system integration to show cases where we
ignore the number of microphones reported by NHLT.
Suggested-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210208233336.59449-12-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

fixup_tplg_name() doesn't need to keep the string, allocated for
filename - it's temporary.
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@intel.com>
Link: https://lore.kernel.org/r/20210208233336.59449-11-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The pinmux allows for 2 SoundWire links to be enabled along with
DMICs. This was the default configuration on the TGL-RVP.

One issue with this configuration is that we don't have a means to
automatically detect how many DMICs are used, which in turn requires
the user to manually rename the topology file required on a platform.

This was borderline acceptable for Intel RVPs, but now that this
configuration is present in HP devices we need to automate the
process.

This patch makes use of the NHLT information and will pass the DMIC
number to the machine driver as a parameter. A follow-up patch will
expose the DMIC number to userspace/UCM with the configuration strings.

The Google devices do make use of DMICs instead of SoundWire link 2
and 3, but their topology is unique enough that they do not need any
NHTL support or topology renaming.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210208233336.59449-10-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

We have existing platforms where the wrong machine is selected. We
need to make sure the number of devices reported on a link matches
what we expect for a link descriptor. This helps avoid using the
TGL-RVP configuration for an HP platform or vice-versa, depending on
the order in which they are inserted in the table.
Co-developed-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NBard Liao <bard.liao@intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Link: https://lore.kernel.org/r/20210208233336.59449-9-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

hda_dsp_dump_skl() is never used and hda_dsp_get_status_skl() is
only called from that function. Remove both functions.
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NKeyon Jie <yang.jie@intel.com>
Signed-off-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210208232149.58899-4-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

To implement common logic in SOF core, core power up/down flows should
use common SOF API and not directly use low-level platform specific
helper functions.
Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128093850.1041387-2-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The old code always uses sof_fw_filename in struct snd_soc_acpi_mach
as the firmware name. However, firmware name should depend on the platform
instead of the machine. For example, different machines may use the same
soundwire link topology, but they are using the different firmware. In this
case, it's hard to determine in struct snd_soc_acpi_mach which firmware it
should use.
Signed-off-by: NLibin Yang <libin.yang@intel.com>
Reviewed-by: NBard Liao <bard.liao@intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Tested-by: NJaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210125070500.807474-1-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210114133337.1039-3-tiwai@suse.deSigned-off-by: NMark Brown <broonie@kernel.org>

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: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201211100743.3188821-4-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200917105633.2579047-9-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NRander Wang <rander.wang@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: NKeyon Jie <yang.jie@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200910164125.2033062-2-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NJaska Uimonen <jaska.uimonen@intel.com>
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200825235040.1586478-6-ranjani.sridharan@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NJaska Uimonen <jaska.uimonen@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200825235040.1586478-4-ranjani.sridharan@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NSathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200821195603.215535-14-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Make sure the SoundWire driver can be loaded
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20200819124404.3734-1-yung-chuan.liao@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: Nranderwang <rander.wang@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20200515135958.17511-6-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only
tag.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NDaniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20200501145850.15178-1-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NJaroslav Kysela <perex@perex.cz>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NKai 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.czSigned-off-by: NMark Brown <broonie@kernel.org>

Log the information extracted from NHLT tables to help support users
who report non-functional digital mics with SOF.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200409184416.15591-4-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200409184416.15591-3-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NRander Wang <rander.wang@intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-11-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NRander Wang <rander.wang@intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-10-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add module parameter so that the different modes can be quickly tested.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-9-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-8-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: NRander Wang <rander.wang@intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-6-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-5-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200325215027.28716-3-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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 139c7feb ("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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200312194859.4051-5-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NAmery Song <chao.song@intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NKeyon Jie <yang.jie@linux.intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NPierre Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20200312200622.24477-6-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NRanjani 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.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NKeyon Jie <yang.jie@linux.intel.com>
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200129220726.31792-9-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200206200223.7715-3-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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 687ae9e2 ("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 87c16945 ("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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200206200223.7715-2-kai.vehmanen@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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/1642Signed-off-by: NKai 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: NMark Brown <broonie@kernel.org>

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: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200120160117.29130-2-kai.vehmanen@linux.intel.comAcked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Now that Xtensa stuff is only referenced in Intel stuff, define
namespace and import it in Intel BYT/BDW/HDaudio modules
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191217202231.18259-9-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Define namespaces (one generic and one dedicated for i915) and include
them in HDaudio top-level module.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191217202231.18259-7-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NCurtis Malainey <cujomalainey@chromium.org>
Reviewed-by: NDaniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191218002616.7652-2-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>