- 04 Nov, 2019 1 commit
-
-
Takashi Iwai authored
The check for the mmap support via hw_support_mmap() function misses the case where the device is with SNDRV_DMA_TYPE_DEV_UC, which should have been treated equally as SNDRV_DMA_TYPE_DEV. Let's fix it. Note that this bug doesn't hit any practical problem, because SNDRV_DMA_TYPE_DEV_UC is used only for x86-specific drivers (snd-hda-intel and snd-intel8x0) for the specific platforms that need the non-cached buffers. And, on such platforms, hw_support_mmap() already returns true in anyway. That's the reason I didn't put Cc-to-stable mark here. This is only for any theoretical future extension. Fixes: 425da159 ("ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*") Fixes: 42e748a0 ("ALSA: memalloc: Add non-cached buffer type") Link: https://lore.kernel.org/r/20191104101115.27311-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 02 Nov, 2019 3 commits
-
-
Takashi Sakamoto authored
Originally BeBeB ASICs and firmware supports clock mode to synchronizing to syt field of received isoc packet. This mode is known as 'SYT Match' slightly described in IEC 61883-6 (but no detail mechanisms). In this mode, drivers can control sampling clock in device. Driver for Windows and macOS uses this feature to perform synchronization for devices on the same bus. In this mode, a plug of Music subunit for synchronization is connected to a plug of isoc unit for incoming packet streaming, then the order to establish connections is INPUT_PLUG first, OUTPUT_PLUG second. This commit implements the above. Actually each device works with its own clock for sampling, therefore the original design is hardly implemented to vendor's products. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191101131323.17300-4-o-takashi@sakamocchi.jpSigned-off-by:
-
Takashi Sakamoto authored
As long as I investigated, there's some cases about the delay for device between establishing OUTPUT_PLUG and transmitting first isoc packet. For devices which support BeBoB protocol version 1 can transmit the packet within several hundred milliseconds, while for devices which support BeBoB protocol version 3 can transmit the packet within 2 seconds. Devices with protocol version 1: * Edirol FA-66 * Yamaha GO46 * Terratec Phase x24 FW * M-Audio FireWire AudioPhile * M-Audio FireWire Solo * M-Audio FireWire 1814 * M-Audio FireWire 410 * Focusrite Saffire Pro 26 I/O Devices with protocol version 3: * M-Audio Profire Lightbridge * Behringer FCA610 * Phonic Firefly 202 At present ALSA bebob driver postpones starting IR context during 1.5 sec for all of supported devices. The delay is too long for devices with protocol version 1, while it's not enough for devices with protocol version 3. This commit improves the delay for these protocols. Signed-off-by:
-
Takashi Sakamoto authored
As long as I investigated, some devices with BeBoB protocol version 1 can be freezed during several hundreds milliseconds after breaking connections. When accessing during the freezed time, any transaction is corrupted. In the worst case, the device is going to reboot. I can see this issue in: * Roland FA-66 * M-Audio FireWire Solo This commit expands sleep just after breaking connections to avoid the freezed time as much as possible. I note that the freeze/reboot behaviour is similar to below models: * Focusrite Saffire Pro 10 I/O * Focusrite Saffire Pro 26 I/O The above models certainly reboot after breaking connections. Signed-off-by:
-
- 30 Oct, 2019 8 commits
-
-
Takashi Iwai authored
Just fix a typo of "S/PDIF" in the clock name string. Fixes: 4638ec6e ("ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats") Acked-by:
-
Takashi Sakamoto authored
UltraLite was shipped in 2005 by MOTU, and already discontinued. This model consists of below ICs: - Texus Instruments TSB41AB2 for physical layer of IEEE 1394 bus - Xilinx Spartan XC35S200 for link layer of IEEE 1394 bus, protocol layer and signal processing This commit adds support for this model. Like the other MOTU models, ALSA firewire MOTU driver fails to drive the device for stable sampling clock and generate noisy sound. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04107574 bus_info_length 4, crc_length 16, crc 30068 404 31333934 bus_name "1394" 408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4) 40c 0001f200 company_id 0001f2 | 410 0007b82d device_id 000007b82d | EUI-64 0001f2000007b82d root directory ----------------------------------------------------------------- 414 0004c65c directory_length 4, crc 50780 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 8d000006 --> eui-64 leaf at 438 424 d1000001 --> unit directory at 428 unit directory at 428 ----------------------------------------------------------------- 428 0003d80a directory_length 3, crc 55306 42c 120001f2 specifier id 430 1300000d version 434 17100800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 00024566 leaf_length 2, crc 17766 43c 0001f200 company_id 0001f2 | 440 0007b82d device_id 000007b82d | EUI-64 0001f2000007b82d Signed-off-by: -
Takashi Sakamoto authored
In MOTU FireWire series, devices which support protocol version 2 have several types of hardware design to process audio data frames for isoc packet. Roughly devices are categorized into three groups: - 828mkII - Traveler/896HD - UltraLite/8pre FireWire Some bit flags in register addressed by 0x'ffff'f000'0b14 includes device-specific effects. This commit cleanups implementation of protocol v2 in this point. Signed-off-by:
-
Takashi Sakamoto authored
This commit adds some helper functions to parse register value for source of sampling clock and nominal sampling transmission frequency. Signed-off-by:
-
Takashi Sakamoto authored
In MOTU FireWire series, devices have a mode to generate sampling clock from a sequence of source packet header (SPH) included in each data block of received packet. This mode is used for several purposes such as mode for SMPTE time code, sync to the other sound cards and so on. This commit adds support for the SPH mode. Signed-off-by:
-
Takashi Sakamoto authored
When unknown source is detected for sampling clock, corresponding label was not added for node on procfs. This commit adds it. Signed-off-by:
-
Takashi Sakamoto authored
Just replace 'SEPARETED' with 'SEPARATED' for macro. Signed-off-by:
-
Saurav Girepunje authored
Use true/false for bool type return in uac_clock_source_is_valid(). Signed-off-by:
Saurav Girepunje <saurav.girepunje@gmail.com> Link: https://lore.kernel.org/r/20191029175200.GA7320@sauravSigned-off-by:
-
- 28 Oct, 2019 4 commits
-
-
Takashi Iwai authored
The recent addition of snd_intel_dsp_driver_probe() check caused a spurious kernel warning when the driver is loaded for a non-Intel hardware due to snd_BUG_ON(). Moreover, for such a hardware, we should always return SND_INTEL_DSP_DRIVER_ANY, not check the dsp_driver option at all. This patch fixes these issues for non-Intel devices. Fixes: 82d9d54a ("ALSA: hda: add Intel DSP configuration / probe code") Signed-off-by:
-
Takashi Iwai authored
This is an alternative fix attemp for the issue reported in the commit caa8422d ("ALSA: hda: Flush interrupts on disabling") that was reverted later due to regressions. Instead of tweaking the hardware disablement order and the enforced irq flushing, do calling cancel_work_sync() of the unsol work early enough, and explicitly ignore the unsol events during the shutdown by checking the bus->shutdown flag. Fixes: caa8422d ("ALSA: hda: Flush interrupts on disabling") Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Back-merge the development process for catching up the HD-audio fix (and apply a new one on top of that). Signed-off-by: -
Takashi Iwai authored
This reverts commit caa8422d. It turned out that this commit caused a regression at shutdown / reboot, as the synchronize_irq() calls seems blocking the whole shutdown. Also another part of the change about shuffling the call order looks suspicious; the azx_stop_chip() call disables the CORB / RIRB while the others may still need the CORB/RIRB update. Since the original commit itself was a cargo-fix, let's revert the whole patch. Fixes: caa8422d ("ALSA: hda: Flush interrupts on disabling") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205333 BugLinK: https://bugs.freedesktop.org/show_bug.cgi?id=111174Signed-off-by:
-
- 26 Oct, 2019 1 commit
-
-
Takashi Sakamoto authored
A helper function of ALSA bebob driver returns negative value in a function which has a prototype to return unsigned value. This commit fixes it by changing the prototype. Fixes: eb7b3a05 ("ALSA: bebob: Add commands and connections/streams management") Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by:
-
- 25 Oct, 2019 1 commit
-
-
YueHaibing authored
platform_get_irq() will call dev_err() itself on failure, so there is no need for the driver to also do this. This is detected by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191025093905.14888-1-yuehaibing@huawei.comSigned-off-by:
-
- 24 Oct, 2019 3 commits
-
-
Aaron Ma authored
These 2 ThinkCentres installed a new realtek codec ID 0x623, it has 2 front mics with the same location on pin 0x18 and 0x19. Apply fixup ALC283_FIXUP_HEADSET_MIC to change 1 front mic location to right, then pulseaudio can handle them. One "Front Mic" and one "Mic" will be shown, and audio output works fine. Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191024114439.31522-1-aaron.ma@canonical.comSigned-off-by:
-
Kailang Yang authored
Support new codec ALC623. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/ed97b6a8bd9445ecb48bc763d9aaba7a@realtek.comSigned-off-by:
-
Justin Song authored
This patch adds native DSD support for Gustard U16/X26 USB Interface. Tested using VID and fp->dsd_raw method. Signed-off-by:
Justin Song <flyingecar@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/CA+9XP1ipsFn+r3bCBKRinQv-JrJ+EHOGBdZWZoMwxFv0R8Y1MQ@mail.gmail.comSigned-off-by:
-
- 23 Oct, 2019 3 commits
-
-
Pierre-Louis Bossart authored
Reshuffle list of devices by historical order and add correct information as needed. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20191022174313.29087-2-perex@perex.czSigned-off-by:
-
Jaroslav Kysela authored
For distributions, we need one place where we can decide which driver will be activated for the auto-configation of the Intel's HDA hardware with DSP. Actually, we cover three drivers: * Legacy HDA * Intel SST * Intel Sound Open Firmware (SOF) All those drivers registers similar PCI IDs, so the first driver probed from the PCI stack can win. But... it is not guaranteed that the correct driver wins. This commit changes Intel's NHLT ACPI module to a common DSP probe module for the Intel's hardware. All above sound drivers calls this code. The user can force another behaviour using the module parameter 'dsp_driver' located in the 'snd-intel-dspcfg' module. This change allows to add specific dmi checks for the specific systems. The examples are taken from the pull request: https://github.com/thesofproject/linux/pull/927 Tested on Lenovo Carbon X1 7th gen. Signed-off-by:
-
Pan Xiuli authored
Add HD Audio Device PCI ID for the Intel Tigerlake and Jasperlake platform. Signed-off-by:
Pan Xiuli <xiuli.pan@linux.intel.com> Signed-off-by:
-
- 22 Oct, 2019 1 commit
-
-
Takashi Iwai authored
The recently introduced USB-audio descriptor validator had a stupid copy&paste error that may lead to an unexpected overlook of too short descriptors for processing and extension units. It's likely the cause of the report triggered by syzkaller fuzzer. Let's fix it. Fixes: 57f87706 ("ALSA: usb-audio: More validations of descriptor units") Reported-by: syzbot+0620f79a1978b1133fd7@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/s5hsgnkdbsl.wl-tiwai@suse.deSigned-off-by:
-
- 21 Oct, 2019 5 commits
-
-
Takashi Iwai authored
The inline prefix was missing in the dummy function pci_pr3_present() definition. Fix it. Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 52525b7a ("PCI: Add a helper to check Power Resource Requirements _PR3 existence") Link: https://lore.kernel.org/r/201910212111.qHm6OcWx%lkp@intel.comSigned-off-by:
-
Kai-Heng Feng authored
Nvidia proprietary driver doesn't support runtime power management, so when a user only wants to use the integrated GPU, it's a common practice to let dGPU not to bind any driver, and let its upstream port to be runtime suspended. At the end of runtime suspension the port uses platform power management to disable power through _OFF method of power resource, which is listed by _PR3. After commit b516ea58 ("PCI: Enable NVIDIA HDA controllers"), when the dGPU comes with an HDA function, the HDA won't be suspended if the dGPU is unbound, so the power resource can't be turned off by its upstream port driver. Commit 37a3a98e ("ALSA: hda - Enable runtime PM only for discrete GPU") only allows HDA to be runtime suspended once GPU is bound, to keep APU's HDA working. However, HDA on dGPU isn't that useful if dGPU is not bound to any driver. So let's relax the runtime suspend requirement for dGPU's HDA function, to disable the power source to save lots of power. BugLink: https://bugs.launchpad.net/bugs/1840835 Fixes: b516ea58 ("PCI: Enable NVIDIA HDA controllers") Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20191018073848.14590-2-kai.heng.feng@canonical.comSigned-off-by:
-
Kai-Heng Feng authored
A driver may want to know the existence of _PR3, to choose different runtime suspend behavior. A user will be add in next patch. This is mostly the same as nouveau_pr3_present(). Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20191018073848.14590-1-kai.heng.feng@canonical.comSigned-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.4-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.4 A collection of fixes that have arrived since the merge window. There are a small number of core fixes here but they are smaller ones around error handling.
-
Kailang Yang authored
Support new codec ALC711. Signed-off-by:
-
- 19 Oct, 2019 6 commits
-
-
Takashi Sakamoto authored
Some devices have a quirk to postpone transmission of isoc packet for several dozen or hundred isoc cycles since configured to transmit. Furthermore, some devices have a quirk to transmit isoc packet with discontinued data of its header. In 1394 OHCI specification, software allows to start isoc context with certain isoc cycle. Linux firewire subsystem has kernel API to use it as well. This commit uses the functionality of 1394 OHCI controller to handle the quirks. At present, this feature is convenient to ALSA bebob and fireface driver. As a result, some devices can be safely handled, as long as I know: - MAudio FireWire solo - MAudio ProFire Lightbridge - MAudio FireWire 410 - Roland FA-66 Signed-off-by:
-
Takashi Sakamoto authored
This commit changes AMDTP domain to run on an IT context of 1394 OHCI as IRQ target. No hardware interrupt is scheduled for the other isoc contexts. All of the isoc context are processed in a callback for an isoc context of IRQ target. The IRQ target is automatically selected from a list of AMDTP streams, thus users of AMDTP domain should add an AMDTP stream for IT context at least. The reason to select IT context as IRQ target is that the IT context runs on local 1394 OHCI controller and it can be used as reliable, constant IRQ generator. On the other hand, IR context can include skip cycle according to isoc packet transferred by device. Signed-off-by:
-
Takashi Sakamoto authored
The aim of AMDTP domain is to process several isoc context in the same time. However, current implementation is against this idea because it flushes each isoc context in the end of processing context callback. This commit cancels it. Signed-off-by:
-
Takashi Sakamoto authored
An isoc context for AMDTP stream is flushed to queue packet by a call of pcm.ack. This commit extends this for AMDTP domain. Signed-off-by:
-
Takashi Sakamoto authored
An isoc context for AMDTP stream is flushed to queue packet by a call of pcm.pointer. This commit extends this for AMDTP domain. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to handle several IR/IT contexts in the same domain by tasklet context for one of the IT context. Such IT context is stored to AMDTP domain structure as 'irq_target'. Signed-off-by:
-
- 18 Oct, 2019 4 commits
-
-
Dragos Tarcatu authored
All the kcontrol put() functions are currently returning 0 when successful. This does not go well with alsamixer as it does not seem to get notified on SND_CTL_EVENT_MASK_VALUE callbacks when values change for (some of) the sof kcontrols. This patch fixes that by returning true for volume, switch and enum type kcontrols when values do change in put(). Signed-off-by:
Dragos Tarcatu <dragos_tarcatu@mentor.com> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Olivier Moysan authored
The commit below, adds a call to sysclk callback on shutdown. This introduces a regression in stm32 SAI driver, as some clock services are called twice, leading to unbalanced calls. Move processing related to mclk from shutdown to sysclk callback. When requested frequency is 0, assume shutdown and release mclk. Fixes: 2458adb8 ("SoC: simple-card-utils: set 0Hz to sysclk when shutdown") Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20191018082040.31022-1-olivier.moysan@st.comSigned-off-by:
-
Chuhong Yuan authored
sof_audio_probe misses a check for devm_clk_get and may cause problems. Add a check for it to fix the bug. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Acked-by:
-
Junya Monden authored
Unlike other format-related DAI parameters, rdai->bit_clk_inv flag is not properly re-initialized when setting format for new stream processing. The inversion, if requested, is then applied not to default, but to a previous value, which leads to SCKP bit in SSICR register being set incorrectly. Fix this by re-setting the flag to its initial value, determined by format. Fixes: 1a7889ca ("ASoC: rsnd: fixup SND_SOC_DAIFMT_xB_xF behavior") Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com> Cc: Jiada Wang <jiada_wang@mentor.com> Cc: Timo Wischer <twischer@de.adit-jv.com> Cc: stable@vger.kernel.org # v3.17+ Signed-off-by:
Junya Monden <jmonden@jp.adit-jv.com> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20191016124255.7442-1-erosca@de.adit-jv.comSigned-off-by:
-
