In case HDA controller becomes active, but codec is runtime suspended,
jack detection is not successful and no interrupt is raised. This has
been observed with multiple Realtek codecs and HDA controllers from
different vendors. Bug does not occur if both codec and controller are
active, or both are in suspend. Bug can be easily hit on desktop systems
with no built-in speaker.
The problem can be fixed by powering up the codec once after every
controller runtime resume. Even if codec goes back to suspend later, the
jack detection will continue to work. Add a flag to 'hda_codec' to
describe codecs that require this flow from the controller driver.
Modify __azx_runtime_resume() to use pm_request_resume() to make the
intent clearer.
Mark all Realtek codecs with the new forced_resume flag.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209379
Cc: Kailang Yang <kailang@realtek.com>
Co-developed-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201012102704.794423-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Replace commas with semicolons. What is done is essentially described by
the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
// <smpl>
@@ expression e1,e2; @@
e1
-,
+;
e2
... when any
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/1602407979-29038-5-git-send-email-Julia.Lawall@inria.fr
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Current hdac_i915 uses a static completion instance to wait
for i915 driver to complete the component bind.
This design is not safe if multiple HDA controllers are active and
communicating with different i915 instances, and can lead to list
corruption and failed audio driver probe.
Fix the design by moving completion mechanism to common acomp
code and remove the related code from hdac_i915.
Fixes: 7b882fe3e3 ("ALSA: hda - handle multiple i915 device instances")
Co-developed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201006161722.500256-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On a HP ZCentral, the front Mic could not be detected.
The codec of the HP ZCentrol is alc671 and it needs to override the pin
configuration to enable the headset mic.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201008105645.65505-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The "count" variable needs to be capped on every path so that we don't
copy too much information to the user.
Fixes: 618eabeae7 ("ALSA: bebob: Add hwdep interface")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201007074928.GA2529578@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect
the headset microphone and another headphone jack until
ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied.
The NID 0x15 maps as the headset microphone and NID 0x19 maps as another
headphone jack. Also need the function like alc887_fixup_asus_jack to
enable the audio jacks.
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201007052224.22611-1-jhp@endlessos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After installing archlinux, the mute led and micmute led are not working
at all. This patch fix this issue by applying a fixup from similar
model. These mute leds are confirmed working on HP Elitebook 845 G7.
Signed-off-by: Qiu Wenbo <qiuwenbo@kylinos.com.cn>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201002124454.7240-1-qiuwenbo@kylinos.com.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Align with recent change to forbid runtime suspend during codec
init in snd_hda_codec_device_new(), with matching call to
allow suspend at end of hdac_hda_codec_probe().
In snd-hda-intel, call to snd_hda_set_power_save() at end of
controller probe does the same thing, but ASoC controller drivers
do not modify runtime settings for codecs, so this has to be done
in codec drivers, and in this case in hdac_hda.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200930114140.3839617-3-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For certain codecs (like Realtek), pm_runtime_forbid() is invoked
in the probe function after build_controls(). In a stress test,
its observed occasionally that runtime PM calls are invoked
before controls are built. This causes the codec to be
runtime suspended before probe completes. Because of this, not all
controls are enumerated correctly, and audio does not work until
system is rebooted.
This issue being common across all codecs, pm_runtime_forbid() is
called when the codec object is created to fix this issue.
A codec enables or disables runtime pm in its own probe function.
Multiple stress tests of 2000+ cycles has been done to test the fix.
Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Signed-off-by: Emmanuel Jillela <emmanuel.jillela@intel.com>
Reviewed-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200930114140.3839617-2-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If the caller of enable_callback_mst() passes a cb func, the callee
function will malloc memory and link this cb func to the list
unconditionally. This will introduce problem if caller is in the
hda_codec_ops.init() since the init() will be repeatedly called in the
codec rt_resume().
So far, the patch_hdmi.c and patch_ca0132.c call enable_callback_mst()
in the hda_codec_ops.init().
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200930055146.5665-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Recently we enabled a HP AIO machine, we found the mic on the machine
couldn't record any sound and it couldn't detect plugging and
unplugging as well.
Through debugging we found the mic is set to manual detect mode, after
setting it to auto detect mode, it could detect plugging and
unplugging and could record sound.
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200928080117.12435-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Drop the kerneldoc markup for connectivity_check() as it's an
static helper function. Fixes the following make W=1 warning:
sound/hda/hdac_i915.c:80: warning: Function parameter or member 'i915' not described in 'connectivity_check'
sound/hda/hdac_i915.c:80: warning: Function parameter or member 'hdac' not described in 'connectivity_check'
Fixes: 7b882fe3e3 ('ALSA: hda - handle multiple i915 device instances')
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200924161027.3402260-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Recently we applied a fix to cover the whole OSS sequencer ioctls with
the mutex for dealing with the possible races. This works fine in
general, but in theory, this may lead to unexpectedly long stall if an
ioctl like SNDCTL_SEQ_SYNC is issued and an event with the far future
timestamp was queued.
For fixing such a potential stall, this patch changes the mutex lock
applied conditionally excluding such an ioctl command. Also, change
the mutex_lock() with the interruptible version for user to allow
escaping from the big-hammer mutex.
Fixes: 80982c7e83 ("ALSA: seq: oss: Serialize ioctls")
Suggested-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20200922083856.28572-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch extends support for DJM-250MK2 and allows mapping
playback and capture channels to available sources.
Configures the card through USB commands.
Signed-off-by: František Kučera <franta-linux@frantovo.cz>
Link: https://lore.kernel.org/r/20200922144206.10472-1-konference@frantovo.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 34dedd2a83.
According to Realtek, volume FU works for line-in.
I can confirm volume control works after device firmware is updated.
Fixes: 34dedd2a83 ("ALSA: usb-audio: Disable Lenovo P620 Rear line-in volume control")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200915103925.12777-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change in lockdep for read lock caused the deadlock
warnings in ALSA control code which uses the read_lock() for
notification and else while write_lock_irqsave() is used for adding
and removing the list entry. Although a deadlock would practically
never hit in a real usage (the addition and the deletion can't happen
with the notification), it's better to fix the read_lock() usage in a
semantically correct way.
This patch replaces the read_lock() calls with read_lock_irqsave()
version for avoiding a reported deadlock. The notification code path
takes the irq disablement in anyway, and other code paths are very
short execution, hence there shouldn't be any big performance hit by
this change.
Fixes: e918188611 ("locking: More accurate annotations for read_lock()")
Reported-by: syzbot+561a74f84100162990b2@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200922084953.29018-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The CONTROLLER_IN_GPU() macro has different semantics than
the similarly named macro in hda_intel.c. The name is also
misleading as the macro is used to apply a Intel HSW/BDW
programming logic for HDA controller clock configuration.
Rename macro to reflect the actual implementation.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200921141741.2983072-5-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently i915_component_master_match() will return the first matching
i915 instance. This does not work in case system has multiple i915
and HDA audio controller instances.
Add a new connectivity check that handles following cases:
- i915 and HDA controller on same PCI bus
- discrete GPU with embedded HDA audio controller connected
via PCI bridge
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200921141741.2983072-4-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Using compat_alloc_user_space() tends to add complexity
to the ioctl handling, so I am trying to remove it everywhere.
The two callers in sound/core can rewritten to just call
the same code that operates on a kernel pointer as the
native handler.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200918095642.1446243-1-arnd@arndb.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Lenovo P520, the front panel headset LED isn't lit up right now.
Realtek states that the LED needs to be enabled by ALC233's GPIO2, so
let's do it accordingly to light the LED up.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Hui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200914070231.13192-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We found a Mic detection issue on many Lenovo laptops, those laptops
belong to differnt models and they have different audio design like
internal mic connects to the codec or PCH, they all have this problem,
the problem is if plugging a headset before powerup/reboot the
machine, after booting up, the headphone could be detected but Mic
couldn't. If we plug out and plug in the headset, both headphone and
Mic could be detected then.
Through debugging we found the codec on those laptops are same, it is
alc257, and if we don't disable the 3k pulldown in alc256_shutup(),
the issue will be fixed. So far there is no pop noise or power
consumption regression on those laptops after this change.
Cc: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200914065118.19238-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
clang static analysis flags this problem
hpioctl.c:513:7: warning: Branch condition evaluates to
a garbage value
if (pci.ap_mem_base[idx]) {
^~~~~~~~~~~~~~~~~~~~
If there is a failure in the middle of the memory space loop,
only some of the memory spaces need to be cleaned up.
At the error handler, idx holds the number of successful
memory spaces mapped. So rework the handler loop to use the
old idx.
There is a second problem, the memory space loop conditionally
iomaps()/sets the mem_base so it is necessay to initize pci.
Fixes: 719f82d398 ("ALSA: Add support of AudioScience ASI boards")
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20200913165230.17166-1-trix@redhat.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Most of this is various driver specific fixes, none of which are
terribly exciting in themselves, plus one core fix adding and using a
new DAI lookup function to deal with a lockdep warning.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9bX1gTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0F04B/44DFfhh3KELcZkIiG4CLfoLRl1g3iw
EEjFHJRJkpVjKJmTGeVgUTYI6UOH4U9abMGey6s4uCZW2AEb5CGODiWlcKAfy7l2
i7XHbbJacsiJKU6ezR66azpuF+Hb5z/Z9AKfVuCDHHItXuj09A4H7V45AAd1IbEU
KWdPSAcex18OgEKhYZNxBkMapsTJQl04cDUWiel7PYT7nJYxLAz46JMI2y4IJ3S8
tXed+T1IDflruk819Mn1XAxYzvOVPcNRD6hHuSUEECV/BZcLJFEHPkvnLKEjKwNe
so66doBMcAGkuGoYlURh2otZWgoX56e7IYrqX5m2N1fIskSRkOeNl5J4
=WLI9
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.9-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.9
Most of this is various driver specific fixes, none of which are
terribly exciting in themselves, plus one core fix adding and using a
new DAI lookup function to deal with a lockdep warning.
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In FireWire driver, a tasklet is
still used for offloading the AMDTP PCM stream handling. It can be
achieved gracefully with a work queued, too.
This patch replaces the tasklet usage in firewire-lib driver with a
simple work. The conversion is fairly straightforward but for the
in_interrupt() checks that are replaced with the check using the
current_work().
Note that in_interrupt() in amdtp_packet tracepoint is still kept as
is. This is the place that is probed by both softirq of 1394 OHCI and
a user task of a PCM application, and the work handling is already
filtered in amdtp_domain_stream_pcm_pointer().
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200909163659.21708-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The miXart driver has been already converted to use the threaded IRQ
instead of tasklet while there is a remaining comment still mentioning
a tasklet. Update the comment appropriately.
Fixes: 8d3a8b5cb5 ("ALSA: mixart: Use nonatomic PCM ops")
Link: https://lore.kernel.org/r/20200903104131.21097-12-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In ASIHPI driver, a tasklet is
still used for offloading the PCM IRQ handling. It can be achieved
gracefully with a threaded IRQ, too.
This patch replaces the tasklet usage in asihpi driver with a threaded
IRQ. It also simplified some call patterns.
Link: https://lore.kernel.org/r/20200903104131.21097-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In Riptide driver, a tasklet is
still used for offloading the PCM IRQ handling. It can be achieved
gracefully with a threaded IRQ, too.
This patch replaces the tasklet usage in riptide driver with a
threaded IRQ.
Link: https://lore.kernel.org/r/20200903104131.21097-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In HDSP-MADI driver, a tasklet is
still used for offloading the MIDI I/O handling (optional via mixer
switch). It can be achieved gracefully with a work queued, too.
This patch replaces the tasklet usage in HDSP-MADI driver with a
simple work. The conversion is fairly straightforward. The only
significant difference is that the work initialization is moved to the
right place in snd_hdspm_create() and cancel_work_sync() is always
called in snd_hdspm_free() to assure killing the pending works.
Link: https://lore.kernel.org/r/20200903104131.21097-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In HDSP driver, a tasklet is still
used for offloading the MIDI I/O handling (optional via mixer
switch). It can be achieved gracefully with a work queued, too.
This patch replaces the tasklet usage in HDSP driver with a simple
work. The conversion is fairly straightforward. The only significant
difference is that a superfluous tasklet_kill() call is removed from
snd_hdap_midi_input_trigger().
Link: https://lore.kernel.org/r/20200903104131.21097-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In aloop driver, a tasklet is still
used for offloading the timer event task. It can be achieved
gracefully with a work queued, too.
This patch replaces the tasklet usage in aloop driver with a simple
work.
Link: https://lore.kernel.org/r/20200903104131.21097-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In UA101 driver, a tasklet is still
used for handling the output URBs. It can be achieved gracefully with
a work queued in the high-prio system workqueue, too.
This patch replaces the tasklet usage in UA101 driver with a simple
work.
Link: https://lore.kernel.org/r/20200903104131.21097-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In USB-audio driver, a tasklet is
still used in MIDI interface code for handling the output byte
stream. It can be achieved gracefully with a work queued in the
high-prio system workqueue.
This patch replaces the tasklet usage in USB-audio driver with a
simple work.
Link: https://lore.kernel.org/r/20200903104131.21097-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In ALSA core timer API, the
callbacks can be offlined to a tasklet when a flag is set in the timer
backend. It can be achieved gracefully with a work queued in the
high-prio system workqueue.
This patch replaces the usage of tasklet in ALSA timer API with a
simple work. Currently the tasklet feature is used only in the system
timer and hrtimer backends, so both are patched to use the new flag
name SNDRV_TIMER_HW_WORK, too.
Link: https://lore.kernel.org/r/20200903104131.21097-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. This patch replaces the usage of
tasklet in pcsp driver with a simple work. In pcsp driver, a global
tasklet is used for offloading the period-elapse handling in the
hrtimer callback (introduced in commit 96c7d478ef "ALSA: pcsp - Fix
locking messes in snd-pcsp"). It can be achieved gracefully with a
work queued in the high-prio system workqueue.
This also changes tasklet_kill() with cancel_work_sync() in the
sync_stop callback, which is anyway better to assure canceling the
pending tasks.
Link: https://lore.kernel.org/r/20200903104131.21097-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Back-merge to apply the tasklet conversion patches that are based
on the already applied tasklet API changes on 5.9-rc4.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Mic connects to the Nid 0x19, but the configuration of Nid 0x19
is not defined to Mic, and also need to set the coeff to enable the
auto detection on the Nid 0x19. After this change, the Mic plugging
in or plugging out could be detected and could record the sound from
the Mic.
And the coeff value is suggested by Kailang of Realtek.
Cc: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200909020041.8967-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According to its datasheet, after reset this codec goes into sleep
mode. In this mode, any register accessing should be avoided except for
exiting sleep mode. Hence this commit moves SLEEP_CFG access before any
register accessing.
Signed-off-by: Camel Guo <camelg@axis.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200908083521.14105-2-camel.guo@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
