Skip to content

L
linux
Switch branch/tag
  1. 07 Jul, 2020 21 commits
  3. 30 Jun, 2020 1 commit
  5. 25 Jun, 2020 1 commit
  7. 19 Jun, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'topic/hda-micmute-led' into for-next · c7440acc
      Takashi Iwai authored 
      This is a patch set inspired by the recent patch Kai-Heng posted about
the HD-audio mic-mute LED control.  Currently HD-audio driver deals
with the mute and mic-mute LED in several different ways: primarily
with the direct callback of vmaster hook and capture sync hook, while
another with the LED class device binding.  The latter has been used
for binding with the platform device LEDs like Thinkpad, Dell,
Huawei.  And, yet, recently we added our own LED classdev for the
mic-mute LED on some HP systems although they are controlled directly
with the callback; it's exposed, however, for the DMIC that is
governed by a different ASoC driver.

This patch set is an attempt to sort out and make them consistent:
namely,
* All LEDs are now controlled via LED class device
* The generic driver provides helper functions to easily build up the
  LED class dev and the relevant mixer controls
* Conversion of the existing framework and clean ups

The patches are lightly tested in my side with a couple of machines
and also through hda-emu tests.  Some devices receive new kcontrols
for the mute LED behavior (that have been missing so far), but
anything else look good though my tests.

Link: https://lore.kernel.org/r/20200618110842.27238-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c7440acc
    • Takashi Iwai's avatar
      ALSA: hda: Enable sync-write operation as default for all controllers · f34a4c9d
      Takashi Iwai authored 
      In the end we already enabled the sync-write mode for most of HD-audio
controllers including Intel, and it's no big merit to keep the async
write mode for the rest.  Let's make it as default and drop the
superfluous AZX_DCAPS_SYNC_WRITE bit flag.

Also, avoid to set the allow_bus_reset flag, which is a quite unstable
and hackish behavior that was needed only for some early platforms
(decades ago).  The straight fallback to the single cmd mode is more
robust.

Link: https://lore.kernel.org/r/20200618144051.7415-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f34a4c9d
  9. 18 Jun, 2020 13 commits
  11. 17 Jun, 2020 1 commit
  13. 15 Jun, 2020 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Use SG-buffer only when direct DMA is available · 3ad796cb
      Takashi Iwai authored 
      The DMA-coherent SG-buffer is tricky to use, as it does need the
mapping.  It used to work stably on x86 over years (and that's why we
had enabled SG-buffer on solely x86) with the default mmap handler and
vmap(), but our luck seems no forever success.  The chance of breakage
is high when the special DMA handling is introduced in the arch side.

In this patch, we change the buffer allocation to use the SG-buffer
only when the device in question is with the direct DMA.  It's a bit
hackish, but it's currently the only condition that may work (more or
less) reliably with the default mmap and vmap() for mapping the pages
that are deduced via virt_to_page().

In theory, we can apply the similar hack in the sound/core memory
allocation helper, too; but it's used by SOF for allocating SG pages
without re-mapping via vmap() or mmap, and it's fine to use it in that
way, so let's keep it and adds the workaround in PCM side.

Link: https://lore.kernel.org/r/20200615160045.2703-5-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3ad796cb
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7