summaryrefslogtreecommitdiff
path: root/sound/firewire/fireface/amdtp-ff.c
AgeCommit message (Collapse)Author
2023-01-12ALSA: firewire-lib: obsolete return value from context payload processing layerTakashi Sakamoto
This commit obsoletes return value from the context payload processing layer since the multiplier between the data block count and PCM frame count was moved to the packet streaming processing layer. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230110134933.322794-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-01-12ALSA: firewire-lib: move parameter for pcm frame multiplier from context ↵Takashi Sakamoto
payload processing layer The current implementation delegates the task to calculate the number of processed PCM frames into the context payload processing layer. It looks good as long as frame calculation is done for a single purpose. Nevertheless, another purpose, the computation of extra delay for the runtime of PCM substream, requires frame calculation, too. This commit refactors the current implementation so that the packet stream processing layer is responsible for the calculation of PCM frame, too. The member is moved to stream structure for multiplier between data block count and PCM frame count. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230110134933.322794-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-01-09ALSA: firewire-lib: use circular linked list for context payload processing ↵Takashi Sakamoto
layer The list of packet descriptor is passed to context payload processing layer so that each driver can copy PCM frames, MIDI messages, and device specific data between packet payload buffer and intermediate buffer for user space application. The list of packet descriptor was replaced by circular linked list in a previous commit. This commit uses circular linked in context payload processing layer as well. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230109021738.75543-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01ALSA: fireface: perform sequence replay for media clock recoveryTakashi Sakamoto
This commit takes ALSA fireface driver to perform sequence replay for media clock recovery. The protocol specific to RME Fireface series is not compliant to IEC 61883-1/6 since it has no CIP header, therefore presentation time is not used for media clock recovery. The sequence of the number of data blocks per packet is important. I note that the device skips an isochronous cycle corresponding to an empty packet or a NODATA packet in blocking transmission method of IEC 61883-1/6. For sequence replay, the cycle is handled as receiving an empty packet. Furthermore, it doesn't start packet transmission till receiving any packet. The sequence replay is tested with below models: * Fireface 400 * Fireface 800 * Fireface 802 I note that it is better to initialize Fireface 400 in advance by initialization transaction implemented in snd-fireface-ctl-service of snd-firewire-ctl-services project. You can see whether initialized or not by HOST LED on the device. Unless, the device often stops packet transmission even if session starts. I guess the sequence replay also works well with below models: * Fireface UFX * Fireface UCX Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210531025103.17880-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-22ALSA: firewire-lib: process payload of isoc context according to packet ↵Takashi Sakamoto
descriptors This commit changes each of data block processing layer so that it receives list of packet descriptor. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-22ALSA: fireface: code refactoring for FF data block processing layerTakashi Sakamoto
This is code refactoring for FF data block processing layer so that it can receive list of packet descriptor. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-22ALSA: firewire-lib: pass packet descriptor to data block processing layerTakashi Sakamoto
This commit changes signature of callback function to call data block processing layer with packet descriptor. At present, the layer is called per packet. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-22ALSA: firewire-lib: pass no syt information to data block processing layerTakashi Sakamoto
In a previous commit, the variable passed from packet streaming layer for syt variable is useless. This commit obsoletes it. In my future work, the syt information is passed to data block processing layer by another way. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-22ALSA: firewire-lib: pass data block counter to data block processing layerTakashi Sakamoto
This is a preparation for future commit that 'struct amdtp_stream.data_block_count' does not represent the value of data block count for current data block. However, data block count is required for calculation of sequence index in sequence-multiplied data channel. Some of data block processing layer require it; e.g. for AM824 data block. This commit passes data block count to the processing layer. 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 Gleixner
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>
2017-10-25locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns ↵Mark Rutland
to READ_ONCE()/WRITE_ONCE() Please do not apply this to mainline directly, instead please re-run the coccinelle script shown below and apply its output. For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't harmful, and changing them results in churn. However, for some features, the read/write distinction is critical to correct operation. To distinguish these cases, separate read/write accessors must be used. This patch migrates (most) remaining ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following coccinelle script: ---- // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and // WRITE_ONCE() // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch virtual patch @ depends on patch @ expression E1, E2; @@ - ACCESS_ONCE(E1) = E2 + WRITE_ONCE(E1, E2) @ depends on patch @ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) ---- Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: davem@davemloft.net Cc: linux-arch@vger.kernel.org Cc: mpe@ellerman.id.au Cc: shuah@kernel.org Cc: snitzer@redhat.com Cc: thor.thayer@linux.intel.com Cc: tj@kernel.org Cc: viro@zeniv.linux.org.uk Cc: will.deacon@arm.com Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-05ALSA: fireface: add unique data processing layerTakashi Sakamoto
As long as investigating Fireface 400, format of payload of each isochronous packet is not IEC 61883-1/6, thus its format of data block is not AM824. The remarkable points of the format are: * The payload just consists of some data channels of quadlet size without CIP header. * Each data channels includes data aligned to little endian order. * One data channel consists of two parts; 8 bit ancillary field and 24 bit PCM frame. Due to lack of CIP headers, rx/tx packets include no CIP headers and different way to check packet discontinuity. For tx packet, the ancillary field is used for counter. However, the way of counting is different depending on positions of data channels. At 44.1 kHz, ancillary field in: * 1st/6th/9th/10th/14th/17th data channels: not used for this purpose. * 2nd/18th data channels: incremented every data block (0x00-0xff). * 3rd/4th/5th/11th/12th/13th data channels: incremented every 256 data blocks (0x00-0x07). * 7th/8th/15th/16th data channels: incremented per the number of data blocks in a packet. The increment can occur per packet (0x00-0xff). For tx packet, tag of each isochronous packet is used for this purpose. The value of tag cyclically changes between 0, 1, 2 and 3 in this order. The interval is different depending on sampling transmission frequency. At 44.1/48.0 kHz, it's 256 data blocks. At 88.2 kHz, it's 96 data blocks. The number of data blocks in tx packet is exactly the same as SYT_INTERVAL. There's no empty packet or no-data packet, thus the throughput is not 8,000 packets per sec. On the other hand, the one in rx packet is 8,000 packets per sec, thus the number of data blocks is different between each packet, depending on sampling transmission frequency: * 44.1 kHz: 5 or 6 * 48.0 kHz: 5 or 6 or 7 * 88.2 kHz: 10 or 11 or 12 This commit adds data processing layer to satisfy the above specification in a policy of 'best effort'. Although PCM frames are handled for intermediate buffer to user space, the ancillary data is not handled at all to reduce CPU usage, thus counter is not checked. 0 is always used for tag of isochronous packet. Furthermore, the packet streaming layer is responsible for calculation of the number of data blocks for each packet, thus it's not exactly the same sequence from the above observation. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>