kernel/sound/firewire/fireface/Makefile, branch linux-5.14.y

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46Z

Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

ALSA: fireface: add support for Fireface UCX

2019-01-21T14:12:25Z

Fireface UFX was shipped by RME GmbH in 2012. This model supports later protocol for management of isochronous communication and synchronization of sampling transmission frequency. This commit adds support for the model. At present, it's not clear how to encode MIDI messages and decide destination address for asynchronous transaction, thus this commit adds support for isochronous communication for PCM frames only. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: unify protocol layer for FF400/FF800

2019-01-21T14:12:15Z

This commit moves codes for Fireface 400 to a file of former protocol. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: rename protocol layer for former models

2019-01-21T14:12:14Z

In a series of Fireface, later model supports different protocol from former models. This commit is a preparation to support both of protocols. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: add support for Fireface 800 with MIDI functionality only

2018-12-11T13:58:01Z

Fireface 800 is a flagship model of RME GmbH for audio and music units on IEEE 1394 bus, shipped 2004. This model consists of four chips: - TI TSB81BA3D for physical layer on cable environment of EEE 1394 bus - TI TSB82AA2 for link layer for 1394 OHCI bus bridge to PCI bus - Xilinx Spartan-3 FPGA XC3S400 - Xilinx High-Performance CPLD XC9572XL This commit adds support Fireface 800. In this time, the support is restricted to its MIDI functionality, thus this commit adds some condition statements to avoid touching streaming functionality. Unlike Fireface 400, Fireface 800 has no functionality to suppress asynchronous transactions for MIDI messages except for unregister of listen address in controller side, thus the feature is available as is. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: add support for Fireface 400

2017-04-05T19:31:54Z

Fireface 400 is a second model of RME Fireface series, released in 2006. This commit adds support for this model. This model supports 8 analog channels, 2 S/PDIF channels and 8 ADAT channels in both of tx/rx packet. The number of ADAT channels differs depending on each mode of sampling transmission frequency. $ python2 linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04107768 bus_info_length 4, crc_length 16, crc 30568 (should be 61311) 404 31333934 bus_name "1394" 408 20009002 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 9 (1024) 40c 000a3501 company_id 000a35 | 410 1bd0862a device_id 011bd0862a | EUI-64 000a35011bd0862a root directory ----------------------------------------------------------------- 414 000485ec directory_length 4, crc 34284 418 03000a35 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 000314c4 directory_length 3, crc 5316 42c 12000a35 specifier id 430 13000002 version 434 17101800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 000261a8 leaf_length 2, crc 25000 43c 000a3501 company_id 000a35 | 440 1bd0862a device_id 011bd0862a | EUI-64 000a35011bd0862a Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: add hwdep interface

2017-04-05T19:31:49Z

This commit adds hwdep interface so as the other drivers for audio and music units on IEEE 1394 have. This interface is designed for mixer/control applications. By using this interface, an application can get information about firewire node, can lock/unlock kernel streaming and can get notification at starting/stopping kernel streaming. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: add support for PCM functionality

2017-04-05T19:31:46Z

This commit adds PCM functionality to transmit/receive PCM frames on isochronous packet streaming. This commit enables userspace applications to start/stop packet streaming via ALSA PCM interface. Sampling rate requested by applications is used as sampling transmission frequency of IEC 61883-1/6packet streaming. As I described in followed commits, units in this series manages sampling clock frequency independently of sampling transmission frequency, and they supports resampling between their packet streaming/data block processing layer and sampling data processing layer. This commit take this driver to utilize these features for usability. When internal clock is selected as source signal of sampling clock, this driver allows user space applications to start PCM substreams at any rate which packet streaming engine supports as sampling transmission frequency. In this case, this driver expects units to perform resampling PCM frames for rx/tx packets when sampling clock frequency and sampling transmission frequency are mismatched. This is for daily use cases. When any external clock is selected as the source signal, this driver gets configured sampling rate from units, then restricts available sampling rate to the rate for PCM applications. This is for studio use cases. Models in this series supports 64.0/128.0 kHz of sampling rate, however these frequencies are not supported by IEC 61883-6 as sampling transmission frequency. Therefore, packet streaming engine of ALSA firewire stack can't handle them. When units are configured to use any external clock as source signal of sampling clock and one of these unsupported rate is configured as rate of the sampling clock, this driver returns EIO to user space applications. Anyway, this driver doesn't voluntarily configure parameters of sampling clock. It's better for users to work with appropriate user space implementations to configure the parameters in advance of usage. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: add stream management functionality

2017-04-05T19:31:44Z

This commit adds management functionality for packet streaming. As long as investigating Fireface 400, there're three modes depending on sampling transmission frequency. The number of data channels in each data block is different depending on the mode. The set of available data channels for each mode might be different for each protocol and model. The length of registers for the number of isochronous channel is just three bits, therefore 0-7ch are available. When bus reset occurs on IEEE 1394 bus, the device discontinues to transmit packets. This commit aborts PCM substreams at bus reset handler. As I described in followed commits, The device manages its sampling clock independently of sampling transmission frequency against IEC 61883-6. Thus, it's a lower cost to change the sampling transmission frequency, while data fetch between streaming layer and DSP require larger buffer for resampling. As a result, device latency might tend to be larger than ASICs for IEC 61883-1/6 such as DM1000/DM1100/DM1500 (BeBoB), DiceII/TCD2210/TCD2220/TCD3070 and OXFW970/971. Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai

ALSA: fireface: add unique data processing layer

2017-04-05T19:31:42Z

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 Signed-off-by: Takashi Iwai