The amp and caps hashes aren't protected properly for concurrent
accesses. Protect them via a new mutex now.
But it can't be so simple as originally thought: since the update of a
hash table entry itself might trigger the power-up sequence which
again accesses the hash table, we can't cover the whole function
simply via mutex. Thus the update part has to be split from the mutex
and revalidated.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The controller is compatible with HD-audio 1.0a with some specific
restrictions.
- The BDLE entries can't be over 4k boundary
- No position-buffer and no MSI
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Check the power_transition up/down state instead of boolean bit, so
that the power-up sequence can cancel the pending power-down work
properly. Also, by moving cancel_delayed_work_sync() before the
actual power-up sequence, make sure that the delayed power-down is
completed.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since the recent commit, the resume procedure is always performed at
the resume time. This makes the pre_resume hack for VREF mute LED on
some HP laptops superfluous. As this is the only user of pre_resume
(and there is no user of post_suspend) ops, let's kill them again.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When an IRQ for some reason gets lost, we wait up to a second using
udelay, which is CPU intensive. This patch improves the situation by
waiting about 30 ms in the CPU intensive mode, then stepping down to
using msleep(2) instead. In essence, we trade some granularity in
exchange for less CPU consumption when the waiting time is a bit longer.
As a result, PulseAudio should no longer be killed by the kernel
for taking up to much RT-prio CPU time. At least not for *this* reason.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Tested-by: Arun Raghavan <arun.raghavan@collabora.co.uk>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move the fixup helper functions in patch_realtek.c to hda_auto_parser.c
so that they can be used in other codec drivers like patch_conexant.c.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some power-saving states have been left unchanged in
snd_hda_codec_reset(), and this is a potential danger because the
function may be called in various situations including the continuous
operation after that call.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a fix for the problem in commit 785f857d1c, the pop noise
issue on some machines with ALC269. The problem was the uninitialized
state after the resume due to the delayed resume of the codec chips.
In that commit, we tried to fix by forcibly putting the codec to D3 at
suspend. But, this still also leaves the uninitialized state after
resume, and it _might_ be still problematic with some BIOS. Since the
commit turned out to regress another issues, we reverted it in the
end.
Now, in this fix, try to fix by turning on the codec immediately at
the resume path. We need to take care of the power-saving in this
case. When the device is woken up at the power-saved state, it should
go power-saving again after the resume.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 785f857d1c.
The commit causes a problem with the wrong D3 state after suspend
because the call of hda_set_power_state() involves with the power-up
sequence, which changes the power_count, and this confuses the resume
sequence that checks the power_count as well.
Originally, this go-to-D3 sequence should be a simple task without the
power-up sequence. But, it'd need some proper sanity checks in the
case of power-saved state, so it's not too easy to write now in the
3.4-rc cycle.
In short, the safest option now is to revert this affecting commit.
Of course, we need to clean up and robustify the power-saving code
better for 3.5 kernel.
Reported-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The call for alc_auto_parse_customize_define() must be done after the
fixup pre-probe initialization. Otherwise SKU_IGNORE fixup won't work
properly (e.g. HP RP5800 with ALC662 codec).
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_hdsp uses its own ioctls to acquire config- and status information.
Expose the corresponding ioctl handler via ioctl_compat, so that 32bit applications can use it on 64bit kernels.
Signed-off-by: Andre Schramm <andre.schramm@iosono-sound.com>
Reviewed-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This assertion seems to imply that chip->dsp_code_to_load is a pointer.
It's actually an integer handle on the actual firmware, and 0 has no
special meaning.
The assertion prevents initialisation of a Darla20 card, but would also
affect other models. It seems it was introduced in commit dd7b254d.
ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting...
ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000
ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware...
ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20
------------[ cut here ]------------
WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]()
Hardware name: Dell DM051
BUG? (!chip->dsp_code_to_load || !chip->comm_page)
Signed-off-by: Mark Hills <mark@pogo.org.uk>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the PCI ID of the Asus Xonar DGX card; it's otherwise
identical with the DG.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull sound fixes from Takashi Iwai:
"A workaround for an ASUS laptop and a few ASoC changes; most of the
commits are tagged for stable, too."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: wm8994: Improve sequencing of AIF channel enables
ALSA: HDA: Add external mic quirk for Asus Zenbook UX31E
ASoC: fsi: update for dmaengine prep_slave_sg fallout.
ASoC: core: Fix card RTD count for deferred probe.
ASoC: cs42l73: don't use negative array index
ASoC: dapm: Ensure power gets managed for line widgets
Pull sound fixes from Takashi Iwai:
"Fixes for a few regressions of HD-audio, originated partly from 3.4
and partly 3.3.
The fixes for ThinkPad docking-station are for 3.3 kernels, thus they
are based on 3.3 then merged back to 3.4, so that they can be merged
to stable tree cleanly. The non-trivial merge conflicts are because
of this action.
In addition, a couple of trivial fixes for documentation and a long-
standing issue in the listing of built-in sound driver at boot time."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/conexant - Set up the missing docking-station pins
ALSA: hda/conexant - Don't set HP pin-control bit unconditionally
ALSA: workaround: change the timing of alsa_sound_last_init()
ALSA: hda/sigmatel - Fix inverted mute LED
ALSA: hda/realtek - Fix regression on Quanta/Gericom KN1
ALSA: fix core/vmaster.c kernel-doc warning
Some old codecs like ALC880 seem to give a bogus pin capability value 0
occasionally. This breaks the new sanity check in snd_hda_set_pin_ctl().
Skip the sanity checks in such a case.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a new helper function to guess the default VREF pin control bits
for mic in. This can be used to set the pin control value safely
matching with the actual pin capabilities.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For setting the pin-control values more safely to match with the
actual pin capability bits, a copule of new helper functions,
snd_hda_set_pin_ctl() and snd_hda_set_pin_ctl_cache(), are
introduced. These are simple replacement of the codec verb write with
AC_VERB_SET_PIN_WIDGET but do more sanity checks and filter out
superfluous pin-control bits if they don't fit with the corresponding
pin capabilities.
Some codecs are screwed up or ignore the command when such a wrong bit
is set. These helpers will avoid such secret errors.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According to the reporter, external mic starts to work if the
laptop-dmic model is used. According to BIOS pin config, all
pins are consistent with the alc269vb_laptop_dmic fixup, except
for the external mic, which is not present.
Cc: stable@kernel.org
BugLink: https://bugs.launchpad.net/bugs/950490
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge fixes for Thinkpad docking-station regressions for 3.3 kernels
back to 3.4. These were committed in that branch to make the stable
merging easier.
Conflicts:
sound/pci/hda/patch_conexant.c
Some output pins on Conexant chips have no HP control bit, but the
auto-parser initializes these pins unconditionally with PIN_HP.
Check the pin-capability and avoid the HP bit if not supported.
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While refactoring the mute-LED handling for HP laptops, I messed up
the polarity check in a wrong way. The red (or the mute-LED if any)
should appear in the muted state, corresponding to GPIO on.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Through the transition to the auto-parser, the support for
Quanta/Gericom KN1 got broken. There are two problems behind it:
- This machine doesn't like the default COEF setup for ALC260 we take
now as default
- BIOS doesn't set the pins correctly at all; especially the machine
uses only the pin 0x0f for both headphone and speaker
This patch adds the fixup as a workaround for these issues.
Reported-and-tested-by: Uros Vampl <mobile.leecher@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull another round of sound fixes from Takashi Iwai:
"A few regression fixes for Realtek HD-audio codecs, mainly specific to
some laptop models."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/realtek - Fix mem leak (and rid us of trailing whitespace).
ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines
ALSA: hda/realtek - Add a fixup entry for Acer Aspire 8940G
ALSA: hda/realtek - Fix GPIO1 setup for Acer Aspire 4930 & co
ALSA: hda/realtek - Add a few ALC882 model strings back
In sound/pci/hda/patch_realtek.c::alc_auto_fill_dac_nids(), in the
'for (;;)' loop, if the 'badness' value returned from
fill_and_eval_dacs() is negative, then we'll return from the function
without freeing the memory we allocated for 'best_cfg', thus leaking.
Fix the leak by kfree()'ing the memory when badness is negative.
While I was there I also noticed some trailing whitespace in the
function that I removed (along with all other trailing whitespace in
the file) - it didn't seem worth-while to do that as two patches, so I
hope it's OK that I just did it all as one patch.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A user reported that setting model=imac24 used to allow sound to work on their
Mac Pro 5,1 machine. Commit 5671087ffa "Move ALC885 macpro and imac24 models
to auto-parser" removed this model option. All Mac machines are now explicitly
handled with a quirk and the auto-parser. This adds a quirk for the device
found on the Mac Pro 5,1 machines.
This (partially) fixes https://bugzilla.redhat.com/show_bug.cgi?id=808559
[sorted the new entry in the ID number order by tiwai]
Reported-by: Gabriel Somlo <somlo@cmu.edu>
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add GPIO1 setup explicitly for Acer Aspire 493x & co.
This could be set by alc_auto_init_amp(), but it's safer to set it
more explicitly in the fixup table.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull sound fixes from Takashi Iwai:
- A series of fixes for Conexant 20549 HD-audio codec chip
- A workaround for HDMI hotplug debug prints that annoyed people
- A fix for the new support of platform DAPM contexts
- Many driver-specific minor fixes
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - hide HDMI/ELD printks unless snd.debug=2
ALSA: sound/isa/sscape.c: add missing resource-release code
sound: sound/oss/msnd_pinnacle.c: add vfrees
ALSA: hda - clean up CX20549 test mixer setup
ALSA: hda - CX20549 doesn't need pin_amp_workaround.
ALSA: hda - Remove CD control from model=benq for CX20549
ALSA: hda - fix record volume controls of CX20459 ("Venice")
ALSA: hda - Rename capture sources of CX20549 to match common conventions
ALSA: hda - Fix proc output for ADC amp values of CX20549
ASoC: tegra: fix i2s compilation when !CONFIG_DEBUG_FS
ASoC: set idle_bias_off=1 for all platform DAPM contexts
ASoC: imx-audmux: Check for NULL pointer
ASoC: imx-audmux: Fix ssi port numbers in sysfs
ASoC: ak4642: fixup: mute needs +1 step
MAINTAINERS: Don't list everyone working on Wolfson drivers
MAINTAINERS: Add missing ASoC OMAP co-maintainer
ASoC: pxa: pxa2xx-i2s: add io.h for IOMEM macro
ASoC: tegra: ensure clocks are enabled when touching registers
ASoC: sgtl5000: Enable VAG when DAC/ADC up
ALSA: asihpi - fix return value of hpios_locked_mem_alloc()
Pull media fixes from Mauro Carvalho Chehab:
- dvb core: there is a regression found when used with xine. For
whatever unknown reason, xine (and xine-lib clients) wants that the
frontend to tell what frequency he is using even before the PLL lock
(or at least, it expects a non-zero frequency).
On DVB, the frequency is only actually known after a frequency
zig-zag seek, done by the DVB core. Anyway, the fix was trivial.
That solves Fedora BZ#808871.
- ivtv: fix a regression when selecting the language channel
- uvc: fix a race-related crash
- it913x: fixes firmware loading
- two trivial patches (a dependency issue at a radio driver at sound
Kconfig, and a warning fix on dvb).
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] uvcvideo: Fix race-related crash in uvc_video_clock_update()
[media] Drivers/media/radio: Fix build error
[media] dvb_frontend: fix compiler warning
[media] it913x: fix firmware loading errors
[media] ivtv: Fix AUDIO_(BILINGUAL_)CHANNEL_SELECT regression
[media] dvb_frontend: regression fix: userspace ABI broken for xine
Since there are still many Acer models that might not be covered by
the current fixup table, let's add back a few typical model names so
that user can test the fixup without recompiling.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Also remove two warnings when CONFIG_SND_DEBUG is not set:
sound/pci/hda/patch_hdmi.c: In function ‘hdmi_intrinsic_event’:
sound/pci/hda/patch_hdmi.c:761:6: warning: unused variable ‘eldv’ [-Wunused-variable]
sound/pci/hda/patch_hdmi.c:760:6: warning: unused variable ‘pd’ [-Wunused-variable]
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
release_firmware() deals gracefully with NULL pointers, no need to check first.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Sunday, April 01, 2012 21:09:34 Tracey Dent wrote:
> radio-maxiradio depends on SND_FM801_TEA575X_BOOL to build or will
> result in an build error such as:
>
> Kernel: arch/x86/boot/bzImage is ready (#1)
> ERROR: "snd_tea575x_init" [drivers/media/radio/radio-maxiradio.ko] undefined!
> ERROR: "snd_tea575x_exit" [drivers/media/radio/radio-maxiradio.ko] undefined!
> WARNING: modpost: Found 6 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Select CONFIG_SND_TEA575X to fixes problem and enable
> the driver to be built as desired.
>
> v2:
> instead of selecting CONFIG_SND_FM801_TEA575X_BOOL, select
> CONFIG_SND_TEA575X, which in turns selects CONFIG_SND_FM801_TEA575X_BOOL
> and any other dependencies for it to build.
No, this is the correct patch:
RADIO_MAXIRADIO should be treated just like RADIO_SF16FMR2, I just didn't
realize at the time that it had to be added as a SND_TEA575X dependency.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Shea Levy <shea@shealevy.com>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Merge with latest Linus' tree, as I have incoming patches
that fix code that is newer than current HEAD of for-next.
Conflicts:
drivers/net/ethernet/realtek/r8169.c
ASoC: fixes for 3.4
A bunch of driver-specific fixes and one generic fix for the new support
for platform DAPM contexts - we were picking the wrong default for the
idle_bias_off setting which was meaning we weren't actually achieving
any useful runtime PM on platform devices.
