2019-05-29 23:57:59 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2017-03-22 12:30:11 +00:00
|
|
|
/*
|
|
|
|
* motu.c - a part of driver for MOTU FireWire series
|
|
|
|
*
|
|
|
|
* Copyright (c) 2015-2017 Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "motu.h"
|
|
|
|
|
|
|
|
#define OUI_MOTU 0x0001f2
|
|
|
|
|
|
|
|
MODULE_DESCRIPTION("MOTU FireWire driver");
|
|
|
|
MODULE_AUTHOR("Takashi Sakamoto <o-takashi@sakamocchi.jp>");
|
|
|
|
MODULE_LICENSE("GPL v2");
|
|
|
|
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:14 +00:00
|
|
|
const unsigned int snd_motu_clock_rates[SND_MOTU_CLOCK_RATE_COUNT] = {
|
|
|
|
/* mode 0 */
|
|
|
|
[0] = 44100,
|
|
|
|
[1] = 48000,
|
|
|
|
/* mode 1 */
|
|
|
|
[2] = 88200,
|
|
|
|
[3] = 96000,
|
|
|
|
/* mode 2 */
|
|
|
|
[4] = 176400,
|
|
|
|
[5] = 192000,
|
|
|
|
};
|
|
|
|
|
2017-03-22 12:30:11 +00:00
|
|
|
static void name_card(struct snd_motu *motu)
|
|
|
|
{
|
|
|
|
struct fw_device *fw_dev = fw_parent_device(motu->unit);
|
|
|
|
struct fw_csr_iterator it;
|
|
|
|
int key, val;
|
|
|
|
u32 version = 0;
|
|
|
|
|
|
|
|
fw_csr_iterator_init(&it, motu->unit->directory);
|
|
|
|
while (fw_csr_iterator_next(&it, &key, &val)) {
|
|
|
|
switch (key) {
|
2019-03-17 06:49:29 +00:00
|
|
|
case CSR_MODEL:
|
2017-03-22 12:30:11 +00:00
|
|
|
version = val;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
strcpy(motu->card->driver, "FW-MOTU");
|
2017-03-22 12:30:13 +00:00
|
|
|
strcpy(motu->card->shortname, motu->spec->name);
|
|
|
|
strcpy(motu->card->mixername, motu->spec->name);
|
2017-03-22 12:30:11 +00:00
|
|
|
snprintf(motu->card->longname, sizeof(motu->card->longname),
|
2019-03-17 06:49:29 +00:00
|
|
|
"MOTU %s (version:%06x), GUID %08x%08x at %s, S%d",
|
2017-03-22 12:30:13 +00:00
|
|
|
motu->spec->name, version,
|
2017-03-22 12:30:11 +00:00
|
|
|
fw_dev->config_rom[3], fw_dev->config_rom[4],
|
|
|
|
dev_name(&motu->unit->device), 100 << fw_dev->max_speed);
|
|
|
|
}
|
|
|
|
|
2018-10-10 06:35:02 +00:00
|
|
|
static void motu_card_free(struct snd_card *card)
|
2017-03-22 12:30:11 +00:00
|
|
|
{
|
2018-10-10 06:35:02 +00:00
|
|
|
struct snd_motu *motu = card->private_data;
|
2017-03-22 12:30:19 +00:00
|
|
|
|
2018-10-10 06:35:02 +00:00
|
|
|
snd_motu_transaction_unregister(motu);
|
2017-03-22 12:30:20 +00:00
|
|
|
snd_motu_stream_destroy_duplex(motu);
|
2017-03-22 12:30:11 +00:00
|
|
|
}
|
|
|
|
|
2017-03-22 12:30:12 +00:00
|
|
|
static void do_registration(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct snd_motu *motu = container_of(work, struct snd_motu, dwork.work);
|
|
|
|
int err;
|
2017-03-22 12:30:11 +00:00
|
|
|
|
2017-03-22 12:30:12 +00:00
|
|
|
if (motu->registered)
|
|
|
|
return;
|
2017-03-22 12:30:11 +00:00
|
|
|
|
2017-03-22 12:30:12 +00:00
|
|
|
err = snd_card_new(&motu->unit->device, -1, NULL, THIS_MODULE, 0,
|
|
|
|
&motu->card);
|
|
|
|
if (err < 0)
|
|
|
|
return;
|
2018-10-10 06:35:02 +00:00
|
|
|
motu->card->private_free = motu_card_free;
|
|
|
|
motu->card->private_data = motu;
|
2017-03-22 12:30:11 +00:00
|
|
|
|
|
|
|
name_card(motu);
|
|
|
|
|
2017-03-22 12:30:19 +00:00
|
|
|
err = snd_motu_transaction_register(motu);
|
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
2017-03-22 12:30:20 +00:00
|
|
|
err = snd_motu_stream_init_duplex(motu);
|
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
2017-03-22 12:30:21 +00:00
|
|
|
snd_motu_proc_init(motu);
|
|
|
|
|
2017-03-22 12:30:22 +00:00
|
|
|
err = snd_motu_create_pcm_devices(motu);
|
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
2017-08-20 12:25:03 +00:00
|
|
|
if ((motu->spec->flags & SND_MOTU_SPEC_RX_MIDI_2ND_Q) ||
|
|
|
|
(motu->spec->flags & SND_MOTU_SPEC_RX_MIDI_3RD_Q) ||
|
|
|
|
(motu->spec->flags & SND_MOTU_SPEC_TX_MIDI_2ND_Q) ||
|
|
|
|
(motu->spec->flags & SND_MOTU_SPEC_TX_MIDI_3RD_Q)) {
|
2017-03-22 12:30:23 +00:00
|
|
|
err = snd_motu_create_midi_devices(motu);
|
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2017-03-22 12:30:24 +00:00
|
|
|
err = snd_motu_create_hwdep_device(motu);
|
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
2017-03-22 12:30:12 +00:00
|
|
|
err = snd_card_register(motu->card);
|
2017-03-22 12:30:11 +00:00
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
2017-03-22 12:30:12 +00:00
|
|
|
motu->registered = true;
|
|
|
|
|
|
|
|
return;
|
|
|
|
error:
|
|
|
|
snd_card_free(motu->card);
|
|
|
|
dev_info(&motu->unit->device,
|
|
|
|
"Sound card registration failed: %d\n", err);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int motu_probe(struct fw_unit *unit,
|
|
|
|
const struct ieee1394_device_id *entry)
|
|
|
|
{
|
|
|
|
struct snd_motu *motu;
|
|
|
|
|
|
|
|
/* Allocate this independently of sound card instance. */
|
2018-10-02 23:21:50 +00:00
|
|
|
motu = devm_kzalloc(&unit->device, sizeof(struct snd_motu), GFP_KERNEL);
|
|
|
|
if (!motu)
|
2017-03-22 12:30:12 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
motu->unit = fw_unit_get(unit);
|
2017-03-22 12:30:11 +00:00
|
|
|
dev_set_drvdata(&unit->device, motu);
|
|
|
|
|
2018-10-02 23:21:50 +00:00
|
|
|
motu->spec = (const struct snd_motu_spec *)entry->driver_data;
|
2017-03-22 12:30:12 +00:00
|
|
|
mutex_init(&motu->mutex);
|
2017-03-22 12:30:23 +00:00
|
|
|
spin_lock_init(&motu->lock);
|
2017-03-22 12:30:24 +00:00
|
|
|
init_waitqueue_head(&motu->hwdep_wait);
|
2017-03-22 12:30:12 +00:00
|
|
|
|
|
|
|
/* Allocate and register this sound card later. */
|
|
|
|
INIT_DEFERRABLE_WORK(&motu->dwork, do_registration);
|
|
|
|
snd_fw_schedule_registration(unit, &motu->dwork);
|
|
|
|
|
2017-03-22 12:30:11 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void motu_remove(struct fw_unit *unit)
|
|
|
|
{
|
|
|
|
struct snd_motu *motu = dev_get_drvdata(&unit->device);
|
|
|
|
|
2017-03-22 12:30:12 +00:00
|
|
|
/*
|
|
|
|
* Confirm to stop the work for registration before the sound card is
|
|
|
|
* going to be released. The work is not scheduled again because bus
|
|
|
|
* reset handler is not called anymore.
|
|
|
|
*/
|
|
|
|
cancel_delayed_work_sync(&motu->dwork);
|
|
|
|
|
|
|
|
if (motu->registered) {
|
2018-10-10 06:34:59 +00:00
|
|
|
// Block till all of ALSA character devices are released.
|
|
|
|
snd_card_free(motu->card);
|
2017-03-22 12:30:12 +00:00
|
|
|
}
|
2018-10-10 06:35:00 +00:00
|
|
|
|
|
|
|
mutex_destroy(&motu->mutex);
|
|
|
|
fw_unit_put(motu->unit);
|
2017-03-22 12:30:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void motu_bus_update(struct fw_unit *unit)
|
|
|
|
{
|
2017-03-22 12:30:12 +00:00
|
|
|
struct snd_motu *motu = dev_get_drvdata(&unit->device);
|
|
|
|
|
|
|
|
/* Postpone a workqueue for deferred registration. */
|
|
|
|
if (!motu->registered)
|
|
|
|
snd_fw_schedule_registration(unit, &motu->dwork);
|
2017-03-22 12:30:19 +00:00
|
|
|
|
|
|
|
/* The handler address register becomes initialized. */
|
|
|
|
snd_motu_transaction_reregister(motu);
|
2017-03-22 12:30:11 +00:00
|
|
|
}
|
|
|
|
|
2017-08-22 13:58:15 +00:00
|
|
|
static const struct snd_motu_spec motu_828mk2 = {
|
2017-03-22 12:30:26 +00:00
|
|
|
.name = "828mk2",
|
|
|
|
.protocol = &snd_motu_protocol_v2,
|
|
|
|
.flags = SND_MOTU_SPEC_SUPPORT_CLOCK_X2 |
|
|
|
|
SND_MOTU_SPEC_TX_MICINST_CHUNK |
|
|
|
|
SND_MOTU_SPEC_TX_RETURN_CHUNK |
|
2018-06-18 12:07:52 +00:00
|
|
|
SND_MOTU_SPEC_RX_SEPARETED_MAIN |
|
2017-03-22 12:30:26 +00:00
|
|
|
SND_MOTU_SPEC_HAS_OPT_IFACE_A |
|
2017-08-20 12:25:03 +00:00
|
|
|
SND_MOTU_SPEC_RX_MIDI_2ND_Q |
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_2ND_Q,
|
2017-03-22 12:30:26 +00:00
|
|
|
|
|
|
|
.analog_in_ports = 8,
|
|
|
|
.analog_out_ports = 8,
|
|
|
|
};
|
|
|
|
|
ALSA: firewire-motu: add support for Motu Traveler
This commit adds support for MOTU Traveler, launched in 2005, discontinued
quite before. As a result, transmission of PCM frame and MIDI messages is
available via ALSA PCM and RawMIDI/Sequencer interfaces.
This model supports sampling transmission frequency up to 192.0 kHz, and
AES/EBU on XLR interface and ADAT on optical interface. Unlike
Motu 828MkII, Windows driver can switch fetching mode for DSP, like
mute/unmute feature.
Although this commit enables high sampling transmission frequency, actual
sound from this model is not good. As long as I tested, it's silence at
176.4 kHz, and it includes hissing noise at 192.0 kHz. In my opinion, as I
reported at 3526ce7f9ba7 ('ALSA: firewire-motu: add MOTU specific protocol
layer'), timestamping on source packet header (SPH) may not still be good
for this model as well.
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04106505 bus_info_length 4, crc_length 16, crc 25861
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 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32f
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 00035955 directory_length 3, crc 22869
42c 120001f2 specifier id
430 13000009 version
434 17107800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 000206b2 leaf_length 2, crc 1714
43c 0001f200 company_id 0001f2 |
440 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32f
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-06-18 12:07:55 +00:00
|
|
|
const struct snd_motu_spec snd_motu_spec_traveler = {
|
|
|
|
.name = "Traveler",
|
|
|
|
.protocol = &snd_motu_protocol_v2,
|
|
|
|
.flags = SND_MOTU_SPEC_SUPPORT_CLOCK_X2 |
|
|
|
|
SND_MOTU_SPEC_SUPPORT_CLOCK_X4 |
|
|
|
|
SND_MOTU_SPEC_TX_RETURN_CHUNK |
|
|
|
|
SND_MOTU_SPEC_HAS_AESEBU_IFACE |
|
|
|
|
SND_MOTU_SPEC_HAS_OPT_IFACE_A |
|
|
|
|
SND_MOTU_SPEC_RX_MIDI_2ND_Q |
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_2ND_Q,
|
|
|
|
|
|
|
|
.analog_in_ports = 8,
|
|
|
|
.analog_out_ports = 8,
|
|
|
|
};
|
|
|
|
|
ALSA: firewire-motu: add support MOTU 8pre FireWire
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-03-17 07:50:24 +00:00
|
|
|
const struct snd_motu_spec snd_motu_spec_8pre = {
|
|
|
|
.name = "8pre",
|
|
|
|
.protocol = &snd_motu_protocol_v2,
|
|
|
|
// In tx, use coax chunks for mix-return 1/2. In rx, use coax chunks for
|
|
|
|
// dummy 1/2.
|
|
|
|
.flags = SND_MOTU_SPEC_SUPPORT_CLOCK_X2 |
|
|
|
|
SND_MOTU_SPEC_HAS_OPT_IFACE_A |
|
|
|
|
SND_MOTU_SPEC_HAS_OPT_IFACE_B |
|
|
|
|
SND_MOTU_SPEC_RX_MIDI_2ND_Q |
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_2ND_Q,
|
|
|
|
.analog_in_ports = 8,
|
|
|
|
.analog_out_ports = 2,
|
|
|
|
};
|
|
|
|
|
2017-08-22 13:58:15 +00:00
|
|
|
static const struct snd_motu_spec motu_828mk3 = {
|
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>
2017-03-22 12:30:28 +00:00
|
|
|
.name = "828mk3",
|
|
|
|
.protocol = &snd_motu_protocol_v3,
|
|
|
|
.flags = SND_MOTU_SPEC_SUPPORT_CLOCK_X2 |
|
|
|
|
SND_MOTU_SPEC_SUPPORT_CLOCK_X4 |
|
|
|
|
SND_MOTU_SPEC_TX_MICINST_CHUNK |
|
|
|
|
SND_MOTU_SPEC_TX_RETURN_CHUNK |
|
|
|
|
SND_MOTU_SPEC_TX_REVERB_CHUNK |
|
2018-06-18 12:07:52 +00:00
|
|
|
SND_MOTU_SPEC_RX_SEPARETED_MAIN |
|
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>
2017-03-22 12:30:28 +00:00
|
|
|
SND_MOTU_SPEC_HAS_OPT_IFACE_A |
|
|
|
|
SND_MOTU_SPEC_HAS_OPT_IFACE_B |
|
2017-08-20 12:25:03 +00:00
|
|
|
SND_MOTU_SPEC_RX_MIDI_3RD_Q |
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_3RD_Q,
|
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>
2017-03-22 12:30:28 +00:00
|
|
|
|
|
|
|
.analog_in_ports = 8,
|
|
|
|
.analog_out_ports = 8,
|
|
|
|
};
|
|
|
|
|
2017-08-22 13:58:15 +00:00
|
|
|
static const struct snd_motu_spec motu_audio_express = {
|
ALSA: firewire-motu: add support for MOTU Audio Express
MOTU Audio Express is one of third generation in MOTU FireWire
series, produced in 2011. This model consists of three chips:
* TI TSB41AB2 (Physical layer for IEEE 1394 bus)
* Microchip USB3300 (Hi-Speed USB Device with ULPI interface)
* Xilinx Spartan-3A FPGA, XC3S400A (Link layer for IEEE 1394 bus, packet
processing and data block processing layer)
This commit adds support for this model. As I expected, it works with
current implementaion of protocol version 3. On the other hand, the unit
has a quirk to request subaction originated by any driver.
11:45:51.287643 firewire_ohci 0000:03:00.0: AT spd 2 tl 1f, ffc1 -> ffc0, -reserved-, QW req, fffff0000b14 = 02000200
11:45:51.289193 firewire_ohci 0000:03:00.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, W resp
11:45:51.289381 fireire_core 0000:03:00.0: unsolicited response (source ffc0, tlabel 1f)
11:45:51.313071 firewire_ohci 0000:03:00.0: AT spd 2 tl 20, ffc1 -> ffc0, ack_pending , QW req, fffff0000b14 = 02000200
11:45:51.314539 firewire_ohci 0000:03:00.0: AR spd 2 tl 20, ffc0 -> ffc1, ack_complete, W resp
In 1394 OHCI (rev.1.1), after OUTPUT_LAST* descriptors is processed,
'xferStaus' field is filled with 'ContextControl[0:15]' (see clause 7.1.3).
5 bits in LSB side of the field has ack code in acknowledge from the unit
(see clause 7.2.2). A list of the code is shown in Table 3-2.
As long as I investigated, in a case of the '-reserved-' acknowledge
message from the unit, the field has 0x10. On the table, this value is
'Reserved for definition by future 1394 standards'. As long as I know,
any specifications of IEEE 1394 has no such extensions, thus the unit is
out of specification. Besides, I note that the unit does not always
acknowledge with the invalid code. I guess this is a bug of firmware. I
confirmed the bug in firmware version 1.04 and this is the latest one.
$ cd linux-firewire-utils
$ python2 ./src/crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410a756 bus_info_length 4, crc_length 16, crc 42838
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7b
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00031680 directory_length 3, crc 5760
42c 120001f2 specifier id
430 13000033 version
434 17104800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 00025ef3 leaf_length 2, crc 24307
43c 0001f200 company_id 0001f2 |
440 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7b
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-08-20 12:25:04 +00:00
|
|
|
.name = "AudioExpress",
|
|
|
|
.protocol = &snd_motu_protocol_v3,
|
|
|
|
.flags = SND_MOTU_SPEC_SUPPORT_CLOCK_X2 |
|
|
|
|
SND_MOTU_SPEC_TX_MICINST_CHUNK |
|
|
|
|
SND_MOTU_SPEC_TX_RETURN_CHUNK |
|
2018-06-18 12:07:52 +00:00
|
|
|
SND_MOTU_SPEC_RX_SEPARETED_MAIN |
|
ALSA: firewire-motu: add support for MOTU Audio Express
MOTU Audio Express is one of third generation in MOTU FireWire
series, produced in 2011. This model consists of three chips:
* TI TSB41AB2 (Physical layer for IEEE 1394 bus)
* Microchip USB3300 (Hi-Speed USB Device with ULPI interface)
* Xilinx Spartan-3A FPGA, XC3S400A (Link layer for IEEE 1394 bus, packet
processing and data block processing layer)
This commit adds support for this model. As I expected, it works with
current implementaion of protocol version 3. On the other hand, the unit
has a quirk to request subaction originated by any driver.
11:45:51.287643 firewire_ohci 0000:03:00.0: AT spd 2 tl 1f, ffc1 -> ffc0, -reserved-, QW req, fffff0000b14 = 02000200
11:45:51.289193 firewire_ohci 0000:03:00.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, W resp
11:45:51.289381 fireire_core 0000:03:00.0: unsolicited response (source ffc0, tlabel 1f)
11:45:51.313071 firewire_ohci 0000:03:00.0: AT spd 2 tl 20, ffc1 -> ffc0, ack_pending , QW req, fffff0000b14 = 02000200
11:45:51.314539 firewire_ohci 0000:03:00.0: AR spd 2 tl 20, ffc0 -> ffc1, ack_complete, W resp
In 1394 OHCI (rev.1.1), after OUTPUT_LAST* descriptors is processed,
'xferStaus' field is filled with 'ContextControl[0:15]' (see clause 7.1.3).
5 bits in LSB side of the field has ack code in acknowledge from the unit
(see clause 7.2.2). A list of the code is shown in Table 3-2.
As long as I investigated, in a case of the '-reserved-' acknowledge
message from the unit, the field has 0x10. On the table, this value is
'Reserved for definition by future 1394 standards'. As long as I know,
any specifications of IEEE 1394 has no such extensions, thus the unit is
out of specification. Besides, I note that the unit does not always
acknowledge with the invalid code. I guess this is a bug of firmware. I
confirmed the bug in firmware version 1.04 and this is the latest one.
$ cd linux-firewire-utils
$ python2 ./src/crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410a756 bus_info_length 4, crc_length 16, crc 42838
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7b
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00031680 directory_length 3, crc 5760
42c 120001f2 specifier id
430 13000033 version
434 17104800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 00025ef3 leaf_length 2, crc 24307
43c 0001f200 company_id 0001f2 |
440 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7b
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-08-20 12:25:04 +00:00
|
|
|
SND_MOTU_SPEC_RX_MIDI_2ND_Q |
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_3RD_Q,
|
|
|
|
.analog_in_ports = 2,
|
|
|
|
.analog_out_ports = 4,
|
|
|
|
};
|
|
|
|
|
ALSA: firewire-motu: add support for MOTU 4pre
MOTU 4pre was launched in 2012 by MOTU, Inc. This commit allows userspace
applications can transmit and receive PCM frames and MIDI messages for
this model via ALSA PCM interface and RawMidi/Sequencer interfaces.
The device supports MOTU protocol version 3. Unlike the other devices, the
device is simply designed. The size of data block is fixed to 10 quadlets
during available sampling rates (44.1 - 96.0 kHz). Each data block
includes 1 source packet header, 2 data chunks for messages, 8 data chunks
for PCM samples and 2 data chunks for padding to quadlet alignment. The
device has no MIDI, optical, BNC and AES/EBU interfaces.
Like support for the other MOTU devices, the quality of playback sound
is not enough good with periodical noise yet.
$ python2 crpp < ~/git/am-config-rom/motu/motu-4pre.img
ROM header and bus information block
-----------------------------------------------------------------
400 041078cc bus_info_length 4, crc_length 16, crc 30924
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a41c5 device_id 00000a41c5 | EUI-64 0001f200000a41c5
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 0003ceda directory_length 3, crc 52954
42c 120001f2 specifier id
430 13000045 version
434 17103800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002d248 leaf_length 2, crc 53832
43c 0001f200 company_id 0001f2 |
440 000a41c5 device_id 00000a41c5 | EUI-64 0001f200000a41c5
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-30 01:14:56 +00:00
|
|
|
static const struct snd_motu_spec motu_4pre = {
|
|
|
|
.name = "4pre",
|
|
|
|
.protocol = &snd_motu_protocol_v3,
|
|
|
|
.flags = SND_MOTU_SPEC_SUPPORT_CLOCK_X2 |
|
|
|
|
SND_MOTU_SPEC_TX_MICINST_CHUNK |
|
|
|
|
SND_MOTU_SPEC_TX_RETURN_CHUNK |
|
|
|
|
SND_MOTU_SPEC_RX_SEPARETED_MAIN,
|
|
|
|
.analog_in_ports = 2,
|
|
|
|
.analog_out_ports = 2,
|
|
|
|
};
|
|
|
|
|
2017-03-22 12:30:13 +00:00
|
|
|
#define SND_MOTU_DEV_ENTRY(model, data) \
|
2017-03-22 12:30:11 +00:00
|
|
|
{ \
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID | \
|
2019-03-17 06:49:29 +00:00
|
|
|
IEEE1394_MATCH_SPECIFIER_ID | \
|
|
|
|
IEEE1394_MATCH_VERSION, \
|
2017-03-22 12:30:11 +00:00
|
|
|
.vendor_id = OUI_MOTU, \
|
|
|
|
.specifier_id = OUI_MOTU, \
|
2019-03-17 06:49:29 +00:00
|
|
|
.version = model, \
|
2017-03-22 12:30:13 +00:00
|
|
|
.driver_data = (kernel_ulong_t)data, \
|
2017-03-22 12:30:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct ieee1394_device_id motu_id_table[] = {
|
2019-03-17 06:49:29 +00:00
|
|
|
SND_MOTU_DEV_ENTRY(0x000003, &motu_828mk2),
|
|
|
|
SND_MOTU_DEV_ENTRY(0x000009, &snd_motu_spec_traveler),
|
ALSA: firewire-motu: add support MOTU 8pre FireWire
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-03-17 07:50:24 +00:00
|
|
|
SND_MOTU_DEV_ENTRY(0x00000f, &snd_motu_spec_8pre),
|
2019-03-17 06:49:29 +00:00
|
|
|
SND_MOTU_DEV_ENTRY(0x000015, &motu_828mk3), /* FireWire only. */
|
|
|
|
SND_MOTU_DEV_ENTRY(0x000035, &motu_828mk3), /* Hybrid. */
|
|
|
|
SND_MOTU_DEV_ENTRY(0x000033, &motu_audio_express),
|
ALSA: firewire-motu: add support for MOTU 4pre
MOTU 4pre was launched in 2012 by MOTU, Inc. This commit allows userspace
applications can transmit and receive PCM frames and MIDI messages for
this model via ALSA PCM interface and RawMidi/Sequencer interfaces.
The device supports MOTU protocol version 3. Unlike the other devices, the
device is simply designed. The size of data block is fixed to 10 quadlets
during available sampling rates (44.1 - 96.0 kHz). Each data block
includes 1 source packet header, 2 data chunks for messages, 8 data chunks
for PCM samples and 2 data chunks for padding to quadlet alignment. The
device has no MIDI, optical, BNC and AES/EBU interfaces.
Like support for the other MOTU devices, the quality of playback sound
is not enough good with periodical noise yet.
$ python2 crpp < ~/git/am-config-rom/motu/motu-4pre.img
ROM header and bus information block
-----------------------------------------------------------------
400 041078cc bus_info_length 4, crc_length 16, crc 30924
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a41c5 device_id 00000a41c5 | EUI-64 0001f200000a41c5
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 0003ceda directory_length 3, crc 52954
42c 120001f2 specifier id
430 13000045 version
434 17103800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002d248 leaf_length 2, crc 53832
43c 0001f200 company_id 0001f2 |
440 000a41c5 device_id 00000a41c5 | EUI-64 0001f200000a41c5
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-30 01:14:56 +00:00
|
|
|
SND_MOTU_DEV_ENTRY(0x000045, &motu_4pre),
|
2017-03-22 12:30:11 +00:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(ieee1394, motu_id_table);
|
|
|
|
|
|
|
|
static struct fw_driver motu_driver = {
|
|
|
|
.driver = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.name = KBUILD_MODNAME,
|
|
|
|
.bus = &fw_bus_type,
|
|
|
|
},
|
|
|
|
.probe = motu_probe,
|
|
|
|
.update = motu_bus_update,
|
|
|
|
.remove = motu_remove,
|
|
|
|
.id_table = motu_id_table,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init alsa_motu_init(void)
|
|
|
|
{
|
|
|
|
return driver_register(&motu_driver.driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit alsa_motu_exit(void)
|
|
|
|
{
|
|
|
|
driver_unregister(&motu_driver.driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(alsa_motu_init);
|
|
|
|
module_exit(alsa_motu_exit);
|