summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)AuthorFilesLines
2017-06-28ASoC: Drop invalid DMI fields when setting card long name from DMI infoMengdong Lin1-4/+35
Sometimes DMI fields may be invalid and so can't give useful vendor, product or board info, such as "Type2 - Board Manufacturer" or "Type1 - TBD by OEM". Including such invalid DMI fileds may create silly card long name. So this patch creates a black list of invalid strings. And if a DMI field contains any string in this list, it will be excluded from the card long name. Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28ASoC: stm32: sai: remove some stray tabsDan Carpenter1-1/+1
This line was accidentally indented too far. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28ASoC: rt5645: del btn_check_timer on removeHans de Goede1-0/+1
The timer may still be running when rt5645_i2c_remove() gets called, call del_timer_sync() to make sure it is stopped. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28ASoC: rt5645: Add jack detection workaround for GPD WinTakashi Iwai1-0/+29
GPD Win requires jd_mode=3 and the inverted flag for making the jack detection working. Unfortunately, the BIOS doesn't give a nice way to match with DMI strings, and the only working way so far is to match with the board vendor/name/version/date to some known patterns. Hopefully other vendors won't do such a stupid setup, too... Thanks to Hans de Goede for the DMI matching suggestion. Suggested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28ASoC: rt5645: add inv_jd1_1 flagBard Liao1-0/+4
The flag will invert jd1_1 status. Which will be used if the jack connector is normal closed. Signed-off-by: Bard Liao <bardliao@realtek.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28ASoC: rt5645: rename jd_invert flag in platform dataBard Liao1-4/+4
The jd_invert flag is actually used for level triggered IRQ. Rename it to let code more readable. Signed-off-by: Bard Liao <bardliao@realtek.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28ASoC: rt5645: read jd1_1 status for jd detectionBard Liao1-23/+8
Read the jd status after invert control. The benefit is we don't need to invert the reading jd status when jd invert is needed. Signed-off-by: Bard Liao <bardliao@realtek.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-28Merge branch 'topic/hda-fix' into for-nextTakashi Iwai5-76/+67
2017-06-28ALSA: hda - Minor code refactoring for Intel HDMI codec parsersTakashi Iwai1-53/+34
No functional change, just a slight reduction of lines. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-28ALSA: hda - Bind with i915 component before codec bindingTakashi Iwai2-26/+26
We used a on-demand i915 component binding for IvyBridge and SandyBridge HDMI codecs, but it has a potential problem of the nested module loading. For avoiding that situation, assure the i915 binding happening at the controller driver level for PCH controller devices, where the initialization is performed in a detached work, instead of calling from the codec driver probe. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-28ALSA: hda - Skip card registration when no codec is foundTakashi Iwai1-0/+3
It's nonsense to register a card object when no codec is bound on it, as we don't support the deferred codec binding. Instead of registering an empty card object, just skip the registration by returning an error from azx_codec_configure(). Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-28ALSA: hda - Fix endless loop of codec configureTakashi Iwai2-2/+8
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 <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-28ALSA: Fix forgotten dependency fix for tristate OSS sequencer kconfigTakashi Iwai2-2/+6
In the commit 3d774d5ef066 ("ALSA: seq: Allow the tristate build of OSS emulation") we changed CONFIG_SND_SEQUENCER_OSS to tristate, but a couple of places were forgotten, namely, opl3 and emux Makefile. These contain the line like snd-opl3-synth-$(CONFIG_SND_SEQUENCER_OSS) += opl3_oss.o and this doesn't work any longer as expected because snd-opl3-synth can be built-in while CONFIG_SND_SEQUENCER_OSS=m. This patch fixes these places to build properly for the new kconfig dependency. In the end, we had to use ifneq() to satisfy the requirement. It's a bit ugly, but lesser evil. Fixes: 3d774d5ef066 ("ALSA: seq: Allow the tristate build of OSS emulation") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-28ALSA: hda - set input_path bitmap to zero after moving it to new placeHui Wang1-0/+1
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: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-27ALSA: pcm: Disable only control mmap for explicit appl_ptr syncTakashi Iwai1-5/+17
Now that user-space (typically alsa-lib) can specify which protocol version it supports, we can optimize the kernel code depending on the reported protocol version. In this patch, we change the previous hack for enforcing the appl_ptr sync by disabling status/control mmap. Instead of forcibly disabling both mmaps, we disable only the control mmap when user-space declares the supported protocol version new enough. For older user-space, still both PCM status and control mmaps are disabled when requested by the driver due to the compatibility reason. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-27ALSA: pcm: Add an ioctl to specify the supported protocol versionTakashi Iwai2-0/+8
We have an ioctl to inform the PCM protocol version the running kernel supports, but there is no way to know which protocol version the user-space can understand. This lack of information caused headaches in the past when we tried to extend the ABI. For example, because we couldn't guarantee the validity of the reserved bytes, we had to introduce a new ioctl SNDRV_PCM_IOCTL_STATUS_EXT for assigning a few new fields in the formerly reserved bits. If we could know that it's a new alsa-lib, we could assume the availability of the new fields, thus we could have reused the existing SNDRV_PCM_IOCTL_STATUS. In order to improve the ABI extensibility, this patch adds a new ioctl for user-space to inform its supporting protocol version to the kernel. By reporting the supported protocol from user-space, the kernel can judge which feature should be provided and which not. With the addition of the new ioctl, the PCM protocol version is bumped to 2.0.14, too. User-space checks the kernel protocol version via SNDRV_PCM_INFO_PVERSION, then it sets the supported version back via SNDRV_PCM_INFO_USER_PVERSION. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-27Backmerge tag 'v4.12-rc7' into drm-nextDave Airlie4-8/+17
Linux 4.12-rc7 Needed at least rc6 for drm-misc-next-fixes, may as well go to rc7
2017-06-26ALSA: hda/realtek - There is no loopback mixer in the ALC234/274/294Hui Wang1-0/+1
We have a Lenovo machine with the codec ALC294 on it, without the patch, the Node 0x0b is regarded as the loopback mixer, but the Node 0x0b in this codec is "Vendor Defined Widget" instead of the audio mixer, please see the log below: Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono Control: name="Beep Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 And I have consulted with Realtek, so far the ALC234/274/294 all don't have loopback mixer. Cc: Kailang Yang <kailang@realtek.com> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-24Merge branch 'linus' into sched/core, to pick up fixesIngo Molnar4-8/+17
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-23ALSA: pcm: Add the explicit appl_ptr sync supportTakashi Iwai1-2/+21
Currently x86 platforms use the PCM status/control mmaps for transferring the PCM status and appl_ptr between kernel and user-spaces. The mmap is a most efficient way of communication, but it has a drawback per its nature, namely, it can't notify the change explicitly to kernel. The lack of appl_ptr update notification is a problem on a few existing drivers, but it's mostly a small issue and negligible. However, a new type of driver that uses DSP for a deep buffer management requires the exact position of appl_ptr for calculating the buffer prefetch size, and the asynchronous appl_ptr update between kernel and user-spaces becomes a significant problem for it. How can we enforce user-space to report the appl_ptr update? The way is relatively simple. Just by disabling the PCM control mmap, the user-space is supposed to fall back to the mode using SYNC_PTR ioctl, and the kernel gets control over that. This fallback mode is used in all non-x86 platforms as default, and also in the 32bit compatible model on all platforms including x86. It's been implemented already over a decade, so we can say it's fairly safe and stably working. With the help of the knowledge above, this patch introduces a new PCM info flag SNDRV_PCM_INFO_SYNC_APPLPTR for achieving the appl_ptr sync from user-space. When a driver sets this flag at open, the PCM status / control mmap is disabled, which effectively switches to SYNC_PTR mode in user-space side. In this version, both PCM status and control mmaps are disabled although only the latter, control mmap, is the target. It's because the current alsa-lib implementation supposes that both status and control mmaps are always coupled, thus it handles a fatal error when only one of them fails. Of course, the disablement of the status/control mmaps may bring a slight performance overhead. Thus, as of now, this should be used only for the dedicated devices that deserves. Note that the disablement of mmap is a sort of workaround. In the later patch, we'll introduce the way to identify the protocol version alsa-lib supports, and keep mmap working while the sync_ptr is performed together. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-23ASoC: audio-graph-scu-card: support 2nd codec endpoint on DTKuninori Morimoto1-3/+25
audio-graph-scu-card can handle below connection which is mainly for sound mixing purpose. +----------+ +-------+ | CPU0--+--|-->| Codec | | | | +-------+ | CPU1--+ | +----------+ >From OF-graph point of view, it should have CPU0 <-> Codec, and CPU1 <-> Codec on DT. But current driver doesn't care about 2nd connection of Codec, because it is dummy from DPCM point of view. This patch can care 2nd Codec connection, and it should be supported from OF-graph point of view. It still have backward compatibility. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-23ASoC: audio-graph-scu-card: tidyup asoc_simple_card_canonicalize_cpu() parameterKuninori Morimoto1-1/+1
asoc_simple_card_canonicalize_cpu() 2nd param is asking CPU component's DAI links, not Card links. This patch fixup it. Otherwise, audio-graph-card can't handle CPU component correctly if CPU has mult-DAIs and Card uses only one of them Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-23ASoC: audio-graph-card: tidyup asoc_simple_card_canonicalize_cpu() parameterKuninori Morimoto1-2/+1
asoc_simple_card_canonicalize_cpu() 2nd param is asking CPU component's DAI links, not Card links. This patch fixup it. Otherwise, audio-graph-card can't handle CPU component correctly if CPU has mult-DAIs and Card uses only one of them Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-23ASoC: nau8825: make crosstalk function optionalJohn Hsu2-1/+6
Make crosstalk functoin optional. The jack detection can speed up without crosstalk detection. Let the decision of function usage to platform design. The patch helps the issue concern as follows: Google issue 35574278: Chell_headphone pop back from S3 There is a concern as follows: cras getting blocked for 2 seconds (worst-case 3 seconds) As I understand, ChromeOS expects resume finishes in 1 seconds. Video/Audio playing after 3 seconds of resume seems against the spec. If we really have to make the choice I would choose pop noise instead of waiting for 3 seconds. Signed-off-by: John Hsu <KCHSU0@nuvoton.com> Signed-off-by: John Hsu <supercraig0719@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-23ASoC: nau8825: fix jack type detection issue after resumeJohn Hsu1-1/+16
Fix the issue that mic type detection error after resume. The microphone type detection procedure will recognize testing signal on JKSLV pin, but before the procedure, JKSLV already had supply voltage, that results in the failure. Therefore, the patch turns off the power and reset the jack type configuration before suspend. Then redo the jack detection procedure after resume. The patch help to fix the issue as follows: Google issue 37973093: CTIA/OMTP jack type detection failure after resume Reported Issue Chrome OS Version : ChromeOS R59-9460.13.0 Type of hardware : DVT sample What steps will reproduce the problem? (1 Play a music (2 Insert a headphones (3 Close laptop lid 3 sec then open it What is the expected output? The music is normal in the headphones. What do you see instead? Singer voice in the music is not clear. How frequently does this problem reproduce? Always What is the impact to the user, and is there a workaround? If so, what is it? Re-insert the headset or close the laptop lid and then open it again can be repaired. Signed-off-by: John Hsu <KCHSU0@nuvoton.com> Signed-off-by: John Hsu <supercraig0719@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-23ASoC: nau8825: default value for propertyJohn Hsu1-12/+41
Assign default value for codec private data when property not given. If without those default value and property, the codec will work abnormally. Signed-off-by: John Hsu <KCHSU0@nuvoton.com> Signed-off-by: John Hsu <supercraig0719@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-23ASoC: zx_aud96p22: add ZTE ZX AUD96P22 codec driverBaoyou Xie3-0/+410
It adds ASoC driver for AUD96P22 stereo audio codec integrated on ZTE ZX family SoCs. The driver includes the support for a number of volume and mute controls, and power bits for various playback and recording components. Due to that the board for testing only supports playback, recording support is untested. Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-22ASoC: es8316: add I2C dependencyArnd Bergmann1-0/+1
Without CONFIG_I2C, we get a build failure: sound/soc/codecs/es8316.c:633:1: error: data definition has no type or storage class [-Werror] sound/soc/codecs/es8316.c:633:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int] sound/soc/codecs/es8316.c:633:1: error: parameter names (without types) in function declaration [-Werror] sound/soc/codecs/es8316.c:623:26: error: 'es8316_i2c_driver' defined but not used [-Werror=unused-variable] This adds the required Kconfig dependency. Fixes: b8b88b70875a ("ASoC: add es8316 codec driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-22ASoC: max9867: make array ni_div static constColin Ian King1-1/+1
The array ni_div does not need to be in global scope and is not modified, so make it static const. Cleans up sparse warning: "symbol 'ni_div' was not declared. Should it be static?" Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-By: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-21ASoC: rsnd: fixup unsigned expression compared with zero: main_rateKuninori Morimoto3-6/+6
This patch fixes this WARNING sound/soc/sh/rcar/ssi.c:285:5-14: WARNING: Unsigned expression\ compared with zero: main_rate < 0 Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-21ASoC: stm32: Add SPDIFRX supportolivier moysan3-0/+1012
Add SPDIFRX support to STM32. Signed-off-by: olivier moysan <olivier.moysan@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-21ASoC: pxa: add COMPILE_TEST on SND_PXA2XX_SOCKuninori Morimoto1-1/+1
It doesn't use asm header. We can add COMPILE_TEST Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-21ASoC: fsl: mpc5200_dma: remove unused psc_dmaKuninori Morimoto1-1/+0
linux/sound/soc/fsl/mpc5200_dma.c:305:18: warning: unused variable \ psc_dma’ [-Wunused-variable] Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-21ALSA: hda/realtek - Add default procedure for suspend and resume stateKailang Yang1-1/+64
Except ALC269. This will reduce pop noise from headset or headphone. If codec enter to power save state, when plug headset or headphone.... It has a chance to cut off power by system. Our new codec use this procedure will be more stable during suspend and resume state. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20sched/wait: Rename wait_queue_t => wait_queue_entry_tIngo Molnar13-19/+19
Rename: wait_queue_t => wait_queue_entry_t 'wait_queue_t' was always a slight misnomer: its name implies that it's a "queue", but in reality it's a queue *entry*. The 'real' queue is the wait queue head, which had to carry the name. Start sorting this out by renaming it to 'wait_queue_entry_t'. This also allows the real structure name 'struct __wait_queue' to lose its double underscore and become 'struct wait_queue_entry', which is the more canonical nomenclature for such data types. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20ALSA: hda/realtek - Support headset mode for ALC234/ALC274/ALC294Kailang Yang1-1/+67
This patch will enable headset mode for ALC234/ALC274/ALC294 platform. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20ALSA: pcm: Fix possible inconsistent appl_ptr update via mmapTakashi Iwai1-6/+7
The ALSA PCM core refers to the appl_ptr value stored on the mmapped page that is shared between kernel and user-space. Although the reference is performed in the PCM stream lock, it doesn't guarantee the atomic access when the value gets updated concurrently from the user-space on another CPU. In most of codes, this is no big problem, but still there are a few places that may result in slight inconsistencies because they access runtime->control->appl_ptr multiple times; that is, the second read might be a different value from the first value. It can be even backward or jumping, as we have no control for it. Hence, the calculation may give an unexpected value. Luckily, there is no security vulnerability by that, as far as I've checked. But still we should address it. This patch tries to reduce such possible cases. The fix is simple -- we just read once, store it to a local variable and use it for the rest calculations. The READ_ONCE() macro is used for it in order to avoid the ill-effect by possible compiler optimizations. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20ALSA: hda: Fix potential race at unregistration and unsol eventsTakashi Iwai2-0/+2
When the codec device is unregistered / freed, it may release the resource while being used in an unsolicited event like the jack detection work. This leads to use-after-free. The fix here is to unregister the device at first, i.e. removing the codec from the list, then flushing the pending works to assure that all unsol events are gone. After this point, we're free from accessing the codec via unsol events, thus can release the resources gracefully. The issue was spotted originally by Intel CI, but it couldn't be reproduced reliably by its nature. So let's hope this fix really addresses the whole issues. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196045 Reported-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20ALSA: hda - Add AZX_DRIVER_SKL for simplificationTakashi Iwai1-26/+21
We checked the quirks specific to the recent Intel chips by checking the PCI IDs manually, but it's becoming messy with lots of IS_SKL() and other macros, as the amount accumulated. For simplification, here the new AZX_DRIVER_SKL type is introduced, and check chip->driver_type instead of the manual PCI ID. The short name for this is still "HDA Intel PCH", so that it doesn't break the existing user-space unnecessarily. Suggested-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20Merge branch 'for-linus' into for-nextTakashi Iwai4-8/+17
2017-06-20ALSA: hda - Apply quirks to Broxton-T, tooTakashi Iwai1-3/+4
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: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20ALSA: line6: remove unnecessary initialization to PODHD500XHans P. Möller Ebner2-4/+8
Remove Initialization from POD HD500X because it's not needed. Every time the device is connected dmesg gives the following output: "receive length failed (error -11)". To solve this problem, another flags is introduced (LINE6_CAP_CONTROL_INFO) and it is only used for PODX3 in: sysfs entries, call podhd_startup_finalize(pod) and disconnection. With this patch the error disappear. Signed-off-by: Hans P. Moller <hmoller@uc.cl> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-20ALSA: line6: add support for POD HD500XHans P. Möller Ebner1-1/+16
Add support for the Line6 POD HD500X multi effect processor for playback and capture (in/out audio) through USB. Signed-off-by: Hans P. Moller <hmoller@uc.cl> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-19ASoC: zx-i2s: flip I2S master/slave modeShawn Guo1-4/+6
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 <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2017-06-19ASoC: compress: Derive substream from stream based on directionSatish Babu Patakokila1-2/+4
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 <sbpata@codeaurora.org> Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org> Acked-By: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2017-06-19ALSA: firewire-lib: Fix stall of process context at packet errorTakashi Sakamoto2-3/+7
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 <clemens@ladisch.de> Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position") Cc: <stable@vger.kernel.org> # 4.9+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-19ASoC: Intel: bxt: Move codec sysclk config to codec_init functionAdam Thomson1-5/+9
The MCLK for DA7219 does not change in this platform, but is currently being configured everytime as part of the platform_clock event handler for DAPM. The upshot of this is that we have unnecessary calls to this function, and it also means that if a stream hasn't yet been started, DA7219 driver does not have the correct MCLK rates programmed and so the HP detection feature does not operate as expected. This patch rectifies this issue by moving the sysclk call to codec_init function so it's only called once at initialisation. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-19ASoC: da7219: Fix HP detection procedure for all MCLK frequenciesAdam Thomson3-25/+64
Currently when HP detection procedure runs for certain MCLK frequencies, when PLL is bypassed, the procedure will incorrectly report Lineout instead of Headphones due to timing incosistencies. To avoid this problem, the PLL is temporarily enabled (if currently bypassed and MCLK present) to provide consistent timings for the procedure, regardless of MCLK frequency. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-19ASoC: skl_rt286: Add deepbuffer dai linkSubhransu S. Prusty1-0/+18
This patch adds the deepbuffer device which can be opened with a bigger buffer size. The application can disable interrupts and sleep for longer duration. Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> Acked-By: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-19ASoC: Intel: Skylake: Fix dma buffer size calculationRamesh Babu1-4/+25
DMA buffer size for gateway copier will be calculated based on: For host DMA copier: Input buffer size (ibs) for output direction (playback) Output buffer size (obs) for input direction (capture) For link DMA copier: IBS for input direction (capture) OBS for output direction (playback) Update the driver to use the above. Signed-off-by: Ramesh Babu <ramesh.babu@intel.com> Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> Acked-By: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>