summaryrefslogtreecommitdiff
path: root/sound/firewire
AgeCommit message (Collapse)Author
2020-01-20Merge branch 'for-linus' into for-nextTakashi Iwai
Resolved the merge conflict in HD-audio Tegra driver. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: dice: add support for Alesis MasterControlTakashi Sakamoto
Alesis MasterControl was shipped 2009 and already discontinued. This model consists of: * TSB41AB2 for physical layer of IEEE 1394 * WaveFront Dice II STD for link layer and protocol implementation * FreeScale DSPB56374AE Although the firmware of this model can respond against read transaction to address space for TCAT extension protocol, the content is not valid for protocol extension. This results in sound card without any PCM/MIDI interfaces. $ ./firewire-request /dev/fw1 read 0xffffe0200000 0x48 result: 000: 00 00 00 20 00 00 04 94 00 00 04 b4 00 00 00 b4 result: 010: 00 00 05 68 00 00 00 24 00 00 05 8c 00 00 00 48 result: 020: 00 00 00 20 00 00 00 08 00 00 00 20 00 00 00 20 result: 030: 00 00 00 10 00 00 00 08 00 00 00 08 00 00 00 04 result: 040: 00 00 00 00 00 00 00 00 This commit adds support the model by adding hard-coded stream formats. $ python3 ~/git/linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04041ad7 bus_info_length 4, crc_length 4, crc 6871 404 31333934 bus_name "1394" 408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255, max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400) 40c 00059504 company_id 000595 | Alesis Corporation 410 008003f5 device_id 04008003f5 | EUI-64 00059504008003f5 root directory ----------------------------------------------------------------- 414 0006a620 directory_length 6, crc 42528 418 03000595 vendor: Alesis Corporation 41c 8100000a --> descriptor leaf at 444 420 17000002 model 424 8100000d --> descriptor leaf at 458 428 0c0087c0 node capabilities per IEEE 1394 42c d1000001 --> unit directory at 430 unit directory at 430 ----------------------------------------------------------------- 430 00041b9f directory_length 4, crc 7071 434 12000595 specifier id: Alesis Corporation 438 13000001 version: audio 43c 17000002 model 440 8100000d --> descriptor leaf at 474 descriptor leaf at 444 ----------------------------------------------------------------- 444 000494c2 leaf_length 4, crc 38082 448 00000000 textual descriptor 44c 00000000 minimal ASCII 450 416c6573 "Ales" 454 69730000 "is" descriptor leaf at 458 ----------------------------------------------------------------- 458 0006c2ec leaf_length 6, crc 49900 45c 00000000 textual descriptor 460 00000000 minimal ASCII 464 4d617374 "Mast" 468 6572436f "erCo" 46c 6e74726f "ntro" 470 6c000000 "l" descriptor leaf at 474 ----------------------------------------------------------------- 474 0006c2ec leaf_length 6, crc 49900 478 00000000 textual descriptor 47c 00000000 minimal ASCII 480 4d617374 "Mast" 484 6572436f "erCo" 488 6e74726f "ntro" 48c 6c000000 "l" Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113084630.14305-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: dice: loosen stream format check for MIDI conformant data channelTakashi Sakamoto
ALSA dice driver expects devices to multiplex MIDI messages into first port of isochronous communication. Actually devices perform for it. However, check of stream format is invalid for second port of isochronous communication. As a result, when the device supports two ports for isochronous communication and the stream format is hard-coded, ALSA dice driver fails to start packet streaming. This commit loosens stream format check for MIDI conformant data channel. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113084630.14305-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: dice: fix fallback from protocol extension into limited functionalityTakashi Sakamoto
At failure of attempt to detect protocol extension, ALSA dice driver should be fallback to limited functionality. However it's not. This commit fixes it. Cc: <stable@vger.kernel.org> # v4.18+ Fixes: 58579c056c1c9 ("ALSA: dice: use extended protocol to detect available stream formats") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113084630.14305-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: oxfw: fix for Stanton SCS.1dTakashi Sakamoto
Stanton SCS.1d uses Oxford Semiconductor FW 971 ASIC (FW971) for communication. Although the unit is bound to ALSA oxfw driver, the instance of sound card can not be added due to its quirk of plug information. This bug was added when snd-scs1x is merged into snd-oxfw at commit 9e2004f9cedf ("ALSA: oxfw: obsolete scs1x module"). This commit fixes the driver for the quirk. In cases that the unit returns NOT IMPLEMENTED for some AV/C commands, the sound card is added without any PCM/MIDI interfaces for packet streaming. For SCS.1d, model dependent operation adds MIDI interface and applications can use it to operate according to HSS1394 protocol from reverse-engineering work by Sean M. Pappalardo. Plug Control Register (PCR) has information that the unit has a pair of plugs for isochronous communication: (oMPR) $ ./firewire-request /dev/fw1 read 0xfffff0000900 result: 80ff0001 (iMPR) $ ./firewire-request /dev/fw1 read 0xfffff0000980 result: 80ff0001 AV/C PLUG INFO also returns information that the unit has a pair of plugs for isochronous communication. (AV/C PLUG INFO command) $ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff response: 000: 0c ff 02 00 01 01 02 02 However, AV/C PLUG SIGNAL INFO command is rejected for both plugs. (AV/C OUTPUT PLUG SIGNAL INFO command) $ ./firewire-request /dev/fw1 fcp 0x01ff1800ffffffff response: 000: 0a ff 18 00 ff ff ff ff (AV/C INPUT PLUG SIGNAL INFO command) $ ./firewire-request /dev/fw1 fcp 0x01ff1900ffffffff response: 000: 0a ff 19 00 ff ff ff ff Furthermore, AV/C EXTENDED STREAM FORMAT INFO is not implemented. (AV/C EXTENDED STREAM FORMAT INFO list subfunction for input plug) $ ./firewire-request /dev/fw1 fcp 0x01ffbfc000000000ffff00ff response: 000: 08 ff bf c0 00 00 00 00 ff ff 00 ff (AV/C EXTENDED STREAM FORMAT INFO list subfunction for output plug) $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffff00ff response: 000: 08 ff bf c0 01 00 00 00 ff ff 00 ff (AV/C EXTENDED STREAM FORMAT INFO single subfunction for input plug) $ ./firewire-request /dev/fw1 fcp 0x01ffbfc100000000ffffffff response: 000: 08 ff bf c1 00 00 00 00 ff ff ff ff (AV/C EXTENDED STREAM FORMAT INFO single subfunction for output plug) $ ./firewire-request /dev/fw1 fcp 0x01ffbfc101000000ffffffff response: 000: 08 ff bf c1 01 00 00 00 ff ff ff ff Reference: https://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/052264.html Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113073418.24622-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: oxfw: don't add MIDI/PCM interface when packet streaming is unavailableTakashi Sakamoto
Stanton SCS.1d doesn't support packet streaming even if it has plugs for isochronous communication. This commit is a preparation for this case. The 'has_input' member is added to specific structure, and MIDI/PCM interfaces are not added when the member is false. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113073418.24622-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: oxfw: use ENXIO for not-supported casesTakashi Sakamoto
When AV/C command returns 'NOT IMPLEMENTED' status in its response, ALSA oxfw driver uses ENOSYS as error code. However, it's expected just to be used for missing system call number. This commit replaces it with ENXIO. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113073418.24622-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: firewire-tascam: fix corruption due to spin lock without restoration ↵Takashi Sakamoto
in SoftIRQ context ALSA firewire-tascam driver can bring corruption due to spin lock without restoration of IRQ flag in SoftIRQ context. This commit fixes the bug. Cc: Scott Bahling <sbahling@suse.com> Cc: <stable@vger.kernel.org> # v4.21 Fixes: d7167422433c ("ALSA: firewire-tascam: queue events for change of control surface") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113085719.26788-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-11ALSA: firewire: Drop superfluous ioctl PCM opsTakashi Iwai
All the PCM ioctl ops of ALSA FireWire drivers do nothing but calling the default handler. Now PCM core accepts NULL as the default ioctl ops(*), so let's drop altogether. (*) commit fc033cbf6fb7 ("ALSA: pcm: Allow NULL ioctl ops") Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191210061145.24641-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-11ALSA: firewire: Use managed buffer allocationTakashi Iwai
Clean up the drivers with the new managed buffer allocation API. The superfluous snd_pcm_lib_malloc_pages() and snd_pcm_lib_free_pages() calls are dropped. Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191209192422.23902-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-09ALSA: fireface: fix return value in error path of isochronous resources ↵Takashi Sakamoto
reservation Even if isochronous resources reservation fails, error code doesn't return in pcm.hw_params callback. Cc: <stable@vger.kernel.org> #5.3+ Fixes: 55162d2bb0e8 ("ALSA: fireface: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191209151655.GA8090@workstation Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-09ALSA: oxfw: fix return value in error path of isochronous resources reservationTakashi Sakamoto
Even if isochronous resources reservation fails, error code doesn't return in pcm.hw_params callback. Cc: <stable@vger.kernel.org> #5.3+ Fixes: 4f380d007052 ("ALSA: oxfw: configure packet format in pcm.hw_params callback") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191209151655.GA8090@workstation Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-09ALSA: firewire-motu: fix double unlocked 'motu->mutex'Takashi Sakamoto
Mutex is doubly unlocked in some error path of pcm.open. This commit fixes ALSA firewire-motu driver in Linux kernel v5.5. Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 3fd80b200388 ("ALSA: firewire-motu: use the same size of period for PCM substream in AMDTP streams") Fixes: 0f5482e7875b ("ALSA: firewire-motu: share PCM buffer size for both direction") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191208232226.6685-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-07Merge branch 'for-linus' into for-nextTakashi Iwai
Merge 5.4-devel branch for applying the further ALSA timer fixes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-06ALSA: firewire: Convert to the common vmalloc memallocTakashi Iwai
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. (*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae39fd1: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-04ALSA: bebob: fix to detect configured source of sampling clock for Focusrite ↵Takashi Sakamoto
Saffire Pro i/o series For Focusrite Saffire Pro i/o, the lowest 8 bits of register represents configured source of sampling clock. The next lowest 8 bits represents whether the configured source is actually detected or not just after the register is changed for the source. Current implementation evaluates whole the register to detect configured source. This results in failure due to the next lowest 8 bits when the source is connected in advance. This commit fixes the bug. Fixes: 25784ec2d034 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series") Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191102150920.20367-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-02ALSA: bebob: link the order of establishing connections and Syt-match clock modeTakashi Sakamoto
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.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-02ALSA: bebob: expand delay of start for IR context just for version 3 firmwareTakashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191101131323.17300-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-02ALSA: bebob: expand sleep just after breaking connections for protocol version 1Takashi Sakamoto
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: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: Correct a typo in the clock proc stringTakashi Iwai
Just fix a typo of "S/PDIF" in the clock name string. Fixes: 4638ec6ede08 ("ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats") Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030100921.3826-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: add support for MOTU UltraLiteTakashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: code refactoring to handle model specific switch for ↵Takashi Sakamoto
protocol v2 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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: minor code refactoring for protocol version 2Takashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: detect SPH source of sampling clockTakashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: print for unknown source of sampling clockTakashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: fix wrong spelling for macroTakashi Sakamoto
Just replace 'SEPARETED' with 'SEPARATED' for macro. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-28Merge branch 'for-linus' into for-nextTakashi Iwai
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 <tiwai@suse.de>
2019-10-26ALSA: bebob: Fix prototype of helper function to return negative valueTakashi Sakamoto
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: eb7b3a056cd8 ("ALSA: bebob: Add commands and connections/streams management") Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191026030620.12077-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: postpone to start IR contextTakashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: handle several AMDTP streams in callback handler of IRQ ↵Takashi Sakamoto
target 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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: cancel flushing isoc context in the laste step to ↵Takashi Sakamoto
process context callback 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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: replace ack callback to flush isoc contexts in AMDTP domainTakashi Sakamoto
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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: replace pointer callback to flush isoc contexts in AMDTP ↵Takashi Sakamoto
domain 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 <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: add irq_target member into amdtp_domain structTakashi Sakamoto
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: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: tune the minimum available size of PCM periodTakashi Sakamoto
In IEC 61883-1/6, one isoc packet can transfer events up to the value of syt interval. This comes from the interval of isoc cycle. As 1394 OHCI controller can generate hardware IRQ per isoc packet, the interval is calculated as 125 usec. In IEC 61883-1/6, two ways of transmission is described; blocking and non-blocking methods. In blocking method, the sequence of packet includes 'empty' or 'NODATA' packets which include no events. In non-blocking method, the number of events per packet is variable up to the syt interval. This commit uses double of the value of syt interval as minimum available size of PCM period due to the above protocol design. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-13-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: tune the maximum available size of PCM periodTakashi Sakamoto
Linux driver for 1394 OHCI controller voluntarily flushes isoc context when total size of accumulated context header reached PAGE_SIZE. This kicks tasklet for the isoc context. This is inconvenient to process runtime of PCM substream. This commit adds a restriction of the maximum size of PCM period to avoid this behaviour. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-12-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: schedule hardware IRQ according to the size of PCM periodTakashi Sakamoto
ALSA IEC 61883-1/6 packet streaming engine controls 1394 OHCI controller to generate hardware IRQ for fixed number of isochronous packets (=16) since its first commit. This commit allow the engine to generate it for variable period according to the number of event to handle. For outgoing stream, internal calculator is used to check the accumulated events. For incoming stream, the number of data block in the packet of stream is used to check the accumulated events. When it's unavailable, fixed number of packet roughly calculated in advance is used instead of event counting. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-11-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: fireface: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA fireface driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-10-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-motu: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA firewire-motu driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-tascam: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA firewire-tascam driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-digi00x: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA firewire-digi00x driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: dice: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA dice driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: oxfw: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA oxfw driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: fireworks: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA fireworks driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: bebob: share PCM buffer size for both directionTakashi Sakamoto
This commit allows ALSA bebob driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: use variable size of queue for isoc packets instead of ↵Takashi Sakamoto
fixed size The number of packets in packet buffer has been fixed number (=48) since first commit of ALSA IEC 61883-1/6 packet streaming engine. This commit allows the engine to use variable number of packets in the buffer. The size is calculated by a parameter in AMDTP domain structure surely to store the number of events in the packets of buffer. Although the value of parameter is expected to come from 'period size' parameter of PCM substream, at present 48 is still used. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireface: use the same size of period for PCM substreams in AMDTP streamsTakashi Sakamoto
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This commit replaces the check with the substream count and the value for the size of PCM period. Unlike the other drivers in ALSA firewire stack, no MIDI substream is multiplexed into AMDTP stream. I note that Fireface AMDTP protocol has a quirk that tx stream includes blank isochronous cycle. The packet for blank cycle is equivalent to empty or NODATA packet in IEC 61883-6, thus the protocol is similar to blocking transmission method of IEC 61883-6. On the other hand, rx stream adopts non-blocking transmission method. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-18-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-motu: use the same size of period for PCM substream in AMDTP ↵Takashi Sakamoto
streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-17-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-tascam: use the same size of period for PCM substream in ↵Takashi Sakamoto
AMDTP streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This commit replaces the check with the substream count and the value for the size of PCM period. Unlike the other drivers in ALSA firewire stack, no MIDI substream is multiplexed into AMDTP stream. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-16-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-digi00x: use the same size of period for PCM substream in ↵Takashi Sakamoto
AMDTP streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. I note that DOT AMDTP protocol has a quirk to use different transmission method of IEC 61883-6 for tx/rx streams; non-blocking in tx stream and blocking in rx stream. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-15-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>