linux.git/sound/soc/sof/intel/hda-codec.c, branch v5.8

ASoC: SOF: Intel: hda: fix generic hda codec support

2020-05-29T17:18:02+00:00

Add support for using generic codec driver with SOF. Generic driver
is used if:
 - snd_sof_intel_hda_common.hda_model="generic" is set, or
 - fallback if no other codec driver is found

The implementation is aligned with snd-hda-intel driver, and fixes audio
support for systems like Acer Swift 3 SF314-57G, on which this issue was
originally reported.

Signed-off-by: Kai Vehmanen 
Reviewed-by: Hui Wang 
Reviewed-by: Guennadi Liakhovetski 
Reviewed-by: Pierre-Louis Bossart 
BugLink: https://github.com/thesofproject/linux/issues/1807
BugLink: https://bugs.launchpad.net/bugs/1877757
Link: https://lore.kernel.org/r/20200529160358.12134-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF/Intel: clarify SPDX license with GPL-2.0-only

2020-05-01T16:45:24+00:00

Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only
tag.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Daniel Baluta 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Guennadi Liakhovetski 
Link: https://lore.kernel.org/r/20200501145850.15178-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: remove unneeded variables

2020-04-14T12:20:50+00:00

Remove unneeded temporary local variables and their declarations.
Change suggested by coccinelle.

Signed-off-by: Payal Kshirsagar 
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
Link: https://lore.kernel.org/r/20200409184853.15896-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: allow operation without i915 gfx

2020-02-20T20:28:45+00:00

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 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
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

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: 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

Merge tag 'asoc-fix-v5.5-rc6' into asoc-5.6

2020-01-17T15:38:56+00:00

ASoC: Fixes for v5.5

This is mostly driver specific fixes, plus an error handling fix
in the core.  There is a rather large diffstat for the stm32 SAI
driver, this is a very large but mostly mechanical update which
wraps every register access in the driver to allow a fix to the
locking which avoids circular locks, the active change is much
smaller and more reasonably sized.

ASoC: SOF: Intel: fix HDA codec driver probe with multiple controllers

2020-01-13T15:12:23+00:00

In case system has multiple HDA controllers, it can happen that
same HDA codec driver is used for codecs of multiple controllers.
In this case, SOF may fail to probe the HDA driver and SOF
initialization fails.

SOF HDA code currently relies that a call to request_module() will
also run device matching logic to attach driver to the codec instance.
However if driver for another HDA controller was already loaded and it
already loaded the HDA codec driver, this breaks current logic in SOF.
In this case the request_module() SOF does becomes a no-op and HDA
Codec driver is not attached to the codec instance sitting on the HDA
bus SOF is controlling. Typical scenario would be a system with both
external and internal GPUs, with driver of the external GPU loaded
first.

Fix this by adding similar logic as is used in legacy HDA driver
where an explicit device_attach() call is done after request_module().

Also add logic to propagate errors reported by device_attach() back
to caller. This also works in the case where drivers are not built
as modules.

Signed-off-by: Kai Vehmanen 
Signed-off-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20200110235751.3404-8-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: Intel: drop HDA codec upon probe failure

2019-12-18T19:53:37+00:00

In case a HDA codec probe fails, do not raise error immediately,
but instead remove the codec from bus->codec_mask and continue
probe for other codecs.

This allows for more robust behaviour in cases where one codec
in the system is faulty. SOF driver load can still proceed with
the codecs that can be probed successfully. Probe may still
fail if suitable machine driver is not found, but in many
cases the generic HDA machine driver can operate with a subset
of codecs.

Reviewed-by: Ranjani Sridharan 
Signed-off-by: Kai Vehmanen 
Signed-off-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20191218002616.7652-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown