linux.git/sound/soc/sof/intel/hda.c, branch v5.6

ASoC: SOF: Intel: hda: move i915 init earlier

2020-02-10T14:06:12+00:00

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 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Takashi Iwai 
Link: https://lore.kernel.org/r/20200206200223.7715-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: fix ordering bug in resume flow

2020-02-10T14:06:04+00:00

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 
Signed-off-by: Kai Vehmanen 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Takashi Iwai 
Link: https://lore.kernel.org/r/20200206200223.7715-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Intel: do not disable i915 power during probe

2020-01-27T17:51:43+00:00

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 
Link: https://lore.kernel.org/r/20200120160117.29130-3-kai.vehmanen@linux.intel.com
Pierre-Louis Bossart 
Signed-off-by: Mark Brown

ASoC: SOF: Intel: refactor i915_get/put functions

2020-01-27T17:51:27+00:00

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 
Link: https://lore.kernel.org/r/20200120160117.29130-2-kai.vehmanen@linux.intel.com
Acked-by: Pierre-Louis Bossart 
Signed-off-by: Mark Brown

ASoC: SOF: Intel: add namespace for XTENSA

2019-12-18T20:02:21+00:00

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

ASoC: SOF: Intel: hda: add namespace for hda-codec functionality

2019-12-18T20:01:52+00:00

Define namespaces (one generic and one dedicated for i915) and include
them in HDaudio top-level module.

Signed-off-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20191217202231.18259-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Introduce state machine for FW boot

2019-12-18T19:52:20+00:00

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

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: intel: hda: Modify signature for hda_codec_probe_bus()

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

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

ASoC: intel/skl/hda - export number of digital microphones via control components

2019-12-09T18:36:52+00:00

It is required for the auto-detection in the user space (for UCM).

Signed-off-by: Jaroslav Kysela 
Signed-off-by: Pierre-Louis Bossart 
Cc: Mark Brown 
Link: https://lore.kernel.org/r/20191204211556.12671-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown