summaryrefslogtreecommitdiff
path: root/sound/firewire/motu/amdtp-motu.c
AgeCommit message (Collapse)AuthorFilesLines
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>
2019-03-18ALSA: firewire-motu: add support MOTU 8pre FireWireTakashi Sakamoto1-0/+6
This commit adds support for MOTU 8pre FireWire, which was shipped 2007 and nowadays already discontinued. Userspace applications can transmit and receive PCM frames and MIDI messages for this model via ALSA PCM interface and RawMidi/Sequencer interfaces. Like the other models of MOTU FireWire series, this model has many quirks in its CIP. At first, data channels for two pairs of optical interfaces. At lower sampling transmission frequency, i.e. 44.1 and 48.0 kHz, one pair is available for ADAT data, thus 8 data chunks are transferred by CIP. At middle sampling transmission frequency, i.e. 88.2 and 96.0 kHz, two pairs are available to keep 8 chunks for ADAT data, thus CIP still includes 8 data chunks. Apart from data chunks for optical interface, CIP includes fixed number of data chunks. In tx stream, two chunks for status message, eight chunks for samples from analog 1-8 input, two chunks for mix-return. In rx stream, two chunks for control message, two chunks for main 1-2 output, two chunks for phone 1-2 output, two chunks for dummy 1-2. CIP header in tx stream includes quirks for its dbs and dbc fields. The value of dbs field is fixed to 0x13, against its actual size. The value of dbc field is firstly updated to 0x07 from zero, then it's incremented continuously according to actual number of data h blocks. Finally, the model has own bits to disable frame fetch. This commit uses several options to absorb the above quirks. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0410b57d bus_info_length 4, crc_length 16, crc 46461 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 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfb 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 0003991c directory_length 3, crc 39196 42c 120001f2 specifier id 430 1300000f version 434 17103800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 00022681 leaf_length 2, crc 9857 43c 0001f200 company_id 0001f2 | 440 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfb Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-02-26ALSA: firewire-motu: fix construction of PCM frame for capture directionTakashi Sakamoto1-1/+3
In data blocks of common isochronous packet for MOTU devices, PCM frames are multiplexed in a shape of '24 bit * 4 Audio Pack', described in IEC 61883-6. The frames are not aligned to quadlet. For capture PCM substream, ALSA firewire-motu driver constructs PCM frames by reading data blocks byte-by-byte. However this operation includes bug for lower byte of the PCM sample. This brings invalid content of the PCM samples. This commit fixes the bug. Reported-by: Peter Sjöberg <autopeter@gmail.com> Cc: <stable@vger.kernel.org> # v4.12+ Fixes: 4641c9394010 ("ALSA: firewire-motu: add MOTU specific protocol layer") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-10-25locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns ↵Mark Rutland1-2/+2
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-20ALSA: firewire-motu: mark trace helpers as __maybe_unusedArnd Bergmann1-4/+6
Two functions were introduced for the purpose of tracing but cause warnings when tracing is disabled: sound/firewire/motu/amdtp-motu.c:284:13: error: 'copy_message' defined but not used [-Werror=unused-function] static void copy_message(u64 *frames, __be32 *buffer, unsigned int data_blocks, sound/firewire/motu/amdtp-motu.c:271:13: error: 'copy_sph' defined but not used [-Werror=unused-function] static void copy_sph(u32 *frames, __be32 *buffer, unsigned int data_blocks, Marking them as __maybe_unused will do the right thing here. Fixes: 17909c1b3058 ("ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashion") Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-04-11ALSA: firewire-motu: add tracepoints for messages for unique protocolTakashi Sakamoto1-0/+17
MOTU units transfer/receive messages in each data block of their isochronous packet payload. A part of content in the message is cleard for MIDI message transmission, while the rest is unknown yet. Additional features are required to assist users and developers to reveal the details. This commit adds tracepoints for the purpose. The tracepoints are designed for MOTU's protocol version 2 and 3 (Protocol version 1 is not upstreamed yet). In the tracepoints, events are probed to gather first two 24 bit data chunks of each data block. The chunks are formatted into elements of 64 bit array with padding in MSB. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-04-11ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashionTakashi Sakamoto1-0/+20
Unique protocol is used for MOTU FireWire series. In this protocol, data block format is not compliant to AM824 in IEC 61883-1/6. Each of the data block consists of 24 bit data chunks, except for a first quadlet. The quadlet is used for source packet header (SPH) described in IEC 61883-1. The sequence of SPH seems to represent presentation timestamp corresponding to included data. Developers have experienced that invalid sequence brings disorder of units in the series. Unfortunately, current implementation of ALSA IEC 61883-1/6 engine and firewire-motu driver brings periodical noises to the units at sampling transmission frequency based on 44.1 kHz. The engine generates the SPH with even interval and this mechanism seems not to be suitable to the units. Further work is required for this issue and infrastructure is preferable to assist the work. This commit adds tracepoints for the purpose. In the tracepoints, events are probed to gather the SPHs from each data blocks. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-28ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a ↵Takashi Sakamoto1-0/+12
model with protocol version 3 MOTU 828mk3 (FireWire/Hybrid) is one of third generation in MOTU FireWire series, produced in 2008/2014. This model consists of three chips for functionality on IEEE 1394 bus: * TI TSB41AB2 (Physical layer for IEEE 1394 bus) * Xilinx Spartan-3E FPGA Family (Link layer for IEEE 1394 bus, packet processing and data block processing layer) * TI TMS320C6722 (Digital signal processing) This commit adds a support for this model, with its unique protocol as version 3. This protocol has some additional features to protocol version 2. * Support several optical interfaces. * Support a data chunk for return of reverb effect. * Have a quirk of tx packets. * Support heartbeat asynchronous transaction. In this protocol, series of transferred packets has some quirks. Below fields in CIP headers of the packets are out of IEC 61883-1: - SID (source node id): always 0x0d - DBS (data block size): always 0x04 - DBC (data block counter): always 0x00 - EOH (End of header): always 0x00 Below is an actual sample of transferred packets. quads CIP1 CIP2 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF Status of clock is configured by write transactions to 0x'ffff'f000'0b14, as well as version 2, while meanings of fields are different from the former protocols. Modes of optical interfaces are configured by write transactions to 0x'ffff'f000'0c94. Drivers can register its address to receive heatbeat transactions from the unit. 0x'ffff'f000'0b0c is for the higher part and 0x'ffff'f000'0b10 is for the lower part. Nevertheless, this feature is not useless for this driver and this commit omits it. Each data block consists of two parts in a point of the number of included data chunks. In both of 'fixed' and 'differed' parts, the number of included data blocks are a multiple of 4, thus depending on models there's some empty data chunks. For example, 828mk3 includes one pair of empty data chunks in its fixed part. When optical interface is configured to S/PDIF, 828mk3 includes one pair of empty data chunks in its differed part. To reduce consumption of CPU cycles with additional conditions/loops, this commit just exposes these empty chunks to user space as PCM channels. Additionally, 828mk3 has a non-negligible overhead to change its sampling transfer frequency. When softwares send asynchronous transaction to perform it, LED on the unit starts to blink. In a worst case, it continues blink during several seconds; e.g. 10 seconds. When stopping blinking, the unit seems to be prepared for the requested sampling transfer frequency. To wait for the preparation, this commit forces the driver to call task scheduler and applications sleeps for 4 seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-28ALSA: firewire-motu: add MIDI functionalityTakashi Sakamoto1-0/+84
In MOTU FireWire series, MIDI messages are multiplexed to isochronous packets as well as PCM frames, while the way is different from the one in IEC 61883-6. MIDI messages are put into a certain position in message chunks. One data block can includes one byte of the MIDI messages. When data block includes a MIDI byte, the block has a flag in a certain position of the message chunk. These positions are unique depending on protocols. Once a data block includes a MIDI byte, some following data blocks includes no MIDI bytes. Next MIDI byte appears on a data block corresponding to next cycle of physical MIDI bus. This seems to avoid buffer overflow caused by bandwidth differences between IEEE 1394 bus and physical MIDI bus. This commit adds MIDI functionality to transfer/receive MIDI messages. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-28ALSA: firewire-motu: add MOTU specific protocol layerTakashi Sakamoto1-0/+292
MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>