Skip to content
  1. Sep 20, 2019
  3. Sep 16, 2019
  5. Sep 06, 2019
    • Sergey Bostandzhyan's avatar
      Add Acer Aspire Ethos 8951G model quirk · 00066e97
      Sergey Bostandzhyan authored 
      

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: default avatarSergey Bostandzhyan <jin@mediatomb.cc>
Link: https://lore.kernel.org/r/20190906093343.GA7640@xn--80adja5bqm.su


Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      00066e97
  7. Sep 05, 2019
  9. Sep 04, 2019
  11. Sep 03, 2019
  13. Sep 02, 2019
  15. Aug 30, 2019
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Fix overridden device-specific initialization · 89781d08
      Takashi Iwai authored 
      The recent change to shuffle the codec initialization procedure for
Realtek via commit 607ca3bd ("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: 607ca3bd ("ALSA: hda/realtek - EAPD turn on later")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      89781d08
  17. Aug 29, 2019
  19. Aug 27, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Allow runtime PM for controller if component notifier is used · dd23e1d5
      Takashi Iwai authored 
      

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 37a3a98e ("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 ade49db3 ("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: default avatarTakashi Iwai <tiwai@suse.de>
      dd23e1d5
  21. Aug 22, 2019
  23. Aug 20, 2019
  25. Aug 19, 2019
  27. Aug 16, 2019
  29. Aug 14, 2019
  31. Aug 13, 2019
  33. Aug 12, 2019
    • Takashi Iwai's avatar
      ALSA: hda: Set fifo_size for both playback and capture streams · 7da20788
      Takashi Iwai authored 
      

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: default avatarTakashi Iwai <tiwai@suse.de>
      7da20788
  35. Aug 10, 2019
    • Wenwen Wang's avatar
      ALSA: hda - Fix a memory leak bug · cfef67f0
      Wenwen Wang authored 
      

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: 352f7f91 ("ALSA: hda - Merge Realtek parser code to generic parser")
Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cfef67f0
  37. Aug 09, 2019
  39. Aug 08, 2019
    • Takashi Iwai's avatar
      ALSA: hda: Direct MMIO accesses · 19abfefd
      Takashi Iwai authored 
      

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: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      19abfefd
    • Takashi Iwai's avatar
      ALSA: hda: Remove page allocation redirection · 619a1f19
      Takashi Iwai authored 
      

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: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      619a1f19
  41. Aug 07, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457) · c02f77d3
      Takashi Iwai authored 
      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: default avatarTakashi Iwai <tiwai@suse.de>
      c02f77d3
  43. Aug 06, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Don't override global PCM hw info flag · c1c6c877
      Takashi Iwai authored 
      

The commit bfcba288 ("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: bfcba288 ("ALSA - hda: Add support for link audio time reporting")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c1c6c877
  45. Aug 02, 2019
  47. Jul 31, 2019
    • Pierre-Louis Bossart's avatar
      ALSA: hda/intel: stop probe if DMICS are detected on Skylake+ platforms · 8c575883
      Pierre-Louis Bossart authored 
      

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: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8c575883
  49. Jul 26, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Show the fatal CORB/RIRB error more clearly · dd65f7e1
      Takashi Iwai authored 
      

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: default avatarTakashi Iwai <tiwai@suse.de>
      dd65f7e1
  51. Jul 25, 2019
  53. Jul 24, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips · 2756d914
      Takashi Iwai authored 
      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: default avatarTodd Brandt <todd.e.brandt@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2756d914
  55. Jul 22, 2019
    • Ranjani Sridharan's avatar
      ASoC: SOF: Intel: hda: Make hdac_device device-managed · ef9bec27
      Ranjani Sridharan authored 
      

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: default avatarLibin Yang <libin.yang@intel.com>
Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190626070450.7229-1-ranjani.sridharan@linux.intel.com


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      ef9bec27
    • Chris Wilson's avatar
      ALSA: hda: Flush interrupts on disabling · caa8422d
      Chris Wilson authored 
      I was looking at

<4> [241.835158] general protection fault: 0000 [#1] PREEMPT SMP PTI
<4> [241.835181] CPU: 1 PID: 214 Comm: kworker/1:3 Tainted: G     U            5.2.0-CI-CI_DRM_6509+ #1
<4> [241.835199] Hardware name: Dell Inc.                 OptiPlex 745                 /0GW726, BIOS 2.3.1  05/21/2007
<4> [241.835234] Workqueue: events snd_hdac_bus_process_unsol_events [snd_hda_core]
<4> [241.835256] RIP: 0010:input_handle_event+0x16d/0x5e0
<4> [241.835270] Code: 48 8b 93 58 01 00 00 8b 52 08 89 50 04 8b 83 f8 06 00 00 48 8b 93 00 07 00 00 8d 70 01 48 8d 04 c2 83 e1 08 89 b3 f8 06 00 00 <66> 89 28 66 44 89 60 02 44 89 68 04 8b 93 f8 06 00 00 0f 84 fd fe
<4> [241.835304] RSP: 0018:ffffc9000019fda0 EFLAGS: 00010046
<4> [241.835317] RAX: 6b6b6b6ec6c6c6c3 RBX: ffff8880290fefc8 RCX: 0000000000000000
<4> [241.835332] RDX: 000000006b6b6b6b RSI: 000000006b6b6b6c RDI: 0000000000000046
<4> [241.835347] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000001
<4> [241.835362] R10: ffffc9000019faa0 R11: 0000000000000000 R12: 0000000000000004
<4> [241.835377] R13: 0000000000000000 R14: ffff8880290ff1d0 R15: 0000000000000293
<4> [241.835392] FS:  0000000000000000(0000) GS:ffff88803de80000(0000) knlGS:0000000000000000
<4> [241.835409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [241.835422] CR2: 00007ffe9a99e9b7 CR3: 000000002f588000 CR4: 00000000000006e0
<4> [241.835436] Call Trace:
<4> [241.835449]  input_event+0x45/0x70
<4> [241.835464]  snd_jack_report+0xdc/0x100
<4> [241.835490]  snd_hda_jack_report_sync+0x83/0xc0 [snd_hda_codec]
<4> [241.835512]  snd_hdac_bus_process_unsol_events+0x5a/0x70 [snd_hda_core]
<4> [241.835530]  process_one_work+0x245/0x610

which has the hallmarks of a worker queued from interrupt after it was
supposedly cancelled (note the POISON_FREE), and I could not see where
the interrupt would be flushed on shutdown so added the likely suspects.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111174


Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      caa8422d
    • Takashi Iwai's avatar
      ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI · ade49db3
      Takashi Iwai authored 
      

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: default avatarTakashi Iwai <tiwai@suse.de>
      ade49db3