1. 12 Apr, 2020 4 commits
  2. 11 Apr, 2020 1 commit
  3. 09 Apr, 2020 1 commit
  4. 08 Apr, 2020 4 commits
  5. 07 Apr, 2020 5 commits
  6. 06 Apr, 2020 3 commits
  7. 04 Apr, 2020 1 commit
  8. 03 Apr, 2020 8 commits
  9. 02 Apr, 2020 2 commits
  10. 01 Apr, 2020 3 commits
  11. 31 Mar, 2020 7 commits
    • 이경택's avatar
      ASoC: dapm: connect virtual mux with default value · 3bbbb772
      이경택 authored
      Since a virtual mixer has no backing registers
      to decide which path to connect,
      it will try to match with initial state.
      This is to ensure that the default mixer choice will be
      correctly powered up during initialization.
      Invert flag is used to select initial state of the virtual switch.
      Since actual hardware can't be disconnected by virtual switch,
      connected is better choice as initial state in many cases.
      Signed-off-by: default avatarGyeongtaek Lee <gt82.lee@samsung.com>
      Link: https://lore.kernel.org/r/01a301d60731$b724ea10$256ebe30$@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      3bbbb772
    • Stephan Gerhold's avatar
      ASoC: qcom: q6asm-dai: Add SNDRV_PCM_INFO_BATCH flag · 7f2430cd
      Stephan Gerhold authored
      At the moment, playing audio with PulseAudio with the qdsp6 driver
      results in distorted sound. It seems like its timer-based scheduling
      does not work properly with qdsp6 since setting tsched=0 in
      the PulseAudio configuration avoids the issue.
      
      Apparently this happens when the pointer() callback is not accurate
      enough. There is a SNDRV_PCM_INFO_BATCH flag that can be used to stop
      PulseAudio from using timer-based scheduling by default.
      
      According to https://www.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html:
      
          The flag is being used in the sense explained in the previous audio
          meeting -- the data transfer granularity isn't fine enough but aligned
          to the period size (or less).
      
      q6asm-dai reports the position as multiple of
      
          prtd->pcm_count = snd_pcm_lib_period_bytes(substream)
      
      so it indeed just a multiple of the period size.
      
      Therefore adding the flag here seems appropriate and makes audio
      work out of the box.
      
      Fixes: 2a9e92d3 ("ASoC: qdsp6: q6asm: Add q6asm dai driver")
      Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
      Reviewed-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Link: https://lore.kernel.org/r/20200330175210.47518-1-stephan@gerhold.netSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      7f2430cd
    • Andreas Steinmetz's avatar
      ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor · 5c6cd702
      Andreas Steinmetz authored
      The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra
      endpoint descriptor.
      
      The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00
      
      As the code in snd_usbmidi_get_ms_info() looks only at the
      first extra descriptor to find USB_DT_CS_ENDPOINT the device
      as such is recognized but there is neither input nor output
      configured.
      
      The patch iterates through the extra descriptors to find the
      proper one. With this patch the device is correctly configured.
      Signed-off-by: default avatarAndreas Steinmetz <ast@domdv.de>
      Link: https://lore.kernel.org/r/1c3b431a86f69e1d60745b6110cdb93c299f120b.camel@domdv.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5c6cd702
    • Takashi Iwai's avatar
      Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h" · b6f69c79
      Takashi Iwai authored
      This reverts commit 645c08f1
      which was reported to break the build a program using this header.
      
      The original issue was addressed in the alsa-lib side recently, so we
      can make the header more self-contained again.
      Reported-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Fixes: 645c08f1 ("ALSA: uapi: Drop asound.h inclusion from asoc.h")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200331090023.8112-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b6f69c79
    • Thomas Hebb's avatar
      ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixups · f36938aa
      Thomas Hebb authored
      patch_realtek.c has historically failed to properly configure the PC
      Beep Hidden Register for the ALC256 codec (among others). Depending on
      your kernel version, symptoms of this misconfiguration can range from
      chassis noise, picked up by a poorly-shielded PCBEEP trace, getting
      amplified and played on your internal speaker and/or headphones to loud
      feedback, which responds to the "Headphone Mic Boost" ALSA control,
      getting played through your headphones. For details of the problem, see
      the patch in this series titled "ALSA: hda/realtek - Set principled PC
      Beep configuration for ALC256", which fixes the configuration.
      
      These symptoms have been most noticed on the Dell XPS 13 9350 and 9360,
      popular laptops that use the ALC256. As a result, several model-specific
      fixups have been introduced to try and fix the problem, the most
      egregious of which locks the "Headphone Mic Boost" control as a hack to
      minimize noise from a feedback loop that shouldn't have been there in
      the first place.
      
      Now that the underlying issue has been fixed, remove all these fixups.
      Remaining fixups needed by the XPS 13 are all picked up by existing pin
      quirks.
      
      This change should, for the XPS 13 9350/9360
      
       - Significantly increase volume and audio quality on headphones
       - Eliminate headphone popping on suspend/resume
       - Allow "Headphone Mic Boost" to be set again, making the headphone
         jack fully usable as a microphone jack too.
      
      Fixes: 8c69729b ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3")
      Fixes: 423cd785 ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360")
      Fixes: e4c9fd10 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant")
      Fixes: 1099f484 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Hebb <tommyhebb@gmail.com>
      Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f36938aa
    • Thomas Hebb's avatar
      ALSA: hda/realtek - Set principled PC Beep configuration for ALC256 · c4473744
      Thomas Hebb authored
      The Realtek PC Beep Hidden Register[1] is currently set by
      patch_realtek.c in two different places:
      
      In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to
      non-beep input on 1Ah and no 1Ah loopback to either headphones or
      speakers. (Although, curiously, the loopback amp is still enabled.) This
      write was added fairly recently by commit e3743f431143 ("ALSA:
      hda/realtek - Dell headphone has noise on unmute for ALC236") and is a
      safe default. However, it happens in the wrong place:
      alc_fill_eapd_coef() runs on module load and cold boot but not on S3
      resume, meaning the register loses its value after suspend.
      
      Conversely, in alc256_init(), the register is updated to unset bit 13
      (disable speaker loopback) and set bit 5 (set non-beep input on 1Ah).
      Although this write does run on S3 resume, it's not quite enough to fix
      up the register's default value of 0x3717. What's missing is a set of
      bit 14 to disable headphone loopback. Without that, we end up with a
      feedback loop where the headphone jack is being driven by amplified
      samples of itself[2].
      
      This change eliminates the update in alc256_init() and replaces it with
      the 0x5757 write from alc_fill_eapd_coef(). Kailang says that 0x5757 is
      supposed to be the codec's default value, so using it will make
      debugging easier for Realtek.
      
      Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs.
      
      [1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst
      
      [2] Setting the "Headphone Mic Boost" control from userspace changes
      this feedback loop and has been a widely-shared workaround for headphone
      noise on laptops like the Dell XPS 13 9350. This commit eliminates the
      feedback loop and makes the workaround unnecessary.
      
      Fixes: e1e8c1fd ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Hebb <tommyhebb@gmail.com>
      Link: https://lore.kernel.org/r/bf22b417d1f2474b12011c2a39ed6cf8b06d3bf5.1585584498.git.tommyhebb@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c4473744
    • Thomas Hebb's avatar
      ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256 · f1280904
      Thomas Hebb authored
      This codec (among others) has a hidden set of audio routes, apparently
      designed to allow PC Beep output without a mixer widget on the output
      path, which are controlled by an undocumented Realtek vendor register.
      The default configuration of these routes means that certain inputs
      aren't accessible, necessitating driver control of the register.
      However, Realtek has provided no documentation of the register, instead
      opting to fix issues by providing magic numbers, most of which have been
      at least somewhat erroneous. These magic numbers then get copied by
      others into model-specific fixups, leading to a fragmented and buggy set
      of configurations.
      
      To get out of this situation, I've reverse engineered the register by
      flipping bits and observing how the codec's behavior changes. This
      commit documents my findings. It does not change any code.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Hebb <tommyhebb@gmail.com>
      Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f1280904
  12. 30 Mar, 2020 1 commit
    • Mark Brown's avatar
      Merge series "ASoC: Intel: boards: Remove ignore_suspend flag from SSP0 dai... · 7f955811
      Mark Brown authored
      Merge series "ASoC: Intel: boards: Remove ignore_suspend flag from SSP0 dai link" from Cezary Rojewski <cezary.rojewski@intel.com>:
      
      As of commit:
      ASoC: soc-core: care .ignore_suspend for Component suspend
      
      function soc-core::snd_soc_suspend no longer ignores 'ignore_suspend'
      flag for dai links. While BE dai link for System Pin is
      supposed to follow standard suspend-resume flow, appended
      'ignore_suspend' flag disturbs that flow and causes audio to break
      right after resume. Remove the flag to address this.
      
      Link to first message in conversation:
      https://lkml.org/lkml/2020/3/18/54
      
      Cezary Rojewski (4):
        ASoC: Intel: broadwell: Remove ignore_suspend flag from SSP0 dai link
        ASoC: Intel: haswell: Remove ignore_suspend flag from SSP0 dai link
        ASoC: Intel: bdw-rt5677: Remove ignore_suspend flag from SSP0 dai link
        ASoC: Intel: bdw-rt5650: Remove ignore_suspend flag from SSP0 dai link
      
       sound/soc/intel/boards/bdw-rt5650.c | 1 -
       sound/soc/intel/boards/bdw-rt5677.c | 1 -
       sound/soc/intel/boards/broadwell.c  | 1 -
       sound/soc/intel/boards/haswell.c    | 1 -
       4 files changed, 4 deletions(-)
      
      --
      2.17.1
      7f955811