user/sven/linux.git/include/sound, branch v5.5.14

ALSA: rawmidi: Avoid bit fields for state flags

2020-02-28T16:23:44Z

commit dfa9a5efe8b932a84b3b319250aa3ac60c20f876 upstream. The rawmidi state flags (opened, append, active_sensing) are stored in bit fields that can be potentially racy when concurrently accessed without any locks. Although the current code should be fine, there is also no any real benefit by keeping the bitfields for this kind of short number of members. This patch changes those bit fields flags to the simple bool fields. There should be no size increase of the snd_rawmidi_substream by this change. Reported-by: syzbot+576cc007eb9f2c968200@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200214111316.26939-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: hda: Apply aligned MMIO access only conditionally

2020-02-11T12:36:45Z

commit 4d024fe8f806e20e577cc934204c5784c7063293 upstream. It turned out that the recent simplification of HD-audio bus access helpers caused a regression on the virtual HD-audio device on QEMU with ARM platforms. The driver got a CORB/RIRB timeout and couldn't probe any codecs. The essential difference that caused a problem was the enforced aligned MMIO accesses by simplification. Since snd-hda-tegra driver is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes the all HD-audio drivers using the aligned MMIO accesses. While this is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM gets broken by this access pattern. For addressing the regression, this patch introduces a new flag, aligned_mmio, to hdac_bus object, and applies the aligned MMIO only when this flag is set. This change affects only platforms with CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms. Unfortunately the patch became a big bigger than it should be, just because the former calls didn't take hdac_bus object in the argument, hence we had to extend the call patterns. Fixes: 19abfefd4c76 ("ALSA: hda: Direct MMIO accesses") BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152 Cc: Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

Merge tag 'asoc-fix-v5.5-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2019-12-17T13:18:32Z

ASoC: Fixes for v5.5 A collection of fixes since the merge window, mostly driver specific but there's a few in the core that clean up fallout from the refactorings done in the last cycle.

ASoC: core: Init pcm runtime work early to avoid warnings

2019-12-04T11:15:30Z

There are cases where we fail before we reach soc_new_pcm which would init the workqueue. When we fail we attempt to flush the queue which generates warnings from the workqueue subsystem when we have not inited the queue. Solution is to use a proxy function to get around this issue. Signed-off-by: Curtis Malainey Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20191203173007.46504-1-cujomalainey@chromium.org Signed-off-by: Mark Brown

ALSA: hda: Modify stream stripe mask only when needed

2019-12-03T06:46:30Z

The recent commit in HD-audio stream management for changing the stripe control seems causing a regression on some platforms. The stripe control is currently used only by HDMI codec, and applying the stripe mask unconditionally may lead to scratchy and static noises as seen on some MacBooks. For addressing the regression, this patch changes the stream management code to apply the stripe mask conditionally only when the codec driver requested. Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477 Tested-by: Michael Pobega Cc: Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.de Signed-off-by: Takashi Iwai

Merge tag 'asoc-v5.5-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2019-11-25T13:27:41Z

ASoC: More updates for v5.5 Some more development work for v5.5. Highlights include: - More cleanups from Morimoto-san. - Trigger word detection for RT5677. Signed-off-by: Takashi Iwai

Merge branch 'asoc-5.5' into asoc-next

2019-11-22T19:56:02Z

ASoC: component: Add sync_stop PCM ops

2019-11-22T13:38:01Z

Add the support of the new PCM sync_stop ops in ASoC component. It's optional and can be NULL unless you need the sync operation. Acked-by: Mark Brown Link: https://lore.kernel.org/r/20191121190709.29121-3-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: Add card sync_irq field

2019-11-20T18:39:54Z

Many PCI and other drivers performs snd_pcm_period_elapsed() simply in its interrupt handler, so the sync_stop operation is just to call synchronize_irq(). Instead of putting this call multiple times, introduce the common card->sync_irq field. When this field is set, PCM core performs synchronize_irq() for sync-stop operation. Each driver just needs to copy its local IRQ number to card->sync_irq, and that's all we need. Link: https://lore.kernel.org/r/20191117085308.23915-8-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: pcm: Add the support for sync-stop operation

2019-11-20T18:39:54Z

The standard programming model of a PCM sound driver is to process snd_pcm_period_elapsed() from an interrupt handler. When a running stream is stopped, PCM core calls the trigger-STOP PCM ops, sets the stream state to SETUP, and moves on to the next step. This is performed in an atomic manner -- this could be called from the interrupt context, after all. The problem is that, if the stream goes further and reaches to the CLOSE state immediately, the stream might be still being processed in snd_pcm_period_elapsed() in the interrupt context, and hits a NULL dereference. Such a crash happens because of the atomic operation, and we can't wait until the stream-stop finishes. For addressing such a problem, this commit adds a new PCM ops, sync_stop. This gets called at the appropriate places that need a sync with the stream-stop, i.e. at hw_params, prepare and hw_free. Some drivers already have a similar mechanism implemented locally, and we'll refactor the code later. Link: https://lore.kernel.org/r/20191117085308.23915-7-tiwai@suse.de Signed-off-by: Takashi Iwai