1. 11 11月, 2014 6 次提交
  2. 10 11月, 2014 4 次提交
  3. 07 11月, 2014 1 次提交
  4. 06 11月, 2014 2 次提交
    • T
      ALSA: usb-audio: Trigger PCM XRUN at XRUN · 67e22500
      Takashi Iwai 提交于
      The usb-audio driver detects XRUN at its complete callback, but the
      actual code to trigger PCM XRUN is commented out because it caused
      deadlock in the past.  This patch revives the PCM trigger properly.
      It resulted in more than just enabling snd_pcm_stop(), but it had to
      deduce the PCM substream with proper NULL checks and holds the stream
      lock around the call.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      67e22500
    • T
      ALSA: pcm: Update the state properly before notification · 9bc889b4
      Takashi Iwai 提交于
      Some state changes (e.g. snd_pcm_stop()) sets the runtime state after
      calling snd_timer_notify().  This is basically racy, since the
      notification may wakes up the user even before the state change.
      Although the possibility is low, we should set the state before the
      notifications.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9bc889b4
  5. 05 11月, 2014 5 次提交
    • T
      Merge branch 'for-linus' into for-next · 19566b0b
      Takashi Iwai 提交于
      This merges the USB-audio disconnect fix and resolves the conflicts
      so that we can continue working on development of usb-audio stuff.
      
      Conflicts:
      	sound/usb/card.c
      19566b0b
    • T
      ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect · 0725dda2
      Takashi Iwai 提交于
      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:
        [<ffffffff814a3e38>] ? dump_stack+0x49/0x71
        [<ffffffff8103cb72>] ? warn_slowpath_common+0x82/0xb0
        [<ffffffff8103cc55>] ? warn_slowpath_fmt+0x45/0x50
        [<ffffffff813521e9>] ? device_del+0x39/0x180
        [<ffffffff81352339>] ? device_unregister+0x9/0x20
        [<ffffffff81352384>] ? device_destroy+0x34/0x40
        [<ffffffffa00ba29f>] ? snd_unregister_device+0x7f/0xd0 [snd]
        [<ffffffffa025124e>] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi]
        [<ffffffffa00c0192>] ? snd_device_disconnect+0x62/0x90 [snd]
        [<ffffffffa00c025c>] ? snd_device_disconnect_all+0x3c/0x60 [snd]
        [<ffffffffa00bb574>] ? snd_card_disconnect+0x124/0x1a0 [snd]
        [<ffffffffa02e54e8>] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio]
        [<ffffffffa015260e>] ? usb_unbind_interface+0x5e/0x1b0 [usbcore]
        [<ffffffff813553e9>] ? __device_release_driver+0x79/0xf0
        [<ffffffff81355485>] ? device_release_driver+0x25/0x40
        [<ffffffff81354e11>] ? bus_remove_device+0xf1/0x130
        [<ffffffff813522b9>] ? device_del+0x109/0x180
        [<ffffffffa01501d5>] ? usb_disable_device+0x95/0x1f0 [usbcore]
        [<ffffffffa014634f>] ? usb_disconnect+0x8f/0x190 [usbcore]
        [<ffffffffa0149179>] ? hub_thread+0x539/0x13a0 [usbcore]
        [<ffffffff810669f5>] ? sched_clock_local+0x15/0x80
        [<ffffffff81066c98>] ? sched_clock_cpu+0xb8/0xd0
        [<ffffffff81070730>] ? bit_waitqueue+0xb0/0xb0
        [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
        [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
        [<ffffffff8105973e>] ? kthread+0xce/0xf0
        [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
        [<ffffffff814a8b7c>] ? ret_from_fork+0x7c/0xb0
        [<ffffffff81059670>] ? 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=80931Reported-and-tested-by: NTomas Gayoso <tgayoso@gmail.com>
      Reported-and-tested-by: NChris J Arges <chris.j.arges@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0725dda2
    • S
      ALSA: echoaudio: cleanup of unnecessary messages · 9161bd0d
      Sudip Mukherjee 提交于
      commit "b5b4a41b" was dereferencing
      chip after it has been freed. This patch fixes that and at the same
      time removes some debugging messages, which are unnecessary, as they
      are just printing information about entry and exit from a function,
      and which switch-case it is executing.
      we can easily get from ftrace the information about the entry and exit
      from a function.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9161bd0d
    • T
      Merge branch 'topic/pcm-locking' into for-next · c009b7ef
      Takashi Iwai 提交于
      here is a small series of patches for cleaning up / enhancing the
      PCM core stuff.
      c009b7ef
    • H
      ALSA: hda - fix mute led problem for three HP laptops · c922c4e8
      Hui Wang 提交于
      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/1389497Tested-by: NTieFu Chen <tienfu.chen@canonical.com>
      Cc: Kailang Yang <kailang@realtek.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c922c4e8
  6. 04 11月, 2014 7 次提交
    • T
      ALSA: usb-audio: Use strim() instead of open code · ae366c20
      Takashi Iwai 提交于
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ae366c20
    • T
      ALSA: usb-audio: Pass direct struct pointer instead of list_head · a6cece9d
      Takashi Iwai 提交于
      Some functions in mixer.c and endpoint.c receive list_head instead of
      the object itself.  This is not obvious and rather error-prone.  Let's
      pass the proper object directly instead.
      
      The functions in midi.c still receive list_head and this can't be
      changed since the object definition isn't exposed to the outside of
      midi.c, so left as is.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a6cece9d
    • T
      ALSA: usb-audio: Flatten probe and disconnect functions · 4c8c3a4f
      Takashi Iwai 提交于
      The usb-audio probe and disconnect functions have been split just for
      adapting the (new!) API at 2.5 kernel time.  We left them until now,
      partly because we wanted to build with the pretty old kernels in the
      external alsa-driver tree.  But the support of such old kernels has
      been longly stopped, so it's good time to clean up this mess.
      
      One good point by this cleanup is that now the probe function returns
      a proper error code instead of only -EIO.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4c8c3a4f
    • T
      ALSA: pcm: Add xrun_injection proc entry · 2b30d411
      Takashi Iwai 提交于
      This patch adds a new proc entry for PCM substreams to inject an
      XRUN.  When a PCM substream is running and any value is written to its
      xrun_injection proc file, the driver triggers XRUN.  This is a useful
      feature for debugging XRUN and error handling code paths.
      
      Note that this entry is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is
      set.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2b30d411
    • T
      ALSA: pcm: Replace PCM hwptr tracking with tracepoints · f5914908
      Takashi Iwai 提交于
      ALSA PCM core has a mechanism tracking the PCM hwptr updates for
      analyzing XRUNs.  But its log is limited (up to 10) and its log output
      is a kernel message, which is hard to handle.
      
      In this patch, the hwptr logging is moved to the tracing
      infrastructure instead of its own.  Not only the hwptr updates but
      also XRUN and hwptr errors are recorded on the trace log, so that user
      can see such events at the exact timing.
      
      The new "snd_pcm" entry will appear in the tracing events:
        # ls -F /sys/kernel/debug/tracing/events/snd_pcm
        enable  filter  hw_ptr_error/  hwptr/  xrun/
      
      The hwptr is for the regular hwptr update events.  An event trace
      looks like:
      
        aplay-26187 [004] d..3  4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
      
      "POS" shows the hwptr update by the explicit position update call and
      "IRQ" means the hwptr update by the interrupt,
      i.e. snd_pcm_period_elapsed() call.  The "pos" is the passed
      ring-buffer offset by the caller, "old" is the previous hwptr, "base"
      is the hwptr base position, "period" and "buf" are period- and
      buffer-size of the target PCM substream.
      (Note that the hwptr position displayed here isn't the ring-buffer
       offset.  It increments up to the PCM position boundary.)
      
      The XRUN event appears similarly, but without "pos" field.
      The hwptr error events appear with the PCM identifier and its reason
      string, such as "Lost interrupt?".
      
      The XRUN and hwptr error reports on kernel message are still left, can
      be turned on/off via xrun_debug proc like before.  But the bit 3, 4, 5
      and 6 bits of xrun_debug proc are dropped by this patch.  Also, along
      with the change, the message strings have been reformatted to be a bit
      more consistent.
      
      Last but not least, the hwptr reporting is enabled only when
      CONFIG_SND_PCM_XRUN_DEBUG is set.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f5914908
    • T
      ALSA: pcm: Correct PCM BUG error message · d507941b
      Takashi Iwai 提交于
      While converting to dev_*(), the message showing the invalid PCM
      position was wrongly tagged as if an XRUN although it's actually a
      BUG.  This patch corrects the message again.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d507941b
    • O
      ALSA: es18xx: Add GPO controls · 2603fe21
      Ondrej Zary 提交于
      Add GPO0 and GPO1 (General Purpose Outputs) controls to mixer.
      These can be used on some cards to control amplifier mute (seen in ES1868
      datasheet) or additional onboard chips such as QX2130 QXpander processor.
      
      These GPOs are present on ES1868, ES1869, ES1887 and ES1888 chips.
      
      Tested on ES1868 with QX2130.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2603fe21
  7. 03 11月, 2014 3 次提交
  8. 31 10月, 2014 3 次提交
  9. 30 10月, 2014 9 次提交