18 Nov, 2014

6 commits

  • The microphone mute led on the Latitude E5550 can't work. We need to
    apply DELL_WMI_MIC_MUTE_LED quirk to this machine.

    The machine uses alc293 codec and already applied the quirk
    ALC293_FIXUP_DELL1_MIC_NO_PRESENCE through pin_fixup_tbl[].

    Here we just let DELL_WMI_MIC_MUTE_LED be chained to
    ALC269_FIXUP_HEADSET_MODE, then the machine will have these
    quirks ALC293_FIXUP_DELL1_MIC_NO_PRESENCE-->
    ALC269_FIXUP_HEADSET_MODE-->ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED.

    BugLink: https://bugs.launchpad.net/bugs/1381856
    Reported-and-tested-by: Po-Hsu Lin
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai

    Hui Wang
     
  • We have one more Dell machine needs DELL_WMI_MIC_MUTE_LED quirk, but
    the machine uses alc293 instead of alc255. So if
    DELL_WMI_MIC_MUTE_LED still chain ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
    the machine can't use this quirk.

    To change this situation, let the DELL_WMI_MIC_MUTE_LED to be a
    standalone quirk, and let other quirks chain it.

    After this change, this quirk can be chained to any existing quirks,
    and as a result, it is possible that this quirk is applied to
    a non-Dell machine or a Dell machine without mic mute led on it, but
    it is still safe since alc_fixup_dell_wmi() will return an error in
    these situations.

    And remove the quirk for machine with subsystem id 0x6010 and 0x601f,
    these two machines will fall back to the quirk
    ALC255_FIXUP_DELL1_MIC_NO_PRESENCE-->ALC255_FIXUP_HEADSET_MODE-->
    ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED through pin_fixup_tbl[].

    BugLink: https://bugs.launchpad.net/bugs/1381856
    Reported-and-tested-by: Po-Hsu Lin
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai

    Hui Wang
     
  • …nie/sound into for-linus

    ASoC: Fixes for v3.18

    As well as the usual driver fixes there's a few other things here:

    One is a fix for a race in DPCM which is unfortuantely a rather large
    diffstat, this is the result of growing usage of the mainline code and
    hence more detailed testing so I'm relatively happy.

    The other is a fix for non-DT machine driver matching following some of
    the componentization work which is much more focused.

    Both have had a while to cook in -next.

    Takashi Iwai
     
  • …ix/sgtl5000' into asoc-linus

    Mark Brown
     
  • …cm', 'asoc/fix/es8328', 'asoc/fix/fsl-asrc', 'asoc/fix/max98090', 'asoc/fix/rcar', 'asoc/fix/rockchip' and 'asoc/fix/rt5645' into asoc-linus

    Mark Brown
     
  • Mark Brown
     

17 Nov, 2014

2 commits


16 Nov, 2014

1 commit

  • This patch adds a USB control message delay quirk for a few specific Marantz/Denon
    devices. Without the delay the DACs will not work properly and produces the
    following type of messages:

    Nov 15 10:09:21 orwell kernel: [ 91.342880] usb 3-13: clock source 41 is not valid, cannot use
    Nov 15 10:09:21 orwell kernel: [ 91.343775] usb 3-13: clock source 41 is not valid, cannot use

    There are likely other Marantz/Denon devices using the same USB module which exhibit the
    same problems. But as this cannot be verified I limited the patch to the devices
    I could test.

    The following two devices are covered by this path:
    - Marantz SA-14S1
    - Marantz HD-DAC1

    Signed-off-by: Jurgen Kramer
    Cc:
    Signed-off-by: Takashi Iwai

    Jurgen Kramer
     

14 Nov, 2014

1 commit

  • On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen
    5 seconds after the end of a playback.

    The SMALL_POP bit should fix this, but its definition is incorrect:
    according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
    bit 1.

    Fix the definition accordingly and enable the bit as intended per the code
    comment.

    After applying this change, no loud 'click' sound is heard after playback

    Signed-off-by: Fabio Estevam
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Fabio Estevam
     

13 Nov, 2014

1 commit

  • Lenovo Ideapad Z560 has a mute LED that is controlled via EAPD pin
    0x1b on CX20585 codec. (EAPD bit on corresponds to mute LED on.)
    The machine doesn't need other EAPD, so the fixup concentrates on
    controlling EAPD 0x1b following the vmaster state (but inversely).

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=665315
    Reported-by: Szymon Kowalczyk
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

12 Nov, 2014

3 commits

  • In commit a1253ef6d3fa ("ASoC: cs42l51: split i2c from codec driver"),
    the I2C part of the CS42L51 was moved to a separate file, but the
    definition of the of_device_id array was left in the driver file
    itself, no longer connected to the platform_driver structure using the
    .of_match_table pointer.

    This commit exports the of_device_id array in cs42l51, and uses it as
    .of_match_able in cs42l51-i2c.c. This solution was suggested by Brian
    Austin.

    Fixes: a1253ef6d3fa ("ASoC: cs42l51: split i2c from codec driver")
    Signed-off-by: Thomas Petazzoni
    Acked-by: Brian Austin
    Signed-off-by: Mark Brown
    Cc:

    Thomas Petazzoni
     
  • This will fix no sound in Linux system after reboot from windows.

    Change log:
    - alc662_fill_coef() is replaced with alc_fill_eapd_coef_idx()
    and move into alc_auto_init_amp().
    - For ALC262, ALC267, ALC268, ALC269, ALC233, ALC255, ALC280, ALC282,
    ALC283, ALC284, ALC285, ALC286, ALC288, ALC290, ALC292, ALC293, ALC294,
    ALC668, ALC888VC, ALC888VD, ALC891, ALC892, ALC898 and ALC1150, add update
    COEF control for EAPD setting.
    - Remove alc269_fill_coef() for update EAPD control line.

    ADDITIONAL NOTE:
    Many Realtek cdoecs have a COEF bit to switch the master amp control
    between COEF and EAPD. Windows drivers seem using COEF while we use
    EAPD, which is more standard. As a result, some system suffer from
    the silent output when booting after Windows. This patch sets the
    COEF bits on the relevant codecs properly to switch to EAPD control.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=87771
    Signed-off-by: Kailang Yang
    Signed-off-by: Takashi Iwai

    Kailang Yang
     
  • M-audio FastTrack Ultra quirk doesn't release the kzalloc'ed memory.
    This patch adds the private_free callback to release it properly.

    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

09 Nov, 2014

1 commit


06 Nov, 2014

4 commits


05 Nov, 2014

4 commits

  • Some USB-audio devices show weird sysfs warnings at disconnecting the
    devices, e.g.
    usb 1-3: USB disconnect, device number 3
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180()
    sysfs group ffffffff8183df40 not found for kobject 'midiC1D0'
    Call Trace:
    [] ? dump_stack+0x49/0x71
    [] ? warn_slowpath_common+0x82/0xb0
    [] ? warn_slowpath_fmt+0x45/0x50
    [] ? device_del+0x39/0x180
    [] ? device_unregister+0x9/0x20
    [] ? device_destroy+0x34/0x40
    [] ? snd_unregister_device+0x7f/0xd0 [snd]
    [] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi]
    [] ? snd_device_disconnect+0x62/0x90 [snd]
    [] ? snd_device_disconnect_all+0x3c/0x60 [snd]
    [] ? snd_card_disconnect+0x124/0x1a0 [snd]
    [] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio]
    [] ? usb_unbind_interface+0x5e/0x1b0 [usbcore]
    [] ? __device_release_driver+0x79/0xf0
    [] ? device_release_driver+0x25/0x40
    [] ? bus_remove_device+0xf1/0x130
    [] ? device_del+0x109/0x180
    [] ? usb_disable_device+0x95/0x1f0 [usbcore]
    [] ? usb_disconnect+0x8f/0x190 [usbcore]
    [] ? hub_thread+0x539/0x13a0 [usbcore]
    [] ? sched_clock_local+0x15/0x80
    [] ? sched_clock_cpu+0xb8/0xd0
    [] ? bit_waitqueue+0xb0/0xb0
    [] ? usb_port_resume+0x430/0x430 [usbcore]
    [] ? usb_port_resume+0x430/0x430 [usbcore]
    [] ? kthread+0xce/0xf0
    [] ? kthread_create_on_node+0x1c0/0x1c0
    [] ? ret_from_fork+0x7c/0xb0
    [] ? kthread_create_on_node+0x1c0/0x1c0
    ---[ end trace 40b1928d1136b91e ]---

    This comes from the fact that usb-audio driver may receive the
    disconnect callback multiple times, per each usb interface. When a
    device has both audio and midi interfaces, it gets called twice, and
    currently the driver tries to release resources at the last call.
    At this point, the first parent interface has been already deleted,
    thus deleting a child of the first parent hits such a warning.

    For fixing this problem, we need to call snd_card_disconnect() and
    cancel pending operations at the very first disconnect while the
    release of the whole objects waits until the last disconnect call.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931
    Reported-and-tested-by: Tomas Gayoso
    Reported-and-tested-by: Chris J Arges
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • Without the fix, the mute led can't work on these three machines.

    After apply this fix, these three machines will fall back on the led
    control quirk as below, and through testing, the mute led works very
    well.
    PIN_QUIRK(0x10ec0282, 0x103c, "HP", ALC269_FIXUP_HP_LINE1_MIC1_LED,
    ALC282_STANDARD_PINS,
    {0x12, 0x90a60140},
    ...

    BugLink: https://bugs.launchpad.net/bugs/1389497
    Tested-by: TieFu Chen
    Cc: Kailang Yang
    Cc: stable@vger.kernel.org
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai

    Hui Wang
     
  • The Baytrail-based chromebooks have a 20MHz mclk, the code was setting
    the divisor incorrectly in this case. According to the 98090
    datasheet, the divisor should be set to DIV1 for 10
    Signed-off-by: Mark Brown

    Dylan Reid
     
  • DPCM can update the FE/BE connection states totally asynchronously
    from the FE's PCM state. Most of FE/BE state changes are protected by
    mutex, so that they won't race, but there are still some actions that
    are uncovered. For example, suppose to switch a BE while a FE's
    stream is running. This would call soc_dpcm_runtime_update(), which
    sets FE's runtime_update flag, then sets up and starts BEs, and clears
    FE's runtime_update flag again.

    When a device emits XRUN during this operation, the PCM core triggers
    snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
    isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
    It eventually updates and clears FE's runtime_update flag while
    soc_dpcm_runtime_update() is running concurrently, and it results in
    confusion.

    Usually, for avoiding such a race, we take a lock. There is a PCM
    stream lock for that purpose. However, as already mentioned, the
    trigger action is atomic, and we can't take the lock for the whole
    soc_dpcm_runtime_update() or other operations that include the lengthy
    jobs like hw_params or prepare.

    This patch provides an alternative solution. This adds a way to defer
    the conflicting trigger callback to be executed at the end of FE/BE
    state changes. For doing it, two things are introduced:

    - Each runtime_update state change of FEs is protected via PCM stream
    lock.
    - The FE's trigger callback checks the runtime_update flag. If it's
    not set, the trigger action is executed there. If set, mark the
    pending trigger action and returns immediately.
    - At the exit of runtime_update state change, it checks whether the
    pending trigger is present. If yes, it executes the trigger action
    at this point.

    Reported-and-tested-by: Qiao Zhou
    Signed-off-by: Takashi Iwai
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Takashi Iwai
     

30 Oct, 2014

5 commits

  • The default EAPD control uses verb command to control EAPD. Some codec
    does not have verb command for EAPD. It needs to control by hidden
    register.

    This update will avoid wrong behavior for some codec. This patch will
    fix double setup for EAPD. It just needs to turn on by one site for
    verb command or hidden register controlled.

    Detailed changes:
    - alc889_coef_init() is replaced with alc_update_coef_idx() with a
    correct COEF value.
    - for ALC262, ALC887 and ALC900, the EAPD setup via the hidden
    register is removed because this rather conflicts with the EAPD verb
    setup.
    - For ALC888-VC, also the hidden register access is removed in
    alc888_coef_init().
    - Remove the dead #if 0 code for ALC267/ALC268.

    Signed-off-by: Kailang Yang
    Cc:
    Signed-off-by: Takashi Iwai

    Kailang Yang
     
  • These three HP machines all have the same pin config, so we can
    change it to a pin quirk.

    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai

    David Henningsson
     
  • These HP machines needs GPIO 4 low to enable the headphone amplifier.
    In addition, we still need to control LEDs via vref and GPIO.

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

    David Henningsson
     
  • Adding ultra doch support for Lenovo Thinkpad X240 (17aa:2214).
    [Actually replaced the entry with ALC292_FIXUP_TPT440_DOCK -- tiwai]

    Signed-off-by: Lukas Bossard
    Cc:
    Signed-off-by: Takashi Iwai

    Lukas Bossard
     
  • Commit 14621c7e5e72 ("ASoC: Consolidate CPU and CODEC DAI lookup")
    consolidated the lookup of CPU DAIs and CODEC DAIs into a single function.
    When matching a component by name for CODEC DAIs the code previous to the
    patch compared the name in the DAI link table with component->name. For CPU
    DAIs the code compared to dev_name(component->dev). The newly introduced
    function ended up using the later as well.

    For most components dev_name(component->dev) and component->name are the
    same. The main notable exception are I2C devices where the driver name and
    the device name are concatenated to form the component name. By using
    dev_name(component->dev) instead of component->name the patch broke the
    matching of I2C CODECs by name.

    This patch restores the original behavior by using component->name instead
    of dev_name(component->dev). This will be safe even for CPU DAIs since for
    CPU DAIs both are the same.

    Fixes: 14621c7e5e72 ("ASoC: Consolidate CPU and CODEC DAI lookup")
    Reported-by: Dmitry Eremin-Solenikov
    Signed-off-by: Lars-Peter Clausen
    Signed-off-by: Mark Brown

    Lars-Peter Clausen
     

29 Oct, 2014

5 commits


28 Oct, 2014

3 commits

  • In compat mode, we copy each field of snd_pcm_status struct but don't
    touch the reserved fields, and this leaves uninitialized values
    there. Meanwhile the native ioctl does zero-clear the whole
    structure, so we should follow the same rule in compat mode, too.

    Reported-by: Pierre-Louis Bossart
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • The convention for i2c_device_id name does not need to have company prefix.

    Signed-off-by: Axel Lin
    Signed-off-by: Mark Brown

    Axel Lin
     
  • Kernel dump (WARN_ON) ocurred during system boot-up inside regmap_write():

    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 47 at kernel/locking/lockdep.c:2744 lockdep_trace_alloc+0xe8/0x108()
    DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
    Modules linked in:
    CPU: 0 PID: 47 Comm: kworker/u2:2 Not tainted 3.18.0-rc1-10245-gb75d289-dirty #56
    Workqueue: deferwq deferred_probe_work_func
    Backtrace:
    [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
    r6:8097c73c r5:8097c73c r4:00000000 r3:be33ba80
    [] (show_stack) from [] (dump_stack+0x8c/0xa4)
    [] (dump_stack) from [] (warn_slowpath_common+0x70/0x94)
    r6:80062838 r5:00000009 r4:bd827b30 r3:be33ba80
    [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40)
    r8:00000004 r7:00000001 r6:000080d0 r5:60000193 r4:bd826010
    [] (warn_slowpath_fmt) from [] (lockdep_trace_alloc+0xe8/0x108)
    r3:80831590 r2:8082e160
    [] (lockdep_trace_alloc) from [] (kmem_cache_alloc+0x28/0x134)
    r5:000080d0 r4:be001f00
    [] (kmem_cache_alloc) from [] (regcache_rbtree_write+0x15c/0x648)
    r10:00000000 r9:0000001c r8:00000004 r7:00000001 r6:00000000 r5:bd819a00
    r4:00000000 r3:811aea88
    [] (regcache_rbtree_write) from [] (regcache_write+0x5c/0x64)
    r10:be3f9f88 r9:00000000 r8:00000004 r7:00000001 r6:00000000 r5:00000001
    r4:bd819a00
    [] (regcache_write) from [] (_regmap_raw_write+0x134/0x5f4)
    r6:be3f9f84 r5:00000001 r4:bd819a00 r3:00000001
    [] (_regmap_raw_write) from [] (_regmap_bus_raw_write+0x74/0x94)
    r10:00000000 r9:00000001 r8:be3fb080 r7:bd819a00 r6:00000001 r5:00000000
    r4:bd819a00
    [] (_regmap_bus_raw_write) from [] (_regmap_write+0x60/0x9c)
    r6:00000001 r5:00000000 r4:bd819a00 r3:8038b59c
    [] (_regmap_write) from [] (regmap_write+0x48/0x68)
    r7:bd81ad80 r6:00000001 r5:00000000 r4:bd819a00
    [] (regmap_write) from [] (fsl_asrc_dai_probe+0x34/0x104)
    r6:bd888628 r5:be3fb080 r4:be3b4410 r3:be3b442c
    ------------[ dump end ]------------

    =============================================================================
    2741 /*
    2742 * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
    2743 */
    2744 if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
    2745 return;
    =============================================================================

    By looking at 2744 line, we can get that it's because regcache_rbtree_write()
    would call kmalloc() with GFP flag if it couldn't find an existing block to
    insert nodes while this kmalloc() call is inside a spin_lock_irq_save pair,
    i.e. IRQs disabled.

    Even though this may be a bug that should be fixed, I still try to send this
    patch as a quick fix (work around) since it does no harm to assign default
    values of every registers when using regcache.

    Signed-off-by: Nicolin Chen
    Signed-off-by: Mark Brown

    Nicolin Chen
     

27 Oct, 2014

4 commits