summaryrefslogtreecommitdiff
path: root/sound/firewire/oxfw/oxfw-stream.c
AgeCommit message (Collapse)AuthorFilesLines
2024-02-19ALSA: oxfw: add support for Miglia Harmony AudioTakashi Sakamoto1-0/+2
Miglia Technology ships Harmony Audio 2004. It uses Oxford Semiconductor OXFW970 for communication function in IEEE 1394 bus. This commit adds support for the model. In my opinion, the firmware of ASIC is really the initial stage, since it has the following quirks. * It skips several isochronous cycles to transmit isochronous packets when receiving any asynchronous transaction. * The value of dbc field in the transmitted packet is the number of accumulated quadlets in CIP payload, instead of the accumulated data blocks. Furthermore, the value includes the quadlets of CIP payload in the packet. * It neither supports AV/C Stream Format Information command nor AV/C Extended Stream Format Information command. * The vendor and model information in root directory of configuration ROM includes some mistakes. Additionally, when operating at 96.0 kHz, it often skips much isochronous cycles to transmit the isochronous packets. The issue is detected as cycle discontinuity and ALSA PCM application receives -EIO at any operation for PCM substream. I have never found any workaround yet. $ config-rom-pretty-printer < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 1024 04249e04 bus_info_length 4, crc_length 36, crc 40452 1028 31333934 bus_name "1394" 1032 20ff5003 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64) 1036 0030e002 company_id 0030e0 | 1040 00454647 device_id 8594474567 | EUI-64 13757098081207879 root directory ----------------------------------------------------------------- 1044 00062d69 directory_length 6, crc 11625 1048 030030e0 vendor 1052 8100000a --> descriptor leaf at 1092 1056 1700f970 model 1060 81000011 --> descriptor leaf at 1128 1064 0c0083c0 node capabilities: per IEEE 1394 1068 d1000001 --> unit directory at 1072 unit directory at 1072 ----------------------------------------------------------------- 1072 00046ff9 directory_length 4, crc 28665 (should be 43676) 1076 1200a02d specifier id 1080 13010001 version 1084 1700f970 model 1088 8100000f --> descriptor leaf at 1148 descriptor leaf at 1092 ----------------------------------------------------------------- 1092 00085f8a leaf_length 8, crc 24458 1096 00000000 textual descriptor 1100 00000000 minimal ASCII 1104 4d69676c "Migl" 1108 69612054 "ia T" 1112 6563686e "echn" 1116 6f6c6f67 "olog" 1120 79204c74 "y Lt" 1124 642e0000 "d." descriptor leaf at 1128 ----------------------------------------------------------------- 1128 00040514 leaf_length 4, crc 1300 1132 00000000 textual descriptor 1136 00000000 minimal ASCII 1140 4f584657 "OXFW" 1144 20393730 " 970" descriptor leaf at 1148 ----------------------------------------------------------------- 1148 0005a1dc leaf_length 5, crc 41436 1152 00000000 textual descriptor 1156 00000000 minimal ASCII 1160 4861726d "Harm" 1164 6f6e7941 "onyA" 1168 7564696f "udio" Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20240218074128.95210-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-02-19ALSA: oxfw: support the case that AV/C Stream Format Information command is ↵Takashi Sakamoto1-23/+73
not available Miglia Harmony Audio does neither support AV/C Stream Format Information command nor AV/C Extended Stream Format Information command. This commit adds a workaround for the case and uses the hard-coded formats. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20240218074128.95210-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-02-19ALSA: oxfw: use const qualifier for immutable argumentTakashi Sakamoto1-1/+1
In the helper function, the first argument is immutable, thus it is preferable to use const qualifier. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20240218074128.95210-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-28ALSA: oxfw: fix functional regression for Mackie Onyx 1640i in v5.14 or laterTakashi Sakamoto1-1/+6
A user reports functional regression for Mackie Onyx 1640i that the device generates slow sound with ALSA oxfw driver which supports media clock recovery. Although the device is based on OXFW971 ASIC, it does not transfer isochronous packet with own event frequency as expected. The device seems to adjust event frequency according to events in received isochronous packets in the beginning of packet streaming. This is unknown quirk. This commit fixes the regression to turn the recovery off in driver side. As a result, nominal frequency is used in duplex packet streaming between device and driver. For stability of sampling rate in events of transferred isochronous packet, 4,000 isochronous packets are skipped in the beginning of packet streaming. Reference: https://github.com/takaswie/snd-firewire-improve/issues/38 Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-12ALSA: oxfw: fix functioal regression for silence in Apogee Duet FireWireTakashi Sakamoto1-1/+8
OXFW 971 has no function to use the value in syt field of received isochronous packet for playback timing generation. In kernel prepatch for v5.14, ALSA OXFW driver got change to send NO_INFO value in the field instead of actual timing value. The change brings Apogee Duet FireWire to generate no playback sound, while output meter moves. As long as I investigate, _any_ value in the syt field takes the device to generate sound. It's reasonable to think that the device just ignores data blocks in packet with NO_INFO value in its syt field for audio data processing. This commit adds a new flag for the quirk to fix regression. Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210812022839.42043-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01ALSA: oxfw: perform sequence replay for media clock recoveryTakashi Sakamoto1-4/+18
This commit takes ALSA oxfw driver to perform sequence replay for media clock recovery. Unfortunately, OXFW970 ASIC and its firmware has a quirk called jumbo payload which skips several isochronous cycles for packet transmission, thus the sequence replay is just adopted to OXFW971 ASIC. As well as Fireworks, OXFW ASICs also ignores presentation time against the way in IEC 61883-1/6. The sequence replay is tested with below models: * Tascam FireOne * Stanton Magnetics SCS.1m * Apogee Duet FireWire For below models, the sequence replay is tested to be disabled: * Griffin FireWave * Behringer F-Control Audio 202 * Loud Technology Tapco Link.FireWire 4x6 * Loud Technology Mackie Onyx Satellite Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210531025103.17880-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-28ALSA: firewire-lib: transfer rx packets on-the-fly when replayingTakashi Sakamoto1-1/+1
Models in below series start transmission of packet after receiving the sequence of packets: * Digidesign Digi00x family * RME Fireface series Additionally, models in Tascam FireWire series start multiplexing PCM frames into packets enough after receiving packets. It's required to transfer packets on-the-fly for the above models according to nominal sampling transfer frequency before starting sequence replay. This commit allows drivers to decide whether the engine transfers packet on-the-fly or not. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-28ALSA: firewire-lib: add replay target to cache sequence of packetTakashi Sakamoto1-1/+1
In design of audio and music unit in IEEE 1394 bus, feedback of effective sampling transfer frequency (STF) is delivered by packets transferred from device. The devices supported by ALSA firewire stack are categorized to three groups regarding to it. * Group 1: * Echo Audio Fireworks board module * Oxford Semiconductor OXFW971 ASIC * Digidesign Digi00x family * Tascam FireWire series * RME Fireface series * Group 2: * BridgeCo. DM1000/DM1100/DM1500 ASICs for BeBoB solution * TC Applied Technologies DICE ASICs * Group 3: * Mark of the Unicord FireWire series In group 1, the effective STF is determined by the sequence of the number of events per packet. In group 2, the sequence of presentation timestamp expressed in syt field of CIP header is interpreted as well. In group 3, the presentation timestamp is expressed in source packet header (SPH) of each data block. I note that some models doesn't take care of effective STF with large internal buffer. It's reasonable to name it as group 0: * Group 0 * Oxford Semiconductor OXFW970 ASIC The effective STF is known to be slightly different from nominal STF for all of devices, and to be different between the devices. Furthermore, the effective STF is known to be shifted for long-period transmission. This makes it hard for software to satisfy the effective STF when processing packets to the device. The effective STF is deterministic as a result of analyzing the batch of packet transferred from the device. For the analysis, caching the sequence of parameter in the packet is required. This commit adds an option so that AMDTP domain structure takes AMDTP stream structure to cache the sequence of parameters in packet transferred from the device. The parameters are offset ticks of syt field against the cycle to receive the packet and the number of data blocks per packet. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210527122611.173711-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-20ALSA: firewire-lib: change waking up timing to process packetsTakashi Sakamoto1-12/+2
When starting AMDTP domain, tasks in process context yields running CPU till all of isochronous context get callback, with an assumption that it's OK to process content of packet. However several isochronous cycles are skipped to transfer rx packets, or the content of rx packets are dropped, to manage the timing to start processing the packets. This commit changes the timing for tasks in process context to wake up when processing content of packet is actually ready. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210520040154.80450-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-18ALSA: oxfw: add quirk flag for blocking transmission methodTakashi Sakamoto1-1/+6
Stanton SCS.1m and Apogee Duet FireWire use blocking transmission method unlike the other models. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210518084557.102681-12-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-18ALSA: oxfw: code refactoring for wrong_dbs quirkTakashi Sakamoto1-1/+1
A new entry is added to the quirk enumeration for wrong_dbs quirk to obsolete structure member. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210518084557.102681-11-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-18ALSA: oxfw: code refactoring for jumbo-payload quirk in OXFW970Takashi Sakamoto1-13/+7
This commit adds enumeration to describe quirks of OXFW ASICs. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210518084557.102681-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: oxfw: fix for Stanton SCS.1dTakashi Sakamoto1-30/+42
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 Sakamoto1-0/+2
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 Sakamoto1-6/+6
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>
2019-10-19ALSA: firewire-lib: postpone to start IR contextTakashi Sakamoto1-1/+1
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-18ALSA: oxfw: share PCM buffer size for both directionTakashi Sakamoto1-2/+3
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: firewire-lib: use variable size of queue for isoc packets instead of ↵Takashi Sakamoto1-1/+1
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: oxfw: register the size of PCM period to AMDTP domainTakashi Sakamoto1-1/+11
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-26ALSA: oxfw: fix NULL pointer dereference to unused stream structureTakashi Sakamoto1-2/+7
ALSA oxfw driver supports Griffin FireWave. This device supports one isochronous stream for PCM playback. Current driver executes code to wait event for stream structure of opposite direction. This causes NULL pointer dereference. This commit fixes the bug. Fixes: ac5d77864cfc ("ALSA: oxfw: support AMDTP domain") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-05ALSA: oxfw: support AMDTP domainTakashi Sakamoto1-29/+43
This commit adds AMDTP domain support for ALSA oxfw driver. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-08Merge tag 'asoc-v5.3' of ↵Takashi Iwai1-2/+1
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v5.3 This is a very big update, mainly thanks to Morimoto-san's refactoring work and some fairly large new drivers. - Lots more work on moving towards a component based framework from Morimoto-san. - Support for force disconnecting muxes from Jerome Brunet. - New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant CX2072X, Realtek RT1011 and RT1308. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-21ALSA: oxfw: ensure to release isochronous resources in pcm.hw_params callbackTakashi Sakamoto1-0/+2
When stopping packet streaming in reserve function for duplex streams, isochronous resources should be released. Fixes: 7bc93821a70a ("ALSA: firewire-lib: split allocation of isochronous resources from establishment of connection") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-17ALSA: firewire-lib: split allocation of isochronous resources from ↵Takashi Sakamoto1-4/+14
establishment of connection In current implementation, establishment connection corresponds to allocation of isochronous resources. Although this is an ideal implementation of CMP described in IEC 61883-1, it's not enough efficient to recover PCM substream multiplexed in packet streaming. The packet streaming can always restart on the same allocated isochronous resources even if the previous packet streaming corrupted. This commit splits allocation of isochronous resources from establishment of connection so that CMP runs with allocated isochronous resources. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: configure stream parameter in pcm.hw_params callbackTakashi Sakamoto1-40/+57
This commit is a part of preparation to perform allocation/release of isochronous resources in pcm.hw_params/hw_free callbacks. This commit splits out an operation to configure stream parameters into pcm.hw_params callback. In pcm.prepare callback, establishing connections and start isochronous contexts. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: configure packet format in pcm.hw_params callbackTakashi Sakamoto1-13/+31
This commit is a part of preparation to perform allocation/release of isochronous resources in pcm.hw_params/hw_free callbacks. At present, several operations are done in pcm.prepare callback. To reduce load of the callback, This commit splits out an operation to set packet format in pcm.hw_params callback. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: unify substreams counterTakashi Sakamoto1-2/+2
In former commits, two isochronous contexts are handles at the same time. This commit unifies stream counters to obsolete them. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: rename helper functions for duplex streamsTakashi Sakamoto1-20/+40
In former commits, ALSA oxfw driver handles two isochronous contexts at the same time, except for some devices which supports one endpoint of isochronous packet stream. This commit renames some helper functions so that they handles duplex streams. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: expand stop procedure for packet streamingTakashi Sakamoto1-33/+35
The helper function stop packet streaming is not enough useful. This commit obsoletes it and expands its code. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: break packet streaming at bus-reset handlerTakashi Sakamoto1-10/+3
In most cases, recovery from bus reset is not successful. This commit aborts packet streaming in bus reset handler. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: start duplex streams if supportedTakashi Sakamoto1-53/+49
It's inconvenient to handle two isochronous context separately each other. This commit unifies the counters to handle the two at the same time. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: set packet parameter according to current configurationTakashi Sakamoto1-24/+24
After a call of pcm.hw_params, the state of target device is expected for applications. This commit retrieves the state and start packet streaming. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-12ALSA: oxfw: code refactoring for stop condition of packet streamingTakashi Sakamoto1-5/+2
This commit unifies stop condition due to queueing error and unmatched state of the target device. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 345Thomas Gleixner1-2/+1
Based on 1 normalized pattern(s): licensed under the terms of the gnu general public license version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 88 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000437.521539229@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-04ALSA: oxfw: use managed-resource to maintain cache of stream formatsTakashi Sakamoto1-5/+8
ALSA oxfw driver allocates memory objects for cache of stream formats. The objects are used to maintain packet streaming by components for ALSA rawMIDI/PCM interface. They can be released as managed-resource of 'struct snd_card.card_dev'. This commit uses managed-resource of the sound card device for this purpose. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-05-10ALSA: firewire-lib: enable the same feature as CIP_SKIP_INIT_DBC_CHECK flagTakashi Sakamoto1-2/+1
In former commit, drivers in ALSA firewire stack always starts IT context before IR context. If IR context starts after packets are transmitted by peer unit, packet discontinuity may be detected because the context starts in the middle of packet streaming. This situation is rare because IT context usually starts immediately. However, it's better to solve this issue. This is suppressed with CIP_SKIP_INIT_DBC_CHECK flag. This commit enables the same feature as CIP_SKIP_INIT_DBC_CHECK. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-19ALSA: oxfw: support more MIDI portsTakashi Sakamoto1-1/+1
In IEC 61883-6, sequence multiplexing is applied to MIDI conformant data channel. As a result, eight MIDI data streams are included in the channel. Although ALSA AM824 data block processing layer implements this multiplexing, current OXFW driver doesn't utilize it due to wrong calculation of MIDI ports. This commit fixes this bug to add proper calculation. Although this commit allows to use 8 MIDI data streams, the number of available MIDI ports is limited by the number of ALSA MIDI ports added by the driver. Fixes: df075feefbd3('ALSA: firewire-lib: complete AM824 data block processing layer') Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-19ALSA: oxfw: calculating MIDI ports in stream discoverTakashi Sakamoto1-1/+34
Current OXFW driver calculates the number of MIDI ports just before adding ALSA MIDI ports. It's convenient for some devices with quirks to move these codes before handling quirks. This commit implements this idea. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-29Merge branch 'topic/firewire-update' into for-nextTakashi Iwai1-4/+7
2015-09-29ALSA: firewire-lib: rename macros with AM824 prefixTakashi Sakamoto1-2/+2
This commit renames some macros just related to AM824 format. In later commit, they're moved to AM824 layer. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-29ALSA: firewire-lib: rename parameter setting function for AM824 with FDF fieldTakashi Sakamoto1-2/+2
The value of FDF field in CIP header is protocol-dependent. Thus, it's better to allow data block processing layer to decide the value in any timing. In AM824 data format, the value of FDF field in CIP header indicates N-flag and Nominal Sampling Frequency Code (sfc). The N-flag is for switching 'Clock-based rate control mode' and 'Command-based rate control mode'. In our implementation, 'Clock-based rate control mode' is just supported. Therefore, When sampling transfer frequency is decided, then the FDF can be set. This commit replaces 'amdtp_stream_set_parameters' with 'amdtp_am824_set_parameters' to set the FDF. This is the same timing to decide the ration between the number of data blocks and the number of PCM frames. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-29ALSA: firewire-lib: add data block processing layer for AM824 formatTakashi Sakamoto1-1/+1
This commit adds data block processing layer for AM824 format. The new layer initializes streaming layer with its value for fmt field. Currently, most implementation of data block processing still remains streaming layer. In later commits, these codes will be moved to the layer. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-29ALSA: firewire-lib: add an argument for Dice's dual wire modeTakashi Sakamoto1-1/+1
In IEC 61883-6, one data block represents one event. In ALSA, the event is one PCM frame. Therefore, when processing one data block, current implementation counts one PCM frame. On the other hand, Dice platform has a quirk called as 'dual wire' at higher sampling rate. In detail, see comment of commit 6eb6c81eee2a ("ALSA: dice: Split stream functionality into a file"). Currently, to handle this quirk, AMDTP stream structure has a 'double_pcm_frames' member. When this is enabled, two PCM frames are counted. Each driver set this flag by accessing the structure member directly. In future commit, some members related to AM824 data block will be moved to specific structure, to separate packet streaming layer and data block processing layer. The access will be limited by opaque pointer. For this reason, this commit adds an argument into amdtp_stream_set_parameter() to set the flag. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-29ALSA: firewire-lib: return error code when amdtp_stream_set_parameters() ↵Takashi Sakamoto1-1/+4
detects error Currently, amdtp_stream_set_parameters() returns no error even if wrong arguments are given. This is not good for streaming layer because drivers can continue processing ignoring capability of streaming layer. This commit changes this function to return error code. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-24ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' ↵Takashi Sakamoto1-1/+4
field in tx CIP header Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-08-07ALSA: firewire: use kmemdup rather than duplicating its implementationAndrzej Hajda1-6/+3
The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-05-23ALSA: firewire-lib: add buffer-over-run protection at receiving more data ↵Takashi Sakamoto1-2/+8
blocks than expected In IEC 61883-6, the number of data blocks in a packet is limited up to the value of SYT_INTERVAL. Current implementation is compliant to the limitation, while it can cause buffer-over-run when the value of dbs field in received packet is illegally large. This commit adds a validator to detect such illegal packets to prevent the buffer-over-run. Actually, the buffer is aligned to the size of memory page, thus this issue hardly causes system errors due to the room to page alignment, as long as a few packets includes such jumbo payload; i.e. a packet to several received packets. Here, Behringer F-Control Audio 202 (based on OXFW 960) has a quirk to postpone transferring isochronous packet till finish handling any asynchronous packets. In this case, this model is lazy, transfers no packets according to several cycle-start packets. After finishing, this model pushes required data in next isochronous packet. As a result, the packet include more data blocks than IEC 61883-6 defines. To continue to support this model, this commit adds a new flag to extend the length of calculated payload. This flag allows the size of payload 5 times as large as IEC 61883-6 defines. As a result, packets from this model passed the validator successfully. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-02-27ALSA: oxfw: fix a condition and return code in start_stream()Takashi Sakamoto1-2/+3
The amdtp_stream_wait_callback() doesn't return minus value and the return code is not for error code. This commit fixes with a propper condition and an error code. Fixes: f3699e2c7745 ('ALSA: oxfw: Change the way to start stream') Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-02-23ALSA: fireworks/bebob/dice/oxfw: allow stream destructor after releasing runtimeTakashi Sakamoto1-2/+4
Currently stream destructor in each driver has a problem to be called in a context in which sound card object is released, because the destructors call amdtp_stream_pcm_abort() and touch PCM runtime data. The PCM runtime data is destroyed in application's context with snd_pcm_close(), on the other hand PCM substream data is destroyed after sound card object is released, in most case after all of ALSA character devices are released. When PCM runtime is destroyed and PCM substream is remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes Null-pointer-dereference. This commit changes stream destructors and allows each driver to call it after releasing runtime. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-12-15ALSA: oxfw: some signedness bugsDan Carpenter1-1/+2
This code tends to use unsigned variables by default and it causes signedness bugs when we use negative variables for error handling. The "i" and "j" variables are used to iterated over small positive values and so they should be type "int". The "len" variable doesn't *need* to be signed but it should be signed to make the code easier to read and audit. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-21 03:17:32 +0300