23 Jan, 2013

1 commit

  • The commit [26a6cb6c: ALSA: hda - Implement a poll loop for jacks as a
    module parameter] introduced the polling jack detection code, but it
    also moved the call of snd_hda_jack_set_dirty_all() in the resume path
    after resume/init ops call. This caused a regression when the jack
    state has been changed during power-down (e.g. in the power save
    mode). Since the driver doesn't probe the new jack state but keeps
    using the cached value due to no dirty flag, the pin state remains
    also as if the jack is still plugged.

    The fix is simply moving snd_hda_jack_set_dirty_all() to the original
    position.

    Reported-by: Manolo Díaz
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

21 Jan, 2013

1 commit


19 Jan, 2013

1 commit


18 Jan, 2013

1 commit


15 Jan, 2013

1 commit

  • When "alsactl restore" is performed on HDMI codecs, it tries to
    restore the channel map value since the channel map controls are
    writable. But hdmi_chmap_ctl_put() returns -EBADFD when no PCM stream
    is assigned yet, and this results in an error message from alsactl.
    Although the error is harmless, it's certainly ugly and can be
    regarded as a regression.

    As a workaround, this patch changes the return code in such a case to
    be zero for making others happy. (A slight excuse is: when the chmap
    is changed through the proper alsa-lib API, the PCM status is checked
    there anyway, so we don't have to be too strict in the kernel side.)

    Cc: [v3.7+]
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

14 Jan, 2013

4 commits

  • Add names of the clock sources for the M-Audio Fast Track
    C400.

    Signed-off-by: Eldad Zack
    Signed-off-by: Takashi Iwai

    Eldad Zack
     
  • Attain constant real-world latency by skipping 16 data packets.
    The number of packets to be skipped was found by trial and error.

    Signed-off-by: Eldad Zack
    Signed-off-by: Takashi Iwai

    Eldad Zack
     
  • Taking another look at the C400 descriptors, I see now that there is
    a clock selector (0x80) for this device.
    Right now, the clock source points to the internal clock (0x81), which
    is also valid. When the external clock source (0x82) is selected in the
    mixer, and the rates mismatch (if it's free-running it is fixed to
    48KHz), xruns will occur.

    Set the clock ID to the clock selector unit (0x81), which then
    allows the validation code to function correctly.

    Signed-off-by: Eldad Zack
    Signed-off-by: Takashi Iwai

    Eldad Zack
     
  • A patch in the 3.2 kernel caused regression with hotplugging the
    M-Audio Fast track pro, or sound after suspend. I don't have the
    device so I haven't done a full analysis, but it seems userspace
    (both udev and pulseaudio) got confused when a card was created,
    immediately destroyed, and then created again.

    However, at least one person in the bug report (martin djfun)
    reports that this patch resolves the issue for him. It also leaves
    a message in the log:
    "snd-usb-audio: probe of 1-1.1:1.1 failed with error -5" which is
    a bit misleading. It is better than non-working audio, but maybe
    there's a more elegant solution?

    BugLink: https://bugs.launchpad.net/bugs/1095315
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai

    David Henningsson
     

11 Jan, 2013

2 commits


10 Jan, 2013

14 commits


09 Jan, 2013

3 commits


08 Jan, 2013

4 commits

  • This patch fixes some code that implements a work-around to a hardware bug in
    the ac97 controller on the pxa27x. A bug in the controller's warm reset
    functionality requires that the mfp used by the controller as the AC97_nRESET
    line be temporarily reconfigured as a generic output gpio (AF0) and manually
    held high for the duration of the warm reset cycle. This is what was done in
    the original code, but it was broken long ago by commit fb1bf8cd
    ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset())
    which changed the mfp to a GPIO input instead of a high output.

    The fix requires the ac97 controller to obtain the gpio via gpio_request_one(),
    with arguments that configure the gpio as an output initially driven high.

    Tested on a palm treo 680 machine. Reportedly, this broken code only prevents a
    warm reset on hardware that lacks a pull-up on the line, which appears to be the
    case for me.

    Signed-off-by: Mike Dunn
    Signed-off-by: Igor Grinberg
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Mike Dunn
     
  • Cold reset on the pxa27x currently fails and

    pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44)

    appears in the kernel log. Through trial-and-error (the pxa270 developer's
    manual is mostly incoherent on the topic of ac97 reset), I got cold reset to
    complete by setting the WARM_RST bit in the GCR register (and later noticed that
    pxa3xx does this for cold reset as well). Also, a timeout loop is needed to
    wait for the reset to complete.

    Tested on a palm treo 680 machine.

    Signed-off-by: Mike Dunn
    Acked-by: Igor Grinberg
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Mike Dunn
     
  • Otherwise we won't run correctly on systems that require this for larger
    data transfers.

    Signed-off-by: Mark Brown

    Mark Brown
     
  • The mute LED is in this case connected to the Mic1 VREF.

    The machine also exposes the following string in BIOS:
    "HP_Mute_LED_0_A", so if more machines are coming, it probably
    makes sense to try to do something more generic, like for the
    IDT codec.

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

    David Henningsson
     

07 Jan, 2013

1 commit

  • vortex_wt_setdsout performs bit-negation on the bit position (wt&0x1f)
    rather than on the resulting bitmask. This code is never actually
    invoked (vortex_wt_setdsout is always called with en=1), so this does
    not currently cause any problem, and this patch is simply cleanup.

    Signed-off-by: Nickolai Zeldovich
    Signed-off-by: Takashi Iwai

    Nickolai Zeldovich
     

05 Jan, 2013

2 commits


04 Jan, 2013

4 commits


03 Jan, 2013

1 commit

  • Support the Creative BT-D1 Bluetooth USB audio device. Before this
    patch, Linux had trouble finding the correct USB descriptors and bailed
    out with these messages:

    no or invalid class specific endpoint descriptor

    Now it still prints these messages on hotplug:

    snd-usb-audio: probe of ...:1.0 failed with error -5
    snd-usb-audio: probe of ...:1.2 failed with error -5
    snd-usb-audio: probe of ...:1.3 failed with error -5

    But the device works correctly, including the HID support.

    The patch is diff'ed against 3.8-rc1 but should apply to older kernels
    as well.

    Signed-off-by: Alexander Schremmer
    Signed-off-by: Takashi Iwai

    Alexander Schremmer