- 06 Nov, 2019 11 commits
-
-
Takashi Iwai authored
The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation helper accepting NULL as the device pointer for the default usage. Drop the snd_dma_continuous_data() usage that became superfluous from the callers. Link: https://lore.kernel.org/r/20191105151856.10785-6-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation helper accepting NULL as the device pointer for the default usage. Drop the snd_dma_continuous_data() usage that became superfluous from the callers. Link: https://lore.kernel.org/r/20191105151856.10785-5-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation helper accepting NULL as the device pointer for the default usage. Drop the snd_dma_continuous_data() usage that became superfluous from the callers. Link: https://lore.kernel.org/r/20191105151856.10785-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation helper accepting NULL as the device pointer for the default usage. Drop the snd_dma_continuous_data() usage that became superfluous from the callers. Link: https://lore.kernel.org/r/20191105151856.10785-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation helper accepting NULL as the device pointer for the default usage. Drop the snd_dma_continuous_data() usage that became superfluous from the callers. Link: https://lore.kernel.org/r/20191105151856.10785-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
It makes little sense to create prealloc proc files for streams that have the zero max size, which is a typical case for vmalloc buffers. Skip the proc file creations to save resources in such a case. Link: https://lore.kernel.org/r/20191105191007.18150-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Warn if snd_pcm_lib_preallocate_pages*() is applied to the stream that has already the preallocated buffers and skip the allocation. It's a clearly a driver bug. Link: https://lore.kernel.org/r/20191105191007.18150-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent changes simplified the required setup for SG- and vmalloc- buffers. Update the documentation accordingly. Link: https://lore.kernel.org/r/20191105080138.1260-5-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
When a driver needs to deal with a special buffer like a SG or a vmalloc buffer, it has to set up the PCM page ops explicitly for the corresponding helper function. This is rather error-prone and many people forgot or incorrectly used it. For simplifying the call patterns and avoiding such a potential bug, this patch enhances the PCM default mmap handler to check the (pre-)allocated buffer type and handles the page gracefully depending on the buffer type. If the PCM page ops is given, the ops is still used in a higher priority. The new code path is only for the default (NULL page ops) case. Link: https://lore.kernel.org/r/20191105080138.1260-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
This patch adds the vmalloc buffer support to ALSA memalloc core. A new type, SNDRV_DMA_TYPE_VMALLOC was added. The vmalloc buffer has been already supported in the PCM via a few own helper functions, but the user sometimes get confused and misuse them. With this patch, the whole buffer management is integrated into the memalloc core, so they can be used in a sole common way. Link: https://lore.kernel.org/r/20191105080138.1260-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Currently we pass the artificial device pointer to the allocation helper in the case of SNDRV_DMA_TYPE_CONTINUOUS for passing the GFP flags. But all common cases are the allocations with GFP_KERNEL, and it's messy to put this in each place. In this patch, the memalloc core helper is changed to accept the NULL device pointer and it treats as the default mode, GFP_KERNEL, so that all callers can omit the complex argument but just leave NULL. Link: https://lore.kernel.org/r/20191105080138.1260-2-tiwai@suse.deSigned-off-by:
-
- 05 Nov, 2019 1 commit
-
-
Takashi Iwai authored
Since we apply the own mutex (bus->cmd_mutex) in HDA core side, the internal locking in regmap is superfluous. This patch adds the flag to indicate that. Also, an infamous side-effect by this change is that it disables the regmap debugfs, too, and this is seen rather good; the regmap debugfs isn't quite useful for HD-audio as it provides the very sparse registers and its debugfs access tends to lead to the way too high resource usages or sometimes hang up. So it'd be rather safe to disable it altogether. Link: https://lore.kernel.org/r/2029139028.10333037.1572874551626.JavaMail.zimbra@redhat.com Link: https://lore.kernel.org/r/20191105081806.4896-1-tiwai@suse.deSigned-off-by:
-
- 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:
-
- 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 3 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:
-
