linux-stable.git/sound, branch v4.12.4

ASoC: atmel: tse850: fix off-by-one in the "ANA" enumeration count

2017-07-27T22:10:06+00:00

commit a00cebf51d5ceed8ba9f6fac5fb189b38cd5a7c2 upstream.

At some point I added the "Low" entry at the beginning of the array
without bumping the enumeration count from 9 to 10. Fix this. While at
it, fix the anti-pattern for the other enumeration (used by MUX{1,2}).

Fixes: aa43112445f0 ("ASoC: atmel: tse850: add ASoC driver for the Axentia TSE-850")
Signed-off-by: Peter Rosin 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: compress: Derive substream from stream based on direction

2017-07-27T22:10:06+00:00

commit 01b8cedfd0422326caae308641dcadaa85e0ca72 upstream.

Currently compress driver hardcodes direction as playback to get
substream from the stream. This results in getting the incorrect
substream for compressed capture usecase.
To fix this, remove the hardcoding and derive substream based on
the stream direction.

Signed-off-by: Satish Babu Patakokila 
Signed-off-by: Banajit Goswami 
Acked-By: Vinod Koul 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: zx-i2s: flip I2S master/slave mode

2017-07-27T22:10:06+00:00

commit a205c159f9e2db586a5ea475f4d22fa22e78fed8 upstream.

The SND_SOC_DAIFMT_MASTER bits are defined to specify the master/slave
mode for Codec, not I2S.  So the I2S master/slave mode should be flipped
according to SND_SOC_DAIFMT_MASTER bits.

Signed-off-by: Shawn Guo 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek - change the location for one of two front microphones

2017-07-21T04:59:13+00:00

commit f33f79f3d0e5caf04dd889cd7cf636261970f009 upstream.

On this Lenovo machine, there are two front mics, and both of them are
assigned the same name "Mic", but pulseaudio can't support two mics
with the same name, as a workaround, we change the location for one of
them, then the driver will assign "Front Mic" and "Mic" for them.

Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown

2017-07-21T04:59:12+00:00

commit 8d5c30308d7c5a17db96fa5452c0232f633377c2 upstream.

Clear the notify function pointer in the platform data before we tear
down the driver. Otherwise i915 would end up calling a stale function
pointer and possibly explode.

Cc: Takashi Iwai 
Cc: Pierre-Louis Bossart 
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-3-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Fix endless loop of codec configure

2017-06-28T10:10:05+00:00

azx_codec_configure() loops over the codecs found on the given
controller via a linked list.  The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.

The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus.  Since the list is initialized via list_del_init(), the
next object points to the same device itself.  This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.

For fixing this bug, just use a *_safe() version of list iteration.

Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: hda - set input_path bitmap to zero after moving it to new place

2017-06-28T05:09:19+00:00

Recently we met a problem, the codec has valid adcs and input pins,
and they can form valid input paths, but the driver does not build
valid controls for them like "Mic boost", "Capture Volume" and
"Capture Switch".

Through debugging, I found the driver needs to shrink the invalid
adcs and input paths for this machine, so it will move the whole
column bitmap value to the previous column, after moving it, the
driver forgets to set the original column bitmap value to zero, as a
result, the driver will invalidate the path whose index value is the
original colume bitmap value. After executing this function, all
valid input paths are invalidated by a mistake, there are no any
valid input paths, so the driver won't build controls for them.

Fixes: 3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Cc: 
Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai

ALSA: hda - Apply quirks to Broxton-T, too

2017-06-20T05:52:49+00:00

Broxton-T was a forgotten child and we didn't apply the quirks for
Skylake+ properly.  Meanwhile, a quirk for reducing the DMA latency
seems specific to the early Broxton model, so we leave as is.

Cc: 
Signed-off-by: Takashi Iwai

ALSA: firewire-lib: Fix stall of process context at packet error

2017-06-19T15:47:18+00:00

At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).

ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
->snd_pcm_common_ioctl1()
  ->snd_pcm_hwsync()
    ->snd_pcm_stream_lock_irq
    (sound/core/pcm_lib.c)
    ->snd_pcm_update_hw_ptr()
      ->snd_pcm_udpate_hw_ptr0()
        ->struct snd_pcm_ops.pointer()
        (sound/firewire/*)
        = Each handler on drivers in ALSA firewire stack
          (sound/firewire/amdtp-stream.c)
          ->amdtp_stream_pcm_pointer()
            (drivers/firewire/core-iso.c)
            ->fw_iso_context_flush_completions()
              ->struct fw_card_driver.flush_iso_completion()
              (drivers/firewire/ohci.c)
              = flush_iso_completions()
                ->struct fw_iso_context.callback.sc
                (sound/firewire/amdtp-stream.c)
                = in_stream_callback() or out_stream_callback()
                  ->...
    ->snd_pcm_stream_unlock_irq

When packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.

(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
->amdtp_stream_pcm_abort()
  ->snd_pcm_stop_xrun()
    ->snd_pcm_stream_lock_irqsave()
    ->snd_pcm_stop()
    ->snd_pcm_stream_unlock_irqrestore()

The process is stalled on the CPU due to attempt to acquire recursive lock.

[  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[  562.630866] Task dump for CPU 2:
[  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
[  562.630870] Call Trace:
[  562.630876]  ? vt_console_print+0x79/0x3e0
[  562.630880]  ? msg_print_text+0x9d/0x100
[  562.630883]  ? up+0x32/0x50
[  562.630885]  ? irq_work_queue+0x8d/0xa0
[  562.630886]  ? console_unlock+0x2b6/0x4b0
[  562.630888]  ? vprintk_emit+0x312/0x4a0
[  562.630892]  ? dev_vprintk_emit+0xbf/0x230
[  562.630895]  ? do_sys_poll+0x37a/0x550
[  562.630897]  ? dev_printk_emit+0x4e/0x70
[  562.630900]  ? __dev_printk+0x3c/0x80
[  562.630903]  ? _raw_spin_lock+0x20/0x30
[  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[  562.630945]  ? poll_select_copy_remaining+0x150/0x150
[  562.630947]  ? poll_select_copy_remaining+0x150/0x150
[  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[  562.630962]  ? futex_wake+0x90/0x170
[  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[  562.630972]  ? do_vfs_ioctl+0xa3/0x610
[  562.630974]  ? vfs_read+0x11b/0x130
[  562.630976]  ? SyS_ioctl+0x79/0x90
[  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad

This commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.

Suggested-by: Clemens Ladisch 
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Cc:  # 4.9+
Signed-off-by: Takashi Sakamoto 
Signed-off-by: Takashi Iwai

ALSA: pcm: Don't treat NULL chmap as a fatal error

2017-06-14T14:20:32+00:00

The standard PCM chmap helper callbacks treat the NULL info->chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
always static and non-NULL.  But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected.  The user still sees the kernel
warning unnecessarily.

For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.

Cc:  # v4.11+
Signed-off-by: Takashi Iwai