- 06 Nov, 2019 26 commits
-
-
Takashi Iwai authored
Pass the device pointer from the PCI pointer directly, instead of a non-standard macro. The macro didn't give any better readability. Also slightly refactor the code (drop the return value check from the preallocation) as it never returns an error. Link: https://lore.kernel.org/r/20191105151856.10785-21-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Pass the device pointer from the PCI pointer directly, instead of a non-standard macro. The macro didn't give any better readability. Link: https://lore.kernel.org/r/20191105151856.10785-20-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
snd_pcm_sgbuf_ops_page is no longer needed to be set explicitly to PCM page ops since the recent change in the PCM core (*). Leaving it NULL should work as long as the preallocation has been done properly. This patch drops the redundant lines. (*) 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-19-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-18-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Since the driver requires the DMA32 allocation, it passes the specially encoded device to snd_pcm_lib_preallocate_pages(). Link: https://lore.kernel.org/r/20191105151856.10785-17-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Since the driver requires the DMA32 allocation, it passes the specially encoded device to snd_pcm_lib_preallocate_pages(). Link: https://lore.kernel.org/r/20191105151856.10785-16-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-15-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-14-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-13-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-12-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-10-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae3: ALSA: pcm: Handle special page mapping in the default mmap handler Also, since the SG-buffer-specific PCM ops becomes identical with the normal PCM ops, unify them again to the single ops, too. Link: https://lore.kernel.org/r/20191105151856.10785-9-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
A few error handling code was forgotten where it never reaches. Drop it. Link: https://lore.kernel.org/r/20191105151856.10785-8-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-7-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-6-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-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 1 commit
-
-
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:
-
