]> git.karo-electronics.de Git - karo-tx-linux.git/commit
ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with...
authorTakashi Sakamoto <o-takashi@sakamocchi.jp>
Wed, 22 Mar 2017 12:30:28 +0000 (21:30 +0900)
committerTakashi Iwai <tiwai@suse.de>
Tue, 28 Mar 2017 10:34:13 +0000 (12:34 +0200)
commit5992e30034c43917968f2327d2948d22be6d4603
treed07dbe8002db2675ae1eb89ad37ca5e2c5c60295
parent2128f78f75a36a34dfef0e127273c2f820c5c904
ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a 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>
sound/firewire/Kconfig
sound/firewire/motu/Makefile
sound/firewire/motu/amdtp-motu.c
sound/firewire/motu/motu-protocol-v3.c [new file with mode: 0644]
sound/firewire/motu/motu.c
sound/firewire/motu/motu.h