23 Dec, 2015

2 commits


22 Dec, 2015

1 commit

  • Without this patch, internal speaker and line-out work,
    but front headphone output jack stays silent on the
    Mac Pro 4,1.

    This code path also gets executed on the MacPro 5,1 due
    to identical codec SSID, but i don't know if it has any
    positive or adverse effects there or not.

    (v2) Implement feedback from Takashi Iwai: Reuse
    alc889_fixup_mbp_vref and just add a new nid
    0x19 for the MacPro 4,1.

    Signed-off-by: Mario Kleiner
    Cc:
    Signed-off-by: Takashi Iwai

    Mario Kleiner
     

18 Dec, 2015

2 commits

  • After several open/close sai test with ctrl+c, there will be
    I/O error. The SAI can't work anymore, can't recover. There
    will be no frame clock. With adding the software reset in
    trigger stop, the issue can be fixed.

    This is a hardware bug/errata and reset is the only option.

    According to the reference manual, the software reset doesn't
    reset any control register but only internal hardware logics
    such as bit clock generator, status flags, and FIFO pointers.
    (Our purpose is just to reset the clock generator while the
    software reset is the only way to do that.)

    Since slave mode doesn't use the clock generator, only apply
    the reset procedure to the master mode.

    For asynchronous mode, TX will not be reset when RX is still
    running. In this case, i can't reproduce this issue.

    Signed-off-by: Zidan Wang
    Acked-by: Nicolin Chen
    Signed-off-by: Mark Brown

    Zidan Wang
     
  • It takes three minutes to enter into hibernation on some OEM SKL
    machines and we see many codec spurious response after thaw() opertion.
    This is because HDA is still in D0 state after freeze() call and
    pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
    It seems bios still access HDA when system enter into freeze state,
    HDA will receive codec response interrupt immediately after thaw() call.
    Because of this unexpected interrupt, HDA enter into a abnormal
    state and slow down the system enter into hibernation.

    In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
    put HDA into D0 state in azx_thaw_noirq().

    V2: Only apply this fix to SKL+
    Fix compile error when CONFIG_PM_SLEEP isn't defined

    [Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment
    by tiwai]

    Signed-off-by: Xiong Zhang
    Cc:
    Signed-off-by: Takashi Iwai

    Xiong Zhang
     

17 Dec, 2015

1 commit


15 Dec, 2015

4 commits

  • Apply the same fixup for Thinkpad with dock to Thinkpad X1 Carbon 2nd,
    too. This reduces the annoying loud cracking noise problem, as well
    as the support of missing docking port.

    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439
    Reported-and-tested-by: Benjamin Poirier
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • Lenovo Thinkpads with Realtek codecs may still have some loud
    crackling noises at reboot/shutdown even though a few previous fixes
    have been applied. It's because the previous fix (disabling the
    default shutup callback) takes effect only at transition of the codec
    power state. Meanwhile, at reboot or shutdown, we don't take down the
    codec power as default, thus it triggers the same problem unless the
    codec is powered down casually by runtime PM.

    This patch tries to address the issue. It gives two things:
    - implement the separate reboot_notify hook to struct alc_spec, and
    call it optionally if defined.
    - turn off the codec to D3 for Thinkpad models via this new callback

    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439
    Reported-and-tested-by: Benjamin Poirier
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • It seems that a workaround for Thinkpad T440s crackling noise can be
    applied generically to all Thinkpad models: namely, disabling the
    default alc269 shutup callback. This patch moves it to the existing
    alc_fixup_tpt440_dock() while also replacing the rest code with
    another existing alc_fixup_disable_aamix(). It resulted in a good
    code reduction.

    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439
    Reported-and-tested-by: Benjamin Poirier
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • These laptops support both headphone, headset and mic modes
    for the 3.5mm jack.

    Cc: stable@vger.kernel.org
    BugLink: https://bugs.launchpad.net/bugs/1526330
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai

    David Henningsson
     

14 Dec, 2015

2 commits

  • Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
    and causes noisy "cannot get freq at ep 0x1" messages when playback
    starts.

    Signed-off-by: Anssi Hannula
    Cc:
    Signed-off-by: Takashi Iwai

    Anssi Hannula
     
  • AudioQuest DragonFly DAC reports a volume control range of 0..50
    (0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
    is obviously incorrect and would cause software using the dB information
    in e.g. volume sliders to have a massive volume difference in 100..102%
    range.

    Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some
    devices") added a dB range mapping for it with range 0..50 dB.

    However, the actual volume mapping seems to be neither linear volume nor
    linear dB scale, but instead quite close to the cubic mapping e.g.
    alsamixer uses, with a range of approx. -53...0 dB.

    Replace the previous quirk with a custom dB mapping based on some basic
    output measurements, using a 10-item range TLV (which will still fit in
    alsa-lib MAX_TLV_RANGE_SIZE).

    Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
    range is 0..50, so if this gets fixed/changed in later HW revisions it
    will no longer be applied.

    v2: incorporated Takashi Iwai's suggestion for the quirk application
    method

    Signed-off-by: Anssi Hannula
    Cc:
    Signed-off-by: Takashi Iwai

    Anssi Hannula
     

13 Dec, 2015

3 commits

  • Explicitly set the transmit data level on the transceiver to 16 samples
    rather then the default 0. This matches both the level set in the vendor
    kernel and the (seemingly very similar) i2s engine. This fixes audio
    glitches when playing back at 192k rate.

    At the same time, fix a trivial typo in the TDL mask definition

    Signed-off-by: Sjoerd Simons
    Signed-off-by: Mark Brown

    Sjoerd Simons
     
  • Attempting to use this codec driver triggers a BUG() in regcache_sync()
    since no cache type is set. The register map of this device is fairly
    small and has few holes so a flat cache is suitable.

    Signed-off-by: Mans Rullgard
    Acked-by: Charles Keepax
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Mans Rullgard
     
  • These are all off by one; the playback and bypass switches are the top
    two bits of the registers, which are at shifts 7 and 6 not 8 and 7.

    Signed-off-by: John Keeping
    Signed-off-by: Mark Brown

    John Keeping
     

11 Dec, 2015

1 commit


10 Dec, 2015

2 commits


09 Dec, 2015

1 commit

  • Lenovo Thinkpad T440s suffers from constant background noises, and it
    seems to be a generic hardware issue on this model:
    https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T440s-speaker-noise/td-p/1339883

    As the noise comes from the analog loopback path, disabling the path
    is the easy workaround.

    Also, the machine gives significant cracking noises at PM suspend. A
    workaround found by trial-and-error is to disable the shutup callback
    currently used for ALC269-variant.

    This patch addresses these noise issues by introducing a new fixup
    chain. Although the same workaround might be applicable to other
    Thinkpad models, it's applied only to T440s (17aa:220c) in this patch,
    so far, just to be safe (you chicken!). As a compromise, a new model
    option string "tp440" is provided now, though, so that owners of other
    Thinkpad models can test it more easily.

    Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=958504
    Reported-and-tested-by: Tim Hardeck
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

08 Dec, 2015

1 commit

  • We have two latest thinkpad laptop models which are all based on the
    Intel skylake platforms, and all of them have the codec alc293 on
    them. When the machines boot to the desktop, an greeting dialogue
    shows up with the notification sound. But on these two models, there
    is noise with the notification sound. We have 3 SKUs for each of
    the models, all of them have this problem.

    So far, this problem is only specific to these two thinkpad models,
    we did not find this problem on the old thinkpad models with the
    codec alc293 or alc292.

    A workaround for this problem is disabling the aamix.

    Cc: stable@vger.kernel.org
    BugLink: https://bugs.launchpad.net/bugs/1523517
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai

    Hui Wang
     

07 Dec, 2015

2 commits


05 Dec, 2015

1 commit

  • rme96 driver needs to reset DAC depending on the sample rate, and this
    results in resetting to the max volume suddenly. It's because of the
    missing call of snd_rme96_apply_dac_volume().

    However, calling this function right after the DAC reset still may not
    work, and we need some delay before this call. Since the DAC reset
    and the procedure after that are performed in the spinlock, we delay
    the DAC volume restore at the end after the spinlock.

    Reported-and-tested-by: Sylvain LABOISNE
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

01 Dec, 2015

2 commits


27 Nov, 2015

2 commits

  • The recent addition of ELD notifier for Intel HDMI/DP codec may lead
    the bad codec connection found as kernel messages like below:
    Suspending console(s) (use no_console_suspend to debug)
    hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
    snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
    snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
    ....
    snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
    snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
    snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
    snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
    azx_single_wait_for_response: 42 callbacks suppressed

    This seems appearing when the sound driver went to suspend before i915
    driver. Then i915 driver disables HDMI/DP audio bit and calls the
    registered notifier, and the HDA codec tries to handle it as a
    hot(un)plug. But since the driver is already in the suspended state,
    it fails miserably.

    As this is a sort of spurious wakeup, it can be ignored safely, as
    long as it's delivered during the system suspend. OTOH, if a
    notification comes during the runtime suspend, the situation is
    different: we need to wake up. But during the system suspend, such a
    notification can't be the reason for a wakeup.

    This patch addresses it by a simple check of the current sound card
    status. The skipped notification doesn't matter because the HDA
    driver will check the plugged status forcibly at the resume in
    return.

    Then, why the card status, not a runtime PM status or else? The HDA
    controller driver is supposed to set the card status to D3 at the
    system suspend but not at the runtime suspend. So we can see it as a
    flag that is set only for the system suspend. Admittedly, it's a bit
    ugly, but it should work well for now.

    Reported-and-tested-by: "Zhang, Xiong Y"
    Fixes: 25adc137c546 ('ALSA: hda - Wake the codec up on pin/ELD notify events')
    Cc: # v4.3+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • …roonie/sound into for-linus

    ASoC: Fixes for v4.4

    Quite a large batch of fixes have come in since the merge window, mainly
    driver specific ones but there's a couple of core ones:

    - A fix for DAPM resume on active streams to ensure everything ends up
    cleanly in the right state.
    - Reset the DAPM cache when freeing widgets to fix a crash on driver
    remove and reload.

    The PM functions for nau8825 are new code which fix crashes on resume.

    Takashi Iwai
     

26 Nov, 2015

6 commits


25 Nov, 2015

6 commits

  • For DAPM resume, we should first change the power state of the
    card and then recheck the endpoints. This ensures the dapm is
    resumed first and then userspace can resume the streams.

    Signed-off-by: Jeeja KP
    Signed-off-by: Vinod Koul
    Reviewed-by: Lars-Peter Clausen
    Signed-off-by: Mark Brown

    Jeeja KP
     
  • Fix kernel-doc warnings in soc-ops.c:

    ..//sound/soc/soc-ops.c:415: warning: No description found for parameter 'ucontrol'
    ..//sound/soc/soc-ops.c:415: warning: Excess function parameter 'uinfo' description in 'snd_soc_put_volsw_sx'

    Signed-off-by: Randy Dunlap
    Cc: Liam Girdwood
    Cc: Mark Brown
    Signed-off-by: Mark Brown

    Randy Dunlap
     
  • Add platform specific data for Terra project.

    Signed-off-by: Luke_Yin@asus.com
    Signed-off-by: Bard Liao
    Signed-off-by: Mark Brown

    Bard Liao
     
  • Correct valid data word register value for 24 bit data width. The
    bit value should be 10 (aka 0x2), not 0x10.

    This fixes playback of 24 bit audio.

    Signed-off-by: Sjoerd Simons
    Reviewed-by: Caesar Wang
    Signed-off-by: Mark Brown

    Sjoerd Simons
     
  • A new randconfig build failure shows that the fsl-asoc-card module
    must not be built-in when the AC97 driver is a loadable module:

    sound/built-in.o: In function `fsl_asoc_card_late_probe':
    :(.text+0x571d8): undefined reference to `snd_ac97_update_bits'

    I couldn't come up with a nice solution, so this adds another dependency
    on "X || !X", which is the Kconfig way of saying that we have an
    optional dependency on something that might be a loadable module.

    Fixes: 50760cad9de9 ("ASoC: fsl-asoc-card: add AC'97 support")
    Signed-off-by: Arnd Bergmann
    Acked-by: Nicolin Chen
    Signed-off-by: Mark Brown

    Arnd Bergmann
     
  • Gigabyte Z710X mobo with ALC1150 codec gets significant noises from
    the analog loopback routes even if their inputs are all muted.
    Simply kill the aamix for fixing it.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

24 Nov, 2015

1 commit

  • We have a machine Dell XPS 13 with the codec alc256, after resume back
    from S3, the headphone has noise when play sound.

    Through comparing with the coeff vaule before and after S3, we found
    restoring a coeff register will help remove noise.

    BugLink: https://bugs.launchpad.net/bugs/1519168
    Cc: Kailang Yang
    Cc:
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai

    Hui Wang