Add a new quirk ID for the Recon3D, as tested by me.
Signed-off-by: NConnor McAdams <conmanx360@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200803002928.8638-2-conmanx360@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

When the ZxR headphone gain control was added, the ca0132_switch_get
function was not updated, which meant that the changes to the control
state were not saved when entering/exiting alsamixer.
Signed-off-by: NConnor McAdams <conmanx360@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200803002928.8638-1-conmanx360@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

There are several Loongson-3 based laptops produced by CZC or Lemote,
they use alc269/alc662 codecs and need specific pin-tables, this patch
add their pin-tables.
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1596360400-32425-1-git-send-email-chenhc@lemote.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

HP NB right speaker had no sound output.
This platform was connected to I2S Amp for speaker out.(None Realtek I2S Amp IC)
EC need to check codec GPIO1 pin to initial I2S Amp.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/01285f623ac7447187482fb4a8ecaa7c@realtek.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

When the ASoC card registration fails and the codec component driver
never probes, the codec device is not initialized and therefore
memory for codec->wcaps is not allocated. This results in a NULL pointer
dereference when the codec driver suspend callback is invoked during
system suspend. Fix this by returning without performing any actions
during codec suspend/resume if the card was not registered successfully.
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200728231011.1454066-1-ranjani.sridharan@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

It's been reported that, when neither nouveau nor Nvidia graphics
driver is used, the screen starts flickering.  And, after comparing
between the working case (stable 4.4.x) and the broken case, it turned
out that the problem comes from the audio component binding.  The
Nvidia and AMD audio binding code clears the bus->keep_power flag
whenever snd_hdac_acomp_init() succeeds.  But this doesn't mean that
the component is actually bound, but it merely indicates that it's
ready for binding.  So, when both nouveau and Nvidia are blacklisted
or not ready, the driver keeps running without the audio component but
also with bus->keep_power = false.  This made the driver runtime PM
kicked in and powering down when unused, which results in flickering
in the graphics side, as it seems.

For fixing the bug, this patch moves the bus->keep_power flag change
into generic_acomp_notifier_set() that is the function called from the
master_bind callback of component ops; i.e. it's guaranteed that the
binding succeeded.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208609
Fixes: 5a858e79 ("ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728082033.23933-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

We've received a regression report on Intel HD-audio controller that
wakes up immediately after S3 suspend.  The bisection leads to the
commit c4c8dd6e ("ALSA: hda: Skip controller resume if not
needed").  This commit replaces the system-suspend to use
pm_runtime_force_suspend() instead of the direct call of
__azx_runtime_suspend().  However, by some really mysterious reason,
pm_runtime_force_suspend() causes a spurious wakeup (although it calls
the same __azx_runtime_suspend() internally).

As an ugly workaround for now, revert the behavior to call
__azx_runtime_suspend() and __azx_runtime_resume() for those old Intel
platforms that may exhibit such a problem, while keeping the new
standard pm_runtime_force_suspend() and pm_runtime_force_resume()
pair for the remaining chips.

Fixes: c4c8dd6e ("ALSA: hda: Skip controller resume if not needed")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208649
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200727164443.4233-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Intel requires to enable power saving mode for intel reference board (alc256)
Signed-off-by: NPeiSen Hou <pshou@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200727115647.10967-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This patch fixes a small typo I accidently submitted with the initial patch. The board should be named GA401 not G401.

Fixes: ff53664d ("ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G14(G401) series with ALC289")
Signed-off-by: NArmas Spann <zappel@retarded.farm>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200724140837.302763-1-zappel@retarded.farmSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds support for headset mic to the ASUS ROG Zephyrus
G15(GA502) notebook series by adding the corresponding
vendor/pci_device id, as well as adding a new fixup for the used
realtek ALC289. The fixup stets the correct pin to get the headset mic
correctly recognized on audio-jack.
Signed-off-by: NArmas Spann <zappel@retarded.farm>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200724140616.298892-1-zappel@retarded.farmSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
word "slave" in vmaster API.  I chose the word "follower" at this time
since it seems fitting for the purpose.

Note that the word "master" is kept in API, since it refers rather to
audio master volume control.

Also, while we're at it, a typo in comments is corrected, too.

Link: https://lore.kernel.org/r/20200717154517.27599-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Delete the doubled word "of" in a comment.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20200719180848.22572-1-rdunlap@infradead.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Fixed no headphone sound bug on laptop Samsung Notebook Pen S
(950SBE-951SBE), by using existing patch in Linus' tree, commit
14425f1f (ALSA: hda/realtek: Add quirk for Samsung Notebook).
This laptop uses the same ALC298 but different subsystem id 0x144dc812.
I added SND_PCI_QUIRK at sound/pci/hda/patch_realtek.c
Signed-off-by: NJoonho Wohn <doomsheart@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAHcbMh291aWDKiWSZoxXB4-Eru6OYRwGA4AVEdCZeYmVLo5ZxQ@mail.gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Add the new PCI ID 0x0014 0x7a07 to support Loongson 7A1000 controller.
Signed-off-by: NKaige Li <likaige@loongson.cn>
Link: https://lore.kernel.org/r/1594954292-1703-2-git-send-email-likaige@loongson.cnSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Add headset_jack for the intel reference board support with
10ec:1230.
Signed-off-by: NPeiSen Hou <pshou@realtek.com.tw>
Link: https://lore.kernel.org/r/20200716090134.9811-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS UX563 speaker can't output.
Add quirk to link suitable model will enable it.
This model also could enable headset Mic.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/96dee3ab01a04c28a7b44061e88009dd@realtek.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS UX533 and UX534 speaker still can't output.
End User feedback speaker didn't have output.
Add this COEF value will enable it.

Fixes: 4e051106 ("ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294")
Cc: <stable@vger.kernel.org>
Signed-off-by: NKailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/r/80334402a93b48e385f8f4841b59ae09@realtek.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" appropriately.

Only comment or variable renames, no functional changes.

Link: https://lore.kernel.org/r/20200714172631.25371-10-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.

Only comment or enum/variable renames, no functional changes.

Link: https://lore.kernel.org/r/20200714172631.25371-9-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.

Correcting only comments, or error/module messages, no functional
changes.

Link: https://lore.kernel.org/r/20200714172631.25371-8-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.

Only comment or variable renames, no functional changes.

Note that pm_blacklist module option is still kept as was, so that
users can still keep the old option.

Link: https://lore.kernel.org/r/20200714172631.25371-7-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.

Only comment or variable renames, no functional changes.

Link: https://lore.kernel.org/r/20200714172631.25371-6-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
word "blacklist" appropriately.

Only correcting the error message, no functional changes.

Link: https://lore.kernel.org/r/20200714172631.25371-5-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.

Only comment or variable renames, no functional changes.

Link: https://lore.kernel.org/r/20200714172631.25371-4-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.

Only comment or function/variable renames, no functional changes.

Link: https://lore.kernel.org/r/20200714172631.25371-3-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Commit f34a4c9d ("ALSA: hda: Enable sync-write operation as default
for all controllers") enabled sync-write for all controllers and this is
causing audio playback on the Tegra186 HDA device to fail. For now,
disable sync-write support for Tegra to fix this.

Fixes: f34a4c9d ("ALSA: hda: Enable sync-write operation as default for all controllers")
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20200714160841.2293-1-jonathanh@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This should be spin_unlock_irq() instead of spin_lock().

Fixes: 6c331254 ("ALSA: echoaudio: Prevent races in calls to set_audio_format()")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200713105324.GB251988@mwandaSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The Acer TravelMate B311R-31 laptop's audio (1025:1430) with ALC256
cannot detect the headset microphone until
ALC256_FIXUP_ACER_MIC_NO_PRESENCE quirk maps the NID 0x19 as the headset
mic pin.
Signed-off-by: NJian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200713060421.62435-1-jian-hong@endlessm.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds support for headset mic to the ASUS ROG Zephyrus
G14(GA401) notebook series by adding the corresponding
vendor/pci_device id, as well as adding a new fixup for the used
realtek ALC289. The fixup stets the correct pin to get the headset mic
correctly recognized on audio-jack.
Signed-off-by: NArmas Spann <zappel@retarded.farm>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200711110557.18681-1-zappel@retarded.farmSigned-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS platform couldn't need to use Headset Mode model.
It changes to the suitable model.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/d05bcff170784ec7bb35023407148161@realtek.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

A few places (except for ASoC) are left unconverted for the new
fallthrough pseudo keyword.  Now replace them all.
Reviewed-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200709111750.8337-4-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200708203236.GA5112@embeddedorSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Distorted audio appears occasionally, affecting either playback or
capture and requiring the affected substream to be closed by all
applications and re-opened.

The best way I have found to reproduce the bug is to use dmix in
combination with Chromium, which opens the audio device multiple times
in threads. Anecdotally, the problems appear to have increased with
faster CPUs. I ruled out 32-bit counter wrapping; it often happens
much earlier.

Since applying this patch I have not had problems, where previously
they would occur several times a day.

The patch targets the following issues:

* Check for progress using the counter from the hardware, not after it
  has been truncated to the buffer.

  This is a clean way to address a possible bug where if a whole
  ringbuffer advances between interrupts, it goes unnoticed.

* Move last_period state from chip to pipe

  This more logically belongs as part of pipe, and code is reasier to
  read if it is "counter position last time a period elapsed".

  Now the code has no references to period count. A period is just
  when the regular counter crosses a threshold. This increases
  readability and reduces scope for bugs.

* Treat period notification and buffer advance independently:

  This helps to clarify what is the responsibility of the interrupt
  handler, and what is pcm_pointer().

  Removing shared state between these operations means race conditions
  are fixed without introducing locks. Synchronisation is only around
  the read of pipe->dma_counter. There may be cache line contention
  around "struct audiopipe" but I did not have cause to profile this.

Pay attention to be robust where dma_counter wrapping is not a
multiple of period_size or buffer_size.

This is a revised patch based on feedback from Takashi and Giuliano.
Signed-off-by: NMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-5-mark@xwax.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

These are valid conditions in normal circumstances, so do not "warn" but
make them for debugging.
Signed-off-by: NMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-4-mark@xwax.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

The function uses chip->comm_page which needs locking against
other use at the same time.
Signed-off-by: NMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-3-mark@xwax.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Use of atomics does not make these statements robust:

       atomic_inc(&chip->opencount);
       if (atomic_read(&chip->opencount) > 1 && chip->rate_set)
               chip->can_set_rate=0;

and

       if (atomic_read(&chip->opencount)) {
               if (chip->opencount) {
                       changed = -EAGAIN;
               } else {
                       changed = set_digital_mode(chip, dmode);

It would be necessary to atomically increment or decrement the value
and use the returned result. And yet we still need to prevent other
threads making use of "can_set_rate" while we set it.

However in all but one case the atomic is misleading as they are already
running with "mode_mutex" held.

Decisions are made on mode setting are often intrinsically connected
to "opencount" because some operations are not permitted unless
there is sole ownership.

So instead simplify this, and use "mode_mutex" as a lock for all reference
counting and mode setting.
Signed-off-by: NMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-2-mark@xwax.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

This check is always false, as it's not the responsibilty of the
device-specific code to make this check. It is already checked
in snd_echo_digital_mode_put.

I do not have a Mona interface to test this change.

This patch is in preparation for follow-up patch to modify the
behavior of "opencount".
Signed-off-by: NMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-1-mark@xwax.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de>

External HDMI receivers have analog circuitry that needs to be powered-on
when exiting standby, and a mechanism to detect PCM v. IEC61937 data.
These two steps take time and up to 2-3 seconds of audio may be muted
when starting playback.

Intel hardware (Haswell and beyond) can keep the link active
with a 'silent stream', so that the receiver does not go through those
two steps when valid audio is transmitted. This mechanism relies
on an setting the channel_id as 0xf, sending info packet and preventing
the codec from going to D3,  which will increase the platform
static power consumption. The info packet assumes a basic 2ch stereo,
and the silent stream is enabled when connecting a monitor.
In case of format changes the detection of PCM v. IEC61937 needs to
be re-run. In this case there is no way to avoid the 2-3s mute.

The silent stream is enabled with a Kconfig option, as well as a kernel
parameter should there be a need to override the build time default.
This approach is used based on the power_save capability as an example,
but in the future, it may be used with a kcontrol,
depending on UCM support for HDaudio legacy.
Signed-off-by: NHarsha Priya <harshapriya.n@intel.com>
Signed-off-by: NEmmanuel Jillela <emmanuel.jillela@intel.com>
Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/1594068797-14011-1-git-send-email-harshapriya.n@intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Fix W=1 warnings. Mark all unused tables with __maybe_unused.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200702193604.169059-24-pierre-louis.bossart@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Fix W=1 warnings. Mark variables as __always_unused.

sound/pci/via82xx.c: In function ‘snd_via82xx_codec_wait’:
sound/pci/via82xx.c:547:6: warning: variable ‘err’ set but not used
[-Wunused-but-set-variable]
  547 |  int err;
      |      ^~~
sound/pci/via82xx_modem.c: In function ‘snd_via82xx_codec_wait’:
sound/pci/via82xx_modem.c:401:6: warning: variable ‘err’ set but not
used [-Wunused-but-set-variable]
  401 |  int err;
      |      ^~~
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200702193604.169059-21-pierre-louis.bossart@linux.intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>