This provide the fix for firmware memory by freeing the pointer in driver
remove where it is safe to do so
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This reverts commit 87b5ed8e ("ASoC: Intel:
Skylake: fix memory leak") as it causes regression on Skylake devices

The SKL drivers can be deferred probe. The topology file based widgets can
have references to topology file so this can't be freed until card is fully
created, so revert this patch for now

[   66.682767] BUG: unable to handle kernel paging request at ffffc900001363fc
[   66.690735] IP: [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.696509] PGD 16e035067 PUD 16e036067 PMD 16e038067 PTE 0
[   66.702925] Oops: 0000 [#1] PREEMPT SMP
[   66.768390] CPU: 3 PID: 57 Comm: kworker/u16:3 Tainted: G O 4.4.0-rc7-skl #62
[   66.778869] Hardware name: Intel Corporation Skylake Client platform
[   66.793201] Workqueue: deferwq deferred_probe_work_func
[   66.799173] task: ffff88008b700f40 ti: ffff88008b704000 task.ti: ffff88008b704000
[   66.807692] RIP: 0010:[<ffffffff806c94dd>]  [<ffffffff806c94dd>] strnlen+0xd/0x40
[   66.816243] RSP: 0018:ffff88008b707878  EFLAGS: 00010286
[   66.822293] RAX: ffffffff80e60a82 RBX: 000000000000000e RCX: fffffffffffffffe
[   66.830406] RDX: ffffc900001363fc RSI: ffffffffffffffff RDI: ffffc900001363fc
[   66.838520] RBP: ffff88008b707878 R08: 000000000000ffff R09: 000000000000ffff
[   66.846649] R10: 0000000000000001 R11: ffffffffa01c6368 R12: ffffc900001363fc
[   66.854765] R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
[   66.862910] FS:  0000000000000000(0000) GS:ffff88016ecc0000(0000) knlGS:0000000000000000
[   66.872150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   66.878696] CR2: ffffc900001363fc CR3: 0000000002c09000 CR4: 00000000003406e0
[   66.886820] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   66.894938] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   66.903052] Stack:
[   66.905346]  ffff88008b7078b0 ffffffff806cb1db 000000000000000e 0000000000000000
[   66.913854]  ffff88008b707928 ffffffffa00d1050 ffffffffa00d104e ffff88008b707918
[   66.922353]  ffffffff806ccbd6 ffff88008b707948 0000000000000046 ffff88008b707940
[   66.930855] Call Trace:
[   66.933646]  [<ffffffff806cb1db>] string.isra.4+0x3b/0xd0
[   66.939793]  [<ffffffff806ccbd6>] vsnprintf+0x116/0x540
[   66.945742]  [<ffffffff806d02f0>] kvasprintf+0x40/0x80
[   66.951591]  [<ffffffff806d0370>] kasprintf+0x40/0x50
[   66.957359]  [<ffffffffa00c085f>] dapm_create_or_share_kcontrol+0x1cf/0x300 [snd_soc_core]
[   66.966771]  [<ffffffff8057dd1e>] ? __kmalloc+0x16e/0x2a0
[   66.972931]  [<ffffffffa00c0dab>] snd_soc_dapm_new_widgets+0x41b/0x4b0 [snd_soc_core]
[   66.981857]  [<ffffffffa00be8c0>] ? snd_soc_dapm_add_routes+0xb0/0xd0 [snd_soc_core]
[   67.007828]  [<ffffffffa00b92ed>] soc_probe_component+0x23d/0x360 [snd_soc_core]
[   67.016244]  [<ffffffff80b14e69>] ? mutex_unlock+0x9/0x10
[   67.022405]  [<ffffffffa00ba02f>] snd_soc_instantiate_card+0x47f/0xd10 [snd_soc_core]
[   67.031329]  [<ffffffff8049eeb2>] ? debug_mutex_init+0x32/0x40
[   67.037973]  [<ffffffffa00baa92>] snd_soc_register_card+0x1d2/0x2b0 [snd_soc_core]
[   67.046619]  [<ffffffffa00c8b54>] devm_snd_soc_register_card+0x44/0x80 [snd_soc_core]
[   67.055539]  [<ffffffffa01c303b>] skylake_audio_probe+0x1b/0x20 [snd_soc_skl_rt286]
[   67.064292]  [<ffffffff808aa887>] platform_drv_probe+0x37/0x90
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add system clock detection to prevent output DC from SPO.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

For a sample rate of 12kHz the bclk was taken from the 44.1kHz table as
we test for a multiple of 8kHz. This patch fixes this issue by testing
for multiples of 4kHz instead.
Signed-off-by: NNikesh Oswal <Nikesh.Oswal@cirrus.com>
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Without this patch, internal speaker and line-out work,
but front headphone output jack stays silent on the
Mac Pro 4,1.

This code path also gets executed on the MacPro 5,1 due
to identical codec SSID, but i don't know if it has any
positive or adverse effects there or not.

(v2) Implement feedback from Takashi Iwai: Reuse
     alc889_fixup_mbp_vref and just add a new nid
     0x19 for the MacPro 4,1.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

After several open/close sai test with ctrl+c, there will be
I/O error. The SAI can't work anymore, can't recover. There
will be no frame clock. With adding the software reset in
trigger stop, the issue can be fixed.

This is a hardware bug/errata and reset is the only option.

According to the reference manual, the software reset doesn't
reset any control register but only internal hardware logics
such as bit clock generator, status flags, and FIFO pointers.
(Our purpose is just to reset the clock generator while the
software reset is the only way to do that.)

Since slave mode doesn't use the clock generator, only apply
the reset procedure to the master mode.

For asynchronous mode, TX will not be reset when RX is still
running. In this case, i can't reproduce this issue.
Signed-off-by: NZidan Wang <zidan.wang@freescale.com>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

It takes three minutes to enter into hibernation on some OEM SKL
machines and we see many codec spurious response after thaw() opertion.
This is because HDA is still in D0 state after freeze() call and
pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
It seems bios still access HDA when system enter into freeze state,
HDA will receive codec response interrupt immediately after thaw() call.
Because of this unexpected interrupt, HDA enter into a abnormal
state and slow down the system enter into hibernation.

In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
put HDA into D0 state in azx_thaw_noirq().

V2: Only apply this fix to SKL+
    Fix compile error when CONFIG_PM_SLEEP isn't defined

[Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment
 by tiwai]
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When power up, a "pop" is heard on line-in and mic-in.
An analysis of the PCM shows it lasts ~400ms
and looks like a filter response.
VAG power up should be delayed by 400ms as VAG power down is.
Signed-off-by: NJean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Apply the same fixup for Thinkpad with dock to Thinkpad X1 Carbon 2nd,
too.  This reduces the annoying loud cracking noise problem, as well
as the support of missing docking port.

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439Reported-and-tested-by: NBenjamin Poirier <bpoirier@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Lenovo Thinkpads with Realtek codecs may still have some loud
crackling noises at reboot/shutdown even though a few previous fixes
have been applied.  It's because the previous fix (disabling the
default shutup callback) takes effect only at transition of the codec
power state.  Meanwhile, at reboot or shutdown, we don't take down the
codec power as default, thus it triggers the same problem unless the
codec is powered down casually by runtime PM.

This patch tries to address the issue.  It gives two things:
- implement the separate reboot_notify hook to struct alc_spec, and
  call it optionally if defined.
- turn off the codec to D3 for Thinkpad models via this new callback

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439Reported-and-tested-by: NBenjamin Poirier <bpoirier@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It seems that a workaround for Thinkpad T440s crackling noise can be
applied generically to all Thinkpad models: namely, disabling the
default alc269 shutup callback.  This patch moves it to the existing
alc_fixup_tpt440_dock() while also replacing the rest code with
another existing alc_fixup_disable_aamix().  It resulted in a good
code reduction.

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439Reported-and-tested-by: NBenjamin Poirier <bpoirier@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

These laptops support both headphone, headset and mic modes
for the 3.5mm jack.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1526330Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
and causes noisy "cannot get freq at ep 0x1" messages when playback
starts.
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AudioQuest DragonFly DAC reports a volume control range of 0..50
(0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
is obviously incorrect and would cause software using the dB information
in e.g. volume sliders to have a massive volume difference in 100..102%
range.

Commit 2d1cb7f6 ("ALSA: usb-audio: add dB range mapping for some
devices") added a dB range mapping for it with range 0..50 dB.

However, the actual volume mapping seems to be neither linear volume nor
linear dB scale, but instead quite close to the cubic mapping e.g.
alsamixer uses, with a range of approx. -53...0 dB.

Replace the previous quirk with a custom dB mapping based on some basic
output measurements, using a 10-item range TLV (which will still fit in
alsa-lib MAX_TLV_RANGE_SIZE).

Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
range is 0..50, so if this gets fixed/changed in later HW revisions it
will no longer be applied.

v2: incorporated Takashi Iwai's suggestion for the quirk application
method
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Explicitly set the transmit data level on the transceiver to 16 samples
rather then the default 0. This matches both the level set in the vendor
kernel and the (seemingly very similar) i2s engine. This fixes audio
glitches when playing back at 192k rate.

At the same time, fix a trivial typo in the TDL mask definition
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NMark Brown <broonie@kernel.org>

Attempting to use this codec driver triggers a BUG() in regcache_sync()
since no cache type is set.  The register map of this device is fairly
small and has few holes so a flat cache is suitable.
Signed-off-by: NMans Rullgard <mans@mansr.com>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

These are all off by one; the playback and bypass switches are the top
two bits of the registers, which are at shifts 7 and 6 not 8 and 7.
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The condition for checking for XDAT being cleared was not correct.

Fixes: 36bcecd0 ("ASoC: davinci-mcasp: Correct TX start sequence")
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

This is using completely the wrong mask and value when updating the
register.  Since the correct values are already defined in the header,
switch to using a table with explicit constants rather than shifting the
array index.
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The Alienware 17 (2015) has the same card and pin configuration of the
Alienware 15, so the same quirks must be applied.
Signed-off-by: NGabriele Martino <g.martino@gmx.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Lenovo Thinkpad T440s suffers from constant background noises, and it
seems to be a generic hardware issue on this model:
  https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T440s-speaker-noise/td-p/1339883

As the noise comes from the analog loopback path, disabling the path
is the easy workaround.

Also, the machine gives significant cracking noises at PM suspend.  A
workaround found by trial-and-error is to disable the shutup callback
currently used for ALC269-variant.

This patch addresses these noise issues by introducing a new fixup
chain.  Although the same workaround might be applicable to other
Thinkpad models, it's applied only to T440s (17aa:220c) in this patch,
so far, just to be safe (you chicken!).  As a compromise, a new model
option string "tp440" is provided now, though, so that owners of other
Thinkpad models can test it more easily.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=958504Reported-and-tested-by: NTim Hardeck <thardeck@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have two latest thinkpad laptop models which are all based on the
Intel skylake platforms, and all of them have the codec alc293 on
them. When the machines boot to the desktop, an greeting dialogue
shows up with the notification sound. But on these two models, there
is noise with the notification sound. We have 3 SKUs for each of
the models, all of them have this problem.

So far, this problem is only specific to these two thinkpad models,
we did not find this problem on the old thinkpad models with the
codec alc293 or alc292.

A workaround for this problem is disabling the aamix.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1523517Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On the internal mic of the Packard Bell DOTS, one channel
has an inverted signal. Add a quirk to fix this up.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1523232Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In BXT-P A0, HD-Audio DMA requests is later than expected,
and makes an audio stream sensitive to system latencies when
24/32 bits are playing.
Adjusting threshold of DMA fifo to force the DMA request
sooner to improve latency tolerance at the expense of power.

v2: move Intel specific code to hda_intel.c
Signed-off-by: NLu, Han <han.lu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

rme96 driver needs to reset DAC depending on the sample rate, and this
results in resetting to the max volume suddenly.  It's because of the
missing call of snd_rme96_apply_dac_volume().

However, calling this function right after the DAC reset still may not
work, and we need some delay before this call.  Since the DAC reset
and the procedure after that are performed in the spinlock, we delay
the DAC volume restore at the end after the spinlock.
Reported-and-tested-by: NSylvain LABOISNE <maeda1@free.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It's supposed to be equivalent with CX20724.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The numbers aren't always linear, just like in the real world.
Correct to the right numbers stated in the datasheet (although we
can't trust the datasheet as well).
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent addition of ELD notifier for Intel HDMI/DP codec may lead
the bad codec connection found as kernel messages like below:
 Suspending console(s) (use no_console_suspend to debug)
 hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
 snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
 snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
 ....
  snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
  snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
 azx_single_wait_for_response: 42 callbacks suppressed

This seems appearing when the sound driver went to suspend before i915
driver.  Then i915 driver disables HDMI/DP audio bit and calls the
registered notifier, and the HDA codec tries to handle it as a
hot(un)plug.  But since the driver is already in the suspended state,
it fails miserably.

As this is a sort of spurious wakeup, it can be ignored safely, as
long as it's delivered during the system suspend.  OTOH, if a
notification comes during the runtime suspend, the situation is
different: we need to wake up.  But during the system suspend, such a
notification can't be the reason for a wakeup.

This patch addresses it by a simple check of the current sound card
status.  The skipped notification doesn't matter because the HDA
driver will check the plugged status forcibly at the resume in
return.

Then, why the card status, not a runtime PM status or else?  The HDA
controller driver is supposed to set the card status to D3 at the
system suspend but not at the runtime suspend.  So we can see it as a
flag that is set only for the system suspend.  Admittedly, it's a bit
ugly, but it should work well for now.
Reported-and-tested-by: N"Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Fixes: 25adc137 ('ALSA: hda - Wake the codec up on pin/ELD notify events')
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For DAPM resume, we should first change the power state of the
card and then recheck the endpoints. This ensures the dapm is
resumed first and then userspace can resume the streams.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix kernel-doc warnings in soc-ops.c:

..//sound/soc/soc-ops.c:415: warning: No description found for parameter 'ucontrol'
..//sound/soc/soc-ops.c:415: warning: Excess function parameter 'uinfo' description in 'snd_soc_put_volsw_sx'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc:	Liam Girdwood <lgirdwood@gmail.com>
Cc:	Mark Brown <broonie@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add platform specific data for Terra project.
Signed-off-by: NLuke_Yin@asus.com <Luke_Yin@asus.com>
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Correct valid data word register value for 24 bit data width. The
bit value should be 10 (aka 0x2), not 0x10.

This fixes playback of 24 bit audio.
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

A new randconfig build failure shows that the fsl-asoc-card module
must not be built-in when the AC97 driver is a loadable module:

sound/built-in.o: In function `fsl_asoc_card_late_probe':
:(.text+0x571d8): undefined reference to `snd_ac97_update_bits'

I couldn't come up with a nice solution, so this adds another dependency
on "X || !X", which is the Kconfig way of saying that we have an
optional dependency on something that might be a loadable module.

Fixes: 50760cad ("ASoC: fsl-asoc-card: add AC'97 support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Gigabyte Z710X mobo with ALC1150 codec gets significant noises from
the analog loopback routes even if their inputs are all muted.
Simply kill the aamix for fixing it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have a machine Dell XPS 13 with the codec alc256, after resume back
from S3, the headphone has noise when play sound.

Through comparing with the coeff vaule before and after S3, we found
restoring a coeff register will help remove noise.

BugLink: https://bugs.launchpad.net/bugs/1519168
Cc: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have requested the firmware but missed releasing it.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

When McASP is used as TX/RX synchronous (TX side generating clocks for RX
side also) and only capture is used we need to configure the number of TX
slots in order McASP to be able to generate the Frame sync.

Fixes: 9273de1940d9e ("ASoC: davinci-mcasp: Add set_tdm_slots() support")
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

It turned out that many HP laptops suffer from the same problem as
fixed in commit [c932b98c: ALSA: hda - Apply pin fixup for HP
ProBook 6550b].  But, it's tiresome to list up all such PCI SSIDs, as
there are really lots of HP machines.

Instead, we do a bit more clever, try to check the supposedly dock and
built-in headphone pins, and apply the fixup when both seem valid.
This rule can be applied generically to all models using the same
quirk, so we'll fix all in a shot.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107491
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

These are all off by one; the playback and bypass switches are the top
two bits of the registers, which are at shifts 7 and 6 not 8 and 7.
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add platform specific data for Wizpig project.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>