We are able to power down the GPU and audio via the GPU driver
so flag these asics as supporting runtime pm.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20191122214353.582899-4-alexander.deucher@amd.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Only enable the vga_switcheroo logic on systems with the
ATPX ACPI method. This logic is not needed for asics
that are not part of a PX (PowerXpress)/HG (Hybrid Graphics)
platform.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20191122214353.582899-2-alexander.deucher@amd.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Laptops like ASUS UX431FLC and UX431FL can share the same audio quirks.
But UX431FLC needs one more step to enable the internal speaker: Pull
the GPIO from CODEC to initialize the AMP.
Fixes: 60083f9e94 ("ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL")
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191125093405.5702-1-jian-hong@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HDMI codec may leave codec->relaxed_resume flag set even after
unbinding. Clear it unconditionally.
It's very unlikely that this actually matters in the real use case,
so just a fix for consistency.
Fixes: ade49db337 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
Link: https://lore.kernel.org/r/20191122132624.5482-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The old Nvidia chips have multiple HD-audio codecs on the same
HD-audio controller, and this doesn't work as expected with the current
audio component binding that is implemented under the one-codec-per-
controller assumption; at the probe time, the driver leads to several
kernel WARNING messages.
For the proper support, we may change the pin2port and port2pin to
traverse the codec list per the given pin number, but this needs more
development and testing.
As a quick workaround, instead, this patch drops the binding in the
audio side for these legacy chips since the audio component support in
nouveau graphics driver is still not merged (hence it's basically
unused).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205625
Fixes: ade49db337 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
Link: https://lore.kernel.org/r/20191122132000.4460-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have a new Dell machine which needs to apply the quirk
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, try to use the fallback table
to fix it this time. And we could remove all pintbls of alc236
for applying DELL1_MIC_NO_PRESENCE on Dell machines.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20191121022644.8078-2-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have a new Dell machine which needs to apply the quirk
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, try to use the fallback table
to fix it this time. And we could remove all pintbls of alc256
for applying DELL1_MIC_NO_PRESENCE on Dell machines.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20191121022644.8078-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mic mute led does not work on HP ProBook 645 G4.
We can use CXT_FIXUP_MUTE_LED_GPIO fixup to support it.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191120082035.18937-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds DP-MST support for GK104+ NVIDIA codecs.
GK104+ NVIDIA codecs support DP-MST audio. These codecs have 4
output converters and 4 pin widgets, with 4 device entries per pin
widget for a total of 16 device entries.
This patch moves the existing patch_nvhdmi() definition to
patch_nvhdmi_legacy(), used by pre-GK104 NVIDIA codecs. Redefine
patch_nvhdmi() to enable DP-MST support by setting codec->dp_mst and
spec->dyn_pcm_assign.
Introduce fresh logic for dynamic pcm assignment, making
sure that new pcm assignments are compatible with the legacy static
per_pin-pmc assignment that existed in the days before DP-MST.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Link: https://lore.kernel.org/r/20191119084710.29267-5-nmahale@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch make it possible for non-acomp codecs to set
dyn_pcm_assign/dp_mst and get DP-MST audio support.
Document change notification HDA040-A for the Intel High Definition
Audio 1.0a specification introduces a Device Select verb for Digital
Display Pin Widgets that are multi-stream capable. This verb selects
a Device Entry that is used by subsequent Pin Widget verbs.
Once the Device Entry is selected, all subsequent Pin Widget verbs
controlling the sink device will be directed to the selected Device
Entry until the Device Select verb is updated with a new value.
These Pin Widget verbs include:
* Connection Select
* Get Connection List Entry
* Amplifier Gain/Mute
* Power State
* Pin Widget Control
* ELD Data
* DIP-Size
* DIP-Index
* DIP-Data
* DIP-XmitCtrl
* Content Protection Control
* ASP Channel Mapping
This patch adds calls to snd_hda_set_dev_select() to direct each of
these Pin Widget control verbs to the correct Device Entry.
snd_hda_get_connections() does not return per-device connection
list, therefore make use snd_hda_get_raw_connections() instead of
snd_hda_get_connections().
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Link: https://lore.kernel.org/r/20191119084710.29267-4-nmahale@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds DP-MST jack support which will be used on NVIDIA
platforms. Today, DP-MST audio is supported only if the codec has
acomp support. This patch makes it possible to add DP-MST support
for non-acomp codecs.
For the codecs supporting DP-MST audio, each pin can contain several
device entries. Each device entry is a virtual pin, described by
pin_nid and dev_id in struct hdmi_spec_per_pin. For monitor hotplug
event handling, non-acomp codecs enable and register jack-detection
for every hdmi_spec_per_pin.
This patch updates every relevant function in hda_jack.h and its
implementation in hda_jack.c, to consider dev_id along with pin_nid.
Changes to the HD Audio specification to support DP-MST audio are
described in the Intel Document Change Notification (DCN) number
HDA040-A.
From HDA040-A, "For the case of multi stream capable Digital Display
Pin Widget, [the Get Pin Sense verb] can be used to read a specific
Device Entry state as reported in Get Device List Entry verb." This
patch updates the read_pin_sense() function to take the dev_id as an
argument and pass it as a parameter to the Get Pin Sense verb.
Bits 15 through 20 from the Unsolicited Response for intrinsic
events contain the index of the Device Entry that generated the
event. This patch updates the Unsolicited Response event handlers to
extract the device entry index from the response and pass it to
snd_hda_jack_tbl_get_from_tag().
This patch updates snd_hda_jack_tbl_new() to take a dev_id argument
and store it in the jack structure, and to make sure not to generate
a different tag when called more than once for the same nid.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Link: https://lore.kernel.org/r/20191119084710.29267-3-nmahale@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
s/snd_hda_pin_sense/snd_hda_jack_pin_sense/g
This aligns the snd_hda_pin_sense function name with the names of
other functions in hda_jack.h.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Link: https://lore.kernel.org/r/20191119084710.29267-2-nmahale@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove the workarounds added in commit fa763f1b28 ("ALSA:
hda - Force polling mode on CNL for fixing codec communication")
and commit a8d7bde23e ("ALSA: hda - Force polling mode on CFL
for fixing codec communication").
The workarounds are no longer needed after the more generic
change done in commit 2756d9143a ("ALSA: hda - Fix intermittent
CORB/RIRB stall on Intel chips"). This change applies to a larger
set of hardware and covers CFL and CNL as well.
Similar change was already done to SOF DSP HDA driver with
no regressions detected.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191115124449.20512-4-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Semantics of port#0 differ between ICL and TGL:
ICL port#0 -> never used for HDAudio
ICL port#1 -> should be mapped to first pin (0x04)
TGL port#0 -> typically not used, but HW has the support,
so should be mapped to first pin (0x04)
TGL port#1 -> should be mapped to 2nd pin (0x06)
Refactor the port mapping logic to allow to take the above
differences into account. Fixes issues with HDAudio on some
TGL platforms.
Co-developed-by: Pan Xiuli <xiuli.pan@linux.intel.com>
Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191115124449.20512-2-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Introduce a new flag in hdmi_spec to indicate the Intel platform-
specific fixups so that we can get rid of the lengthy codec ID
checks. The flag is set in intel_hsw_common_init() commonly.
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191111190937.19186-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The code change in commit 6974f8ad44 ("ALSA: pci: Avoid non-standard
macro usage") contained an incorrect conversion, which left the
invalid pointer passed to the allocator for au88x0 driver. Fix it.
Fixes: 6974f8ad44 ("ALSA: pci: Avoid non-standard macro usage")
Link: https://lore.kernel.org/r/20191112143243.22216-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Apply same logic to pin setup as on previous platforms. Fixes
errors in HDMI/DP playback.
Tested with both snd-hda-intel and SOF drivers.
Fixes: 9a11ba7388 ("ALSA: hda: hdmi - add Tigerlake support")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191111133838.21213-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some big changes in the core but more about cleanps and refactorings
than new features, plus a collection of new drivers and lots of small
fixes and improvements to existing ones.
- Lots more cleanups from Morimoto-san. Now that everything is a
component this is mostly about refactorings to clarify and simplify
the core, a combination of things that are no longer required due to
refactorings and spotting similarities.
- Many fixes to the Sound Open Firmware code.
- Wake on voice support for Chromebooks.
- SPI support for RT5677.
- New drivers for Analog Devices ADAU7118, Intel Cannonlake systems
with RT1011 and RT5682, Texas Instruments TAS2562 and TAS2770.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl3EFLYTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0JCuB/40P/KPRGlEFBSJAwTfCkjQxzvQUGBy
Y3w9QeMq3ONhCJt5BusmeuFqdkanzYqnl+NveGYKdKNTAwh6vEMGiMbGSB8dgrR5
R7PLNBDRJi7ZUDdOZle7VrdUiZWyieaZk/ecWxfTPKfqzoBjnM3XYSa30i55hvbQ
A2MTimFsO7nf0caLNBLqEqBjy68IHQ3tuHH27kA0MIpVNsYVrjaWfM400ot3odbg
0vMpNTM+PDcQGkWcq3sKJBOVVjmGg2Xs1yM5hv6Mu+q1zXLCtCKj+Pv+ZXC3BT6e
Yyxv/arpgvtjIU79Tv9RamVRC4jN6ZJRkThP9UW6JrX7tPCjvD+ygzPn
=4FMp
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v5.5
Some big changes in the core but more about cleanps and refactorings
than new features, plus a collection of new drivers and lots of small
fixes and improvements to existing ones.
- Lots more cleanups from Morimoto-san. Now that everything is a
component this is mostly about refactorings to clarify and simplify
the core, a combination of things that are no longer required due to
refactorings and spotting similarities.
- Many fixes to the Sound Open Firmware code.
- Wake on voice support for Chromebooks.
- SPI support for RT5677.
- New drivers for Analog Devices ADAU7118, Intel Cannonlake systems
with RT1011 and RT5682, Texas Instruments TAS2562 and TAS2770.
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Along with it, drop the unnecessary assignment before the
snd_dma_alloc_pages() call and simplify by returning the error code
directly.
Link: https://lore.kernel.org/r/20191105151856.10785-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Along with it, the unneeded assignment before snd_dma_alloc_pages*()
call is dropped.
Link: https://lore.kernel.org/r/20191105151856.10785-22-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Also slightly refactor the code (drop the return value check from the
preallocation) as it never returns an error.
Link: https://lore.kernel.org/r/20191105151856.10785-21-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_pcm_sgbuf_ops_page is no longer needed to be set explicitly to PCM
page ops since the recent change in the PCM core (*). Leaving it NULL
should work as long as the preallocation has been done properly.
This patch drops the redundant lines.
(*) 7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The unsolicited event handler for the headphone jack on CA0132 codec
driver tries to reschedule the another delayed work with
cancel_delayed_work_sync(). It's no good idea, unfortunately,
especially after we changed the work queue to the standard global
one; this may lead to a stall because both works are using the same
global queue.
Fix it by dropping the _sync but does call cancel_delayed_work()
instead.
Fixes: 993884f6a2 ("ALSA: hda/ca0132 - Delay HP amp turnon.")
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1155836
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191105134316.19294-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit ade49db337 ("ALSA: hda/hdmi - Allow audio component for
AMD/ATI and Nvidia HDMI") introduced the spec->pcm_lock mutex lock to
the whole generic_hdmi_init() function for avoiding the race with the
audio component registration. However, this caused a dead lock when
the unsolicited event is handled without the audio component, as the
codec gets runtime-resumed in hdmi_present_sense() which is already
inside the spec->pcm_lock in its caller.
For avoiding this deadlock, add a new mutex only for the audio
component binding that is used in both generic_hdmi_init() and the
audio notifier registration where the jack callbacks are handled /
re-registered.
Fixes: ade49db337 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
Reported-and-tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/s5himo7i89i.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To support the DP-MST multiple streams via single connector feature,
the HDMI driver was extended with the concept of backup PCMs. See
commit 9152085def ("ALSA: hda - add DP MST audio support").
This implementation works fine with snd_hda_intel.c as PCM topology
is fully managed within the single driver.
When the HDA codec driver is used from ASoC components, the concept
of backup PCMs no longer fits. For ASoC topologies, the physical
HDMI converters are presented as backend DAIs and these should match
with hardware capabilities. The ASoC topology may define arbitrary
PCMs (i.e. frontend DAIs) and have processing elements before eventual
routing to the HDMI BE DAIs. With backup PCMs, the link between
FE and BE DAIs would become dynamic and change when monitors are
(un)plugged. This would lead to modifying the topology every time
hotplug events happen, which is not currently possible in ASoC and
there does not seem to be any obvious benefits from this design.
To overcome above problems and enable the HDMI driver to be used
from ASoC, this patch adds a new mode (mst_no_extra_pcms flags) to
patch_hdmi.c. In this mode, the codec driver does not assume
the backup PCMs to be created.
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-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This is an alternative fix attemp for the issue reported in the commit
caa8422d01 ("ALSA: hda: Flush interrupts on disabling") that was
reverted later due to regressions. Instead of tweaking the hardware
disablement order and the enforced irq flushing, do calling
cancel_work_sync() of the unsol work early enough, and explicitly
ignore the unsol events during the shutdown by checking the
bus->shutdown flag.
Fixes: caa8422d01 ("ALSA: hda: Flush interrupts on disabling")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit caa8422d01.
It turned out that this commit caused a regression at shutdown /
reboot, as the synchronize_irq() calls seems blocking the whole
shutdown. Also another part of the change about shuffling the call
order looks suspicious; the azx_stop_chip() call disables the CORB /
RIRB while the others may still need the CORB/RIRB update.
Since the original commit itself was a cargo-fix, let's revert the
whole patch.
Fixes: caa8422d01 ("ALSA: hda: Flush interrupts on disabling")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205333
BugLinK: https://bugs.freedesktop.org/show_bug.cgi?id=111174
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://lore.kernel.org/r/20191028081056.22010-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These 2 ThinkCentres installed a new realtek codec ID 0x623,
it has 2 front mics with the same location on pin 0x18 and 0x19.
Apply fixup ALC283_FIXUP_HEADSET_MIC to change 1 front mic
location to right, then pulseaudio can handle them.
One "Front Mic" and one "Mic" will be shown, and audio output works
fine.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191024114439.31522-1-aaron.ma@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For distributions, we need one place where we can decide
which driver will be activated for the auto-configation of the
Intel's HDA hardware with DSP. Actually, we cover three drivers:
* Legacy HDA
* Intel SST
* Intel Sound Open Firmware (SOF)
All those drivers registers similar PCI IDs, so the first
driver probed from the PCI stack can win. But... it is not
guaranteed that the correct driver wins.
This commit changes Intel's NHLT ACPI module to a common
DSP probe module for the Intel's hardware. All above sound
drivers calls this code. The user can force another behaviour
using the module parameter 'dsp_driver' located in
the 'snd-intel-dspcfg' module.
This change allows to add specific dmi checks for the specific
systems. The examples are taken from the pull request:
https://github.com/thesofproject/linux/pull/927
Tested on Lenovo Carbon X1 7th gen.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191022174313.29087-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Nvidia proprietary driver doesn't support runtime power management, so
when a user only wants to use the integrated GPU, it's a common practice
to let dGPU not to bind any driver, and let its upstream port to be
runtime suspended. At the end of runtime suspension the port uses
platform power management to disable power through _OFF method of power
resource, which is listed by _PR3.
After commit b516ea586d ("PCI: Enable NVIDIA HDA controllers"), when
the dGPU comes with an HDA function, the HDA won't be suspended if the
dGPU is unbound, so the power resource can't be turned off by its
upstream port driver.
Commit 37a3a98ef6 ("ALSA: hda - Enable runtime PM only for
discrete GPU") only allows HDA to be runtime suspended once GPU is
bound, to keep APU's HDA working.
However, HDA on dGPU isn't that useful if dGPU is not bound to any
driver. So let's relax the runtime suspend requirement for dGPU's HDA
function, to disable the power source to save lots of power.
BugLink: https://bugs.launchpad.net/bugs/1840835
Fixes: b516ea586d ("PCI: Enable NVIDIA HDA controllers")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20191018073848.14590-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Przemysław Kopa reports that since commit b516ea586d ("PCI: Enable
NVIDIA HDA controllers"), the discrete GPU Nvidia GeForce GT 540M on his
2011 Samsung laptop refuses to runtime suspend, resulting in a power
regression and excessive heat.
Rivera Valdez witnesses the same issue with a GeForce GT 525M (GF108M)
of the same era, as does another Arch Linux user named "R0AR" with a
more recent GeForce GTX 1050 Ti (GP107M).
The commit exposes the discrete GPU's HDA controller and all four codecs
on the controller do not set the CLKSTOP and EPSS bits in the Supported
Power States Response. They also do not set the PS-ClkStopOk bit in the
Get Power State Response. hda_codec_runtime_suspend() therefore does
not call snd_hdac_codec_link_down(), which prevents each codec and the
PCI device from runtime suspending.
The same issue is present on some AMD discrete GPUs and we addressed it
by forcing runtime PM despite the bits not being set, see commit
57cb54e53b ("ALSA: hda - Force to link down at runtime suspend on
ATI/AMD HDMI").
Do the same for Nvidia HDMI codecs.
Fixes: b516ea586d ("PCI: Enable NVIDIA HDA controllers")
Link: https://bbs.archlinux.org/viewtopic.php?pid=1865512
Link: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c81
Reported-by: Przemysław Kopa <prymoo@gmail.com>
Reported-by: Rivera Valdez <riveravaldez@ysinembargo.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Drake <dan@reactivated.net>
Cc: stable@vger.kernel.org # v5.3+
Link: https://lore.kernel.org/r/3086bc75135c1e3567c5bc4f3cc4ff5cbf7a56c2.1571324194.git.lukas@wunner.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Asus MJ401TA (with Realtek ALC256), the headset mic is connected to
pin 0x19, with default configuration value 0x411111f0 (indicating no
physical connection).
Enable this by quirking the pin. Mic jack detection was also tested and
found to be working.
This enables use of the headset mic on this product.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191017081501.17135-1-drake@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Headphone on XPS 9350/9360 produces a background white noise. The The
noise level somehow correlates with "Headphone Mic Boost", when it sets
to 1 the noise disappears. However, doing this has a side effect, which
also decreases the overall headphone volume so I didn't send the patch
upstream.
The noise was bearable back then, but after commit 717f43d81a ("ALSA:
hda/realtek - Update headset mode for ALC256") the noise exacerbates to
a point it starts hurting ears.
So let's use the workaround to set "Headphone Mic Boost" to 1 and lock
it so it's not touchable by userspace.
Fixes: 717f43d81a ("ALSA: hda/realtek - Update headset mode for ALC256")
BugLink: https://bugs.launchpad.net/bugs/1654448
BugLink: https://bugs.launchpad.net/bugs/1845810
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20191003043919.10960-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191004144931.3851-1-krzk@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The same fixup to enable laptop imic is needed for ASUS M9V with AD1986A
codec like another HP machine.
Signed-off-by: Shih-Yuan Lee (FourDollars) <fourdollars@debian.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190920134052.GA8035@localhost
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The laptop has a combined jack to attach headsets on the right.
The BIOS encodes them as two different colored jacks at the front,
but otherwise it seems to be configured ok. But any adaption of
the pins config on its own doesn't fix the jack detection to work
in Linux. Still Windows works correct.
This is somehow fixed by chaining ALC256_FIXUP_ASUS_HEADSET_MODE,
which seems to register the microphone jack as a headset part and
also results in fixing jack sensing, visible in dmesg as:
-snd_hda_codec_realtek hdaudioC0D0: Mic=0x19
+snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x19
[ Actually the essential change is the location of the jack; the
driver created "Front Mic Jack" without the matching volume / mute
control element due to its jack location, which confused PA.
-- tiwai ]
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/8f4f9b20-0aeb-f8f1-c02f-fd53c09679f1@fbihome.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen
Laptop) is fixed by the same workaround applied to other AMD chips.
Update the driver_data entry for Raven (1022:15e3) to use the newly
introduced preset, AZX_DCAPS_PRESET_AMD_SB. Since it already contains
AZX_DCAPS_PM_RUNTIME, we can drop that bit, too.
Reported-and-tested-by: Dennis Padiernos <depadiernos@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190920073040.31764-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Quite a big update this time around, particularly in the core
where we've had a lot of cleanups from Morimoto-san - there's
not much functional change but quite a bit of modernization
going on. We've also seen a lot of driver work, a lot of it
cleanups but also some particular drivers.
- Lots and lots of cleanups from Morimoto-san and Yue Haibing.
- Lots of cleanups and enhancements to the Freescale, sunxi dnd
Intel rivers.
- Initial Sound Open Firmware suppot for i.MX8.
- Removal of w90x900 and nuc900 drivers as the platforms are
being removed.
- New support for Cirrus Logic CS47L15 and CS47L92, Freescale
i.MX 7ULP and 8MQ, Meson G12A and NXP UDA1334
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl13cr4THGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0NKuB/9fvRIh6bJ4pUA26Bc7+shJQ1BtC/MN
jo1G4maN+hY5ZUwE5hvg04S6W6Unm1iNotQecKcF43Vh/4SZNiLtfSEM4b/6IBWw
IFUU6xDz8Q4HbF4HJMotpKQKMABpfds5flH2e1YrrNoMH+KlkC9kJOR26B2W36xW
TZclfquCDICxr8M7eYGM7N5hOqSrlugyWBZqTTnTDnsMrW4SAaH2HYwFhaeayd+I
ECyaXIoUHvo4FX5ueZv/mzBiMl0z4rgXn3tuqI6a8LoWJdRZTkcSQabtuIC+wmxb
P734RY6vjSUYZrv03cAtxHDrSVoC/RYedOzhT+iFF6y/NHzdu701lsJb
=aD0T
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v5.4
Quite a big update this time around, particularly in the core
where we've had a lot of cleanups from Morimoto-san - there's
not much functional change but quite a bit of modernization
going on. We've also seen a lot of driver work, a lot of it
cleanups but also some particular drivers.
- Lots and lots of cleanups from Morimoto-san and Yue Haibing.
- Lots of cleanups and enhancements to the Freescale, sunxi dnd
Intel rivers.
- Initial Sound Open Firmware suppot for i.MX8.
- Removal of w90x900 and nuc900 drivers as the platforms are
being removed.
- New support for Cirrus Logic CS47L15 and CS47L92, Freescale
i.MX 7ULP and 8MQ, Meson G12A and NXP UDA1334
The pci express variant of the digigram lx6464es card has a different
device ID, but works without changes to the driver.
Thanks to Nikolas Slottke for reporting and testing.
Signed-off-by: Tim Blechmann <tim@klingt.org>
Link: https://lore.kernel.org/r/20190906082119.40971-1-tim@klingt.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This notebook has 6 built in speakers for 5.1 surround support, however
only two got autodetected and have also not been assigned correctly.
This patch enables all speakers and also fixes muting when headphones are
plugged in.
The speaker layout is as follows:
pin 0x15 Front Left / Front Right
pin 0x18 Front Center / Subwoofer
pin 0x1b Rear Left / Rear Right (Surround)
The quirk will be enabled automatically on this hardware, but can also be
activated manually via the model=aspire-ethos module parameter.
Caveat: pin 0x1b is shared between headphones jack and surround speakers.
When headphones are plugged in, the surround speakers get muted
automatically by the hardware, however all other speakers remain
unmuted. Currently it's not possible to make use of the generic automute
function in the driver, because such shared pins are not supported.
If we would change the pin settings to identify the pin as headphones,
the surround channel and thus the ability to select 5.1 profiles would
get lost.
This quirk solves the above problem by monitoring jack state of 0x1b and
by connecting/disconnecting all remaining speaker pins when something
gets plugged in or unplugged from the headphones jack port.
Signed-off-by: Sergey Bostandzhyan <jin@mediatomb.cc>
Link: https://lore.kernel.org/r/20190906093343.GA7640@xn--80adja5bqm.su
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Variable pcm_idx is being initialized with a value that is never read
and is being re-assigned immediately afterwards. The assignment is
redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190905154826.5916-1-colin.king@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This ThinkCentre machine has a new realtek codec alc222, it is not
in the support list, we add it in the realtek.c then this machine
can apply FIXUPs for the realtek codec.
And this machine has two front mics which can't be handled
by PA so far, it uses the pin 0x18 and 0x19 as the front mics, as
a result the existing FIXUP ALC294_FIXUP_LENOVO_MIC_LOCATION doesn't
work on this machine. Fortunately another FIXUP
ALC283_FIXUP_HEADSET_MIC also can change the location for one of the
two mics on this machine.
Link: https://lore.kernel.org/r/20190904055327.9883-1-hui.wang@canonical.com
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Original pin node values of ASUS UX431FL with ALC294:
0x12 0xb7a60140
0x13 0x40000000
0x14 0x90170110
0x15 0x411111f0
0x16 0x411111f0
0x17 0x90170111
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x4066852d
0x1e 0x411111f0
0x1f 0x411111f0
0x21 0x04211020
1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
route become confused. So, the output volume cannot be changed by
setting.
2. Misses the headset mic pin node.
This patch disables the confusing speaker (NID 0x14) and enables the
headset mic (NID 0x19).
Link: https://lore.kernel.org/r/20190902100054.6941-1-jian-hong@endlessm.com
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HP Pavilion 15 (AMD Ryzen-based model) with 103c:84e7 needs the same
quirk like HP Envy/Spectre x360 for enabling the mute LED over Mic3 pin.
[ rearranged in the SSID number order by tiwai ]
Signed-off-by: Sam Bazley <sambazley@fastmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change to shuffle the codec initialization procedure for
Realtek via commit 607ca3bd22 ("ALSA: hda/realtek - EAPD turn on
later") caused the silent output on some machines. This change was
supposed to be safe, but it isn't actually; some devices have quirk
setups to override the EAPD via COEF or BTL in the additional verb
table, which is applied at the beginning of snd_hda_gen_init(). And
this EAPD setup is again overridden in alc_auto_init_amp().
For recovering from the regression, tell snd_hda_gen_init() not to
apply the verbs there by a new flag, then apply the verbs in
alc_init().
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727
Fixes: 607ca3bd22 ("ALSA: hda/realtek - EAPD turn on later")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since the chained quirks via chained_before flag is applied before the
depth check, it may lead to the endless recursive calls, when the
chain were set up incorrectly. Fix it by moving the depth check at
the beginning of the loop.
Fixes: 1f57825077 ("ALSA: hda - Add chained_before flag to the fixup entry")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we disallow the runtime PM of the HD-audio controller if
it's bound with HDMI/DP on Nvidia / AMD unless it's for dGPU. This is
for keeping the link up to get the proper notification for ELD
hotplug.
As explained in the commit 37a3a98ef6 ("ALSA: hda - Enable runtime
PM only for discrete GPU"), this keep-power-up behavior is rather a
stop-gap solution until the ELD notification via audio component.
And now we finally got the audio component for these graphics drivers
via commit ade49db337 ("ALSA: hda/hdmi - Allow audio component for
AMD/ATI and Nvidia HDMI"), so it's time to change.
This patch makes HD-audio controller again runtime-suspendable when
the device gets bound with audio component in HDMI codec driver. For
making it easier to access from the codec driver, move the flag into
the common hda_bus object instead of hda_intel flag. Also rename it
to keep_power, to indicate the actual meaning.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull USB validation patches. It's based on the latest 5.3 development
branch, so we shall catch up the whole things.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Lenovo ThinkCentre M73 and M93 don't seem to have a proper beep
although the driver tries to probe and set up blindly.
Blacklist these machines for suppressing the beep creation.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204635
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some Realtek codec parsers didn't check the availability of PC beep.
Add has_cdefine_beep() check appropriately.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds a new PCI subsys ID for the SBZ, as found and tested by
me and some reddit users.
Link: https://lore.kernel.org/lkml/20190819204008.14426-1-p.rekowski@gmail.com
Signed-off-by: Paweł Rekowski <p.rekowski@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
"enabled" parameter historically referred to the device input or
output, not to the led indicator. After the changes added with the led
helper functions the mic mute led logic refers to the led and not to
the mic input which caused led indicator to be negated.
Fixing logic in cxt_update_gpio_led and updated
cxt_fixup_gpio_mute_hook
Also updated debug messages to ease further debugging if necessary.
Fixes: 184e302b46 ("ALSA: hda/conexant - Use the mic-mute LED helper")
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jeronimo Borque <jeronimo@borque.com.ar>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have another Dell laptop which needs the DELL4_MIC_NO_PRESENCE,
and this laptop has different pincfg definitions from existing
ones in the pintbl, rather adding a new entry, let us define
a tbl in the fallback_pin_fixup_tbl and this tbl will match
all dell machines with alc289 codec and the pins of 0x19 and 0x1b
are undef by default.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
With the existing pintbl, we already have many entries in it. it is
better to figure out a new way to reduce the size of the pintbl.
We plan to define a new tbl which will match more machines with a
single tbl, To do that, this function doesn't need to match all valid
pins between machine and tbl, it just needs to match all pins defined
in the tbl with the machine.
And the plan is to move some tbls from pin_fixup_tbl to
fallback_pin_fixup_tbl gradually.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We don't need to deal with the unsol events for Intel chips that are
tied with the graphics via audio component notifier. Although the
presence of the audio component is checked at the beginning of
hdmi_unsol_event(), better to short cut by dropping unsol_event ops.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204565
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Make codec enter D3 before rebooting or poweroff can fix the noise
issue on some laptops. And in theory it is harmless for all codecs
to enter D3 before rebooting or poweroff, let us add a generic
reboot_notify, then realtek and conexant drivers can call this
function.
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have 3 new lenovo laptops which have conexant codec 0x14f11f86,
these 3 laptops also have the noise issue when rebooting, after
letting the codec enter D3 before rebooting or poweroff, the noise
disappers.
Instead of adding a new ID again in the reboot_notify(), let us make
this function apply to all conexant codec. In theory make codec enter
D3 before rebooting or poweroff is harmless, and I tested this change
on a couple of other Lenovo laptops which have different conexant
codecs, there is no side effect so far.
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/pci/hda/patch_sigmatel.c:981:30: warning:
stac9200_core_init defined but not used [-Wunused-const-variable=]
It is never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HP Envy x360 (AMD Ryzen-based model) with 103c:8497 needs the same
quirk like HP Spectre x360 for enabling the mute LED over Mic3 pin.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204373
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we set hdac_stream.fifo_size field only for the playback
stream by some odd reason I forgot, while this field isn't referred in
any places. Actually this fifo_size field would have been required in
the position report correction for VIA chipset, but due to the lack of
the fifo_size set for capture streams, snd-hda-intel driver fetches
the register by itself.
This patch straightens and simplifies the code by setting the
fifo_size field for both playback and capture streams, and use it in
the HD-audio controller driver.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In snd_hda_parse_generic_codec(), 'spec' is allocated through kzalloc().
Then, the pin widgets in 'codec' are parsed. However, if the parsing
process fails, 'spec' is not deallocated, leading to a memory leak.
To fix the above issue, free 'spec' before returning the error.
Fixes: 352f7f914e ("ALSA: hda - Merge Realtek parser code to generic parser")
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[ This is rather a revival of the patch Tomas sent in months ago, but
applying only with the quirk model option -- tiwai ]
Hard coded coefficients to make Huawuei Matebook X right speaker
work. The Matebook X has a ALC298, please refer to bug 197801 on
how these numbers were reverse engineered from the Windows driver
The reversed engineered sequence represents a repeating pattern
of verbs, and the only values that are changing periodically are
written on indexes 0x23 and 0x25:
0x500, 0x23
0x400, VALUE1
0x500, 0x25
0x400, VALUE2
* skipped reading sequences (0x500 - 0xc00 sequences are ignored)
* static values from reverse engineering are used
NOTE: since a significant risk is still considered, this is provided
as an experimental fix that isn't applied as default for now. For
enabling the fix, you'll have to choose huawei-mbx-stereo via model
option of snd-hda-intel module.
If we get feedback from users that this works stably, we may apply it
per default.
[ Some coding style fixes and replacement with AC_VERB_* by tiwai ]
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197801
Signed-off-by: Tomas Espeleta <tomas.espeleta@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For the sake of debugging, show each response that took too long time
and its corresponding last verb. Since such an error happens in
series once when started, use the ratelimited variant for suppressing
the flood.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/pci/ac97/ac97_codec.c:599:38: warning:
snd_ac97_controls_master_mono defined but not used [-Wunused-const-variable=]
It is never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
MSI MPG X570 board is with another AMD HD-audio controller (PCI ID
1022:1487) and it requires the same workaround applied for X370, etc
(PCI ID 1022:1457).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HD-audio drivers access to the mmio registers indirectly via the
corresponding bus->io_ops callbacks. This is because some platform
(notably Tegra SoC) requires the word-aligned access. But it's rather
a rare case, and other platforms suffer from the penalties by indirect
calls unnecessarily.
This patch is an attempt to optimize and cleanup for this situation.
Now the special aligned access is used only when a new kconfig
CONFIG_SND_HDA_ALIGNED_MMIO is set. And the HD-audio core itself
provides the aligned MMIO access helpers instead of the driver side.
If Kconfig isn't set (as default), the standard helpers like readl()
or writel() are used directly.
A couple of places in ASoC Intel drivers have the access via io_ops
reg_writel(), and they are replaced with the direct writel() calls.
And now with this patch, the whole bus->io_ops becomes empty, so it's
dropped completely. The bus initialization functions are changed
accordingly as well to drop the whole bus->io_ops.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HD-audio core allocates and releases pages via driver's specific
dma_alloc_pages and dma_free_pages ops defined in bus->io_ops. This
was because some platforms require the uncached pages and the handling
of page flags had to be done locally in the driver code.
Since the recent change in ALSA core memory allocator, we can simply
pass SNDRV_DMA_TYPE_DEV_UC for the uncached pages, and the only
difference became about this type to be passed to the core allocator.
That is, it's good time for cleaning up the mess.
This patch changes the allocation code in HD-audio core to call the
core allocator directly so that we get rid of dma_alloc_pages and
dma_free_pages io_ops. If a driver needs the uncached pages, it has
to set bus->dma_type right after the bus initialization.
This is merely a code refactoring and shouldn't bring any behavior
changes.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A long-time problem on the recent AMD chip (X370, X470, B450, etc with
PCI ID 1022:1457) with Realtek codecs is the crackled or distorted
sound for capture streams, as well as occasional playback hiccups.
After lengthy debugging sessions, the workarounds we've found are like
the following:
- Set up the proper driver caps for this controller, similar as the
other AMD controller.
- Correct the DMA position reporting with the fixed FIFO size, which
is similar like as workaround used for VIA chip set.
- Even after the position correction, PulseAudio still shows
mysterious stalls of playback streams when a capture is triggered in
timer-scheduled mode. Since we have no clear way to eliminate the
stall, pass the BATCH PCM flag for PA to suppress the tsched mode as
a temporary workaround.
This patch implements the workarounds. For the driver caps, it
defines a new preset, AXZ_DCAPS_PRESET_AMD_SB. It enables the FIFO-
corrected position reporting (corresponding to the new position_fix=6)
and enforces the SNDRV_PCM_INFO_BATCH flag.
Note that the current implementation is merely a workaround.
Hopefully we'll find a better alternative in future, especially about
removing the BATCH flag hack again.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit bfcba288b9 ("ALSA - hda: Add support for link audio time
reporting") introduced the conditional PCM hw info setup, but it
overwrites the global azx_pcm_hw object. This will cause a problem if
any other HD-audio controller, as it'll inherit the same bit flag
although another controller doesn't support that feature.
Fix the bug by setting the PCM hw info flag locally.
Fixes: bfcba288b9 ("ALSA - hda: Add support for link audio time reporting")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the new PCI ID 0x1d17 0x3288 Zhaoxin controller support
Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The legacy HD-Audio driver cannot handle Skylake+ platforms with
digital microphones. For those platforms, the SOF or SST drivers need
to be used.
This patch provides an automatic way of detecting the presence of
DMICs using NHTL information reported by the BIOS. A kernel kconfig
option or a kernel module parameter provide an opt-in means of
stopping the probe. The kernel would then look for an alternate driver
registered for the same PCI ID to probe.
With this capability, distros no longer have to blacklist
snd-hda-intel, but still need to make sure the SOF/SST drivers are
functional by providing the relevant firmware and topology files in
/lib/firmware/intel
The coexistence between SOF and SST drivers and their dynamic
detection is not addressed by this patch, different mechanisms need to
be used, e.g. DMI-based quirks.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The last fallback of CORB/RIRB communication error recovery is to turn
on the single command mode, and this last resort usually means that
something is really screwed up. Instead of a normal dev_err(), show
the error more clearly with dev_WARN() with the caller stack trace.
Also, show the bus-reset fallback also as an error, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of using kmalloc + memcpy, use kmemdup
to simplify the code.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This conexant codec isn't in the supported codec list yet, the hda
generic driver can drive this codec well, but on a Lenovo machine
with mute/mic-mute leds, we need to apply CXT_FIXUP_THINKPAD_ACPI
to make the leds work. After adding this codec to the list, the
driver patch_conexant.c will apply THINKPAD_ACPI to this machine.
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It turned out that the recent Intel HD-audio controller chips show a
significant stall during the system PM resume intermittently. It
doesn't happen so often and usually it may read back successfully
after one or more seconds, but in some rare worst cases the driver
went into fallback mode.
After trial-and-error, we found out that the communication stall seems
covered by issuing the sync after each verb write, as already done for
AMD and other chipsets. So this patch enables the write-sync flag for
the recent Intel chips, Skylake and onward, as a workaround.
Also, since Broxton and co have the very same driver flags as Skylake,
refer to the Skylake driver flags instead of defining the same
contents again for simplification.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901
Reported-and-tested-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_hdac_ext_bus_device_exit() has been recently modified
to no longer free the hdac device. SOF allocates memory for
hdac_device and hda_hda_priv with kzalloc. Make them
device-managed instead so that they will be freed when the
SOF driver is unloaded.
Because of the above change, hda_codec is device-managed and
it will be freed when the ASoC device is removed. Freeing
the codec in snd_hda_codec_dev_release() leads to kernel
panic while unloading and reloading the ASoC driver. So,
avoid freeing the hda_codec for ASoC driver. This is done in
the same patch to avoid bisect failure.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190626070450.7229-1-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
AMD/ATI and Nvidia HDMI codec drivers didn't have the audio component
binding like i915, but it worked only with the traditional HD-audio
unsolicited event for the HDMI hotplug detection and the ELD read-up
thereafter. This has been a problem in many ways: first of all, it
goes through the hardware event transition (from GPU register write,
HD-audio controller trigger, and finally to HD-audio unsolicited event
handling), which is often unreliable and may miss some opportunities.
Second, each unsol event handling and ELD read-up need the explicit
power up / down when the codec is in the runtime suspend. Last but
not least, which is the most important, the hotplug wakeup may be
missed when the HD-audio controller is in runtime suspend. Especially
the last point is a big problem due to the recent change relevant with
vga_switcheroo that forcibly enables the runtime PM for AMD HDMI
controllers.
These issues are solved by introducing the audio component; the
hotplug notification is done by a direct function callback, which is
more accurate and reliable, and it can be processed without the actual
hardware access, i.e. no runtime PM trigger is needed, and the
HD-audio gets the event even if it's in runtime suspend. The same for
ELD query, as it's read directly from the cached ELD bytes stored in
the DRM driver, hence the whole hardware access can be skipped.
So here it is: this patch implements the audio component binding with
AMD/ATI and Nouveau DRM drivers. The biggest difference from i915
implementation is that this binding is fully optional and it can be
enabled asynchronously on the fly. That is, the driver will switch
from the HD-audio unsolicited event to the notify callback once when
the DRM component gets bound. Similarly, when DRM driver gets
unloaded, the HDMI event handling returns to the legacy mode, too.
Also, another difference from i915 is that the new code registers the
component in the codec driver, while i915 HDMI codec assumes the
component binding was already done in the HD-audio controller driver.
Hence the new code does need to de-register the component binding at
the codec exit, too.
Some other details:
- The match component ops assumes that both VGA and HD-audio
controller PCI entries belong to the same PCI bus, and only accepts
such an entry.
- The pin2port audio_ops is implemented with assumption of the fixed
widget layout. For AMD, it's starting from 3, with step 2 (3, 5, 7,
...), while for Nvidia, it's starting from 4, with step 1 (4, 5, 6,
...)
As of this patch, the corresponding component isn't implemented in DRM
side, so this change alone won't give any benefit. By the following
changes in DRM sides, the mission will be completed.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HDMI jack handling reports the state change always via
snd_jack_report() whenever hdmi_present_sense() is called, even if the
state itself doesn't change from the previous time. This is mostly
harmless but still a bit confusing to user-space.
This patch reduces such spurious jack state changes and reports only
when the state really changed. Also, as a minor optimization, avoid
overwriting the pin ELD data when the state is identical.
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
