Skip to content
  1. Apr 06, 2021
  2. Mar 30, 2021
  3. Mar 29, 2021
  4. Mar 22, 2021
    • Hui Wang's avatar
      ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook · e54f30be
      Hui Wang authored
      
      
      We found the alc_update_headset_mode() is not called on some machines
      when unplugging the headset, as a result, the mode of the
      ALC_HEADSET_MODE_UNPLUGGED can't be set, then the current_headset_type
      is not cleared, if users plug a differnt type of headset next time,
      the determine_headset_type() will not be called and the audio jack is
      set to the headset type of previous time.
      
      On the Dell machines which connect the dmic to the PCH, if we open
      the gnome-sound-setting and unplug the headset, this issue will
      happen. Those machines disable the auto-mute by ucm and has no
      internal mic in the input source, so the update_headset_mode() will
      not be called by cap_sync_hook or automute_hook when unplugging, and
      because the gnome-sound-setting is opened, the codec will not enter
      the runtime_suspend state, so the update_headset_mode() will not be
      called by alc_resume when unplugging. In this case the
      hp_automute_hook is called when unplugging, so add
      update_headset_mode() calling to this function.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e54f30be
    • Hui Wang's avatar
      ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO · febf2256
      Hui Wang authored
      
      
      We found a recording issue on a Dell AIO, users plug a headset-mic and
      select headset-mic from UI, but can't record any sound from
      headset-mic. The root cause is the determine_headset_type() returns a
      wrong type, e.g. users plug a ctia type headset, but that function
      returns omtp type.
      
      On this machine, the internal mic is not connected to the codec, the
      "Input Source" is headset mic by default. And when users plug a
      headset, the determine_headset_type() will be called immediately, the
      codec on this AIO is alc274, the delay time for this codec in the
      determine_headset_type() is only 80ms, the delay is too short to
      correctly determine the headset type, the fail rate is nearly 99% when
      users plug the headset with the normal speed.
      
      Other codecs set several hundred ms delay time, so here I change the
      delay time to 850ms for alc2x4 series, after this change, the fail
      rate is zero unless users plug the headset slowly on purpose.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Link: https://lore.kernel.org/r/20210320091542.6748-1-hui.wang@canonical.com
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      febf2256
  5. Mar 18, 2021
  6. Mar 17, 2021
    • Mark Brown's avatar
      Merge series "Do not handle MCLK device clock in simple-card-utils" from... · f9dc51cc
      Mark Brown authored
      Merge series "Do not handle MCLK device clock in simple-card-utils" from Sameer Pujar <spujar@nvidia.com>:
      
      With commit 1e30f642 ("ASoC: simple-card-utils: Fix device module clock")
      simple-card-utils can control MCLK clock for rate updates or enable/disable.
      But this is breaking some platforms where it is expected that codec drivers
      would actually handle the MCLK clock. One such example is following platform.
        - "arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts"
      
      In above case codec, wm8904, is using internal PLL and configures sysclk
      based on fixed MCLK input. In such cases it is expected that, required PLL
      output or sysclk, is just passed via set_sysclk() callback and card driver
      need not actually update MCLK rate. Instead, codec can take ownership of
      this clock and do the necessary configuration.
      
      So the original commit is reverted and codec driver for rt5659 is updated
      to fix my board which has this codec.
      
      Sameer Pujar (2):
        ASoC: simple-card-utils: Do not handle device clock
        ASoC: rt5659: Update MCLK rate in set_sysclk()
      
       sound/soc/codecs/rt5659.c             |  5 +++++
       sound/soc/generic/simple-card-utils.c | 13 +++++++------
       2 files changed, 12 insertions(+), 6 deletions(-)
      
      --
      2.7.4
      f9dc51cc
  7. Mar 16, 2021
  8. Mar 14, 2021
  9. Mar 12, 2021
  10. Mar 11, 2021
  11. Mar 10, 2021