linux/sound/firewire/oxfw/oxfw.c

427 lines
10 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* oxfw.c - a part of driver for OXFW970/971 based devices
*
* Copyright (c) Clemens Ladisch <clemens@ladisch.de>
*/
#include "oxfw.h"
#define OXFORD_FIRMWARE_ID_ADDRESS (CSR_REGISTER_BASE + 0x50000)
/* 0x970?vvvv or 0x971?vvvv, where vvvv = firmware version */
#define OXFORD_HARDWARE_ID_ADDRESS (CSR_REGISTER_BASE + 0x90020)
#define OXFORD_HARDWARE_ID_OXFW970 0x39443841
#define OXFORD_HARDWARE_ID_OXFW971 0x39373100
#define VENDOR_LOUD 0x000ff2
#define VENDOR_GRIFFIN 0x001292
#define VENDOR_BEHRINGER 0x001564
#define VENDOR_LACIE 0x00d04b
#define VENDOR_TASCAM 0x00022e
#define OUI_STANTON 0x001260
#define OUI_APOGEE 0x0003db
ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-20 20:18:55 +08:00
#define MODEL_SATELLITE 0x00200f
#define SPECIFIER_1394TA 0x00a02d
#define VERSION_AVC 0x010001
MODULE_DESCRIPTION("Oxford Semiconductor FW970/971 driver");
MODULE_AUTHOR("Clemens Ladisch <clemens@ladisch.de>");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("snd-firewire-speakers");
MODULE_ALIAS("snd-scs1x");
struct compat_info {
const char *driver_name;
const char *vendor_name;
const char *model_name;
};
static bool detect_loud_models(struct fw_unit *unit)
{
const char *const models[] = {
"Onyxi",
"Onyx-i",
ALSA: oxfw: add support for Mackie Onyx 1640i As of kernel 4.10, ALSA OXFW driver has no entry for Onyx 1640i produced by Mackie (Loud Technologies). This commit supplement it. I note that there're two models produced by Mackie (Loud Technologies), which have the same name 'Onyx 1640i'. The former model based on OXFW970, the latter model based on Dice. This is probably due to low quality of communication of OXFW series. Additionally, the tester reports his or her experiences to get unexpected result at higher sampling transmission frequency as 88.2/96.0 kHz. We didn't have further investigation yet[0]. $ ./linux-firewire-utils/src/crpp < config_rom ROM header and bus information block ----------------------------------------------------------------- 400 042525ce bus_info_length 4, crc_length 37, crc 9678 404 31333934 bus_name "1394" 408 20ff5003 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64) 40c 000ff205 company_id 000ff2 | 410 00000fcf device_id 0500000fcf | EUI-64 000ff20500000fcf root directory ----------------------------------------------------------------- 414 0006c1b7 directory_length 6, crc 49591 418 03000ff2 vendor 41c 8100000a --> descriptor leaf at 444 420 17001640 model 424 81000011 --> descriptor leaf at 468 428 0c0083c0 node capabilities per IEEE 1394 42c d1000001 --> unit directory at 430 unit directory at 430 ----------------------------------------------------------------- 430 00040b97 directory_length 4, crc 2967 434 1200a02d specifier id: 1394 TA 438 13010001 version: AV/C 43c 17001640 model 440 81000010 --> descriptor leaf at 480 descriptor leaf at 444 ----------------------------------------------------------------- 444 0008a886 leaf_length 8, crc 43142 448 00000000 textual descriptor 44c 00000000 minimal ASCII 450 4c6f7564 "Loud" 454 20546563 " Tec" 458 686e6f6c "hnol" 45c 6f676965 "ogie" 460 7320496e "s In" 464 632e0000 "c." descriptor leaf at 468 ----------------------------------------------------------------- 468 00059fcf leaf_length 5, crc 40911 46c 00000000 textual descriptor 470 00000000 minimal ASCII 474 4f6e7978 "Onyx" 478 20313634 " 164" 47c 30690000 "0i" descriptor leaf at 480 ----------------------------------------------------------------- 480 00059fcf leaf_length 5, crc 40911 484 00000000 textual descriptor 488 00000000 minimal ASCII 48c 4f6e7978 "Onyx" 490 20313634 " 164" 494 30690000 "0i" [0]: [FFADO-user] Mackie 1640i issues (finer details) https://sourceforge.net/p/ffado/mailman/message/35229260/ Tested-by: Seth O'Bannion <saobannion@gmail.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-01-03 10:36:08 +08:00
"Onyx 1640i",
"d.Pro",
"Mackie Onyx Satellite",
"Tapco LINK.firewire 4x6",
"U.420"};
char model[32];
int err;
err = fw_csr_string(unit->directory, CSR_MODEL,
model, sizeof(model));
if (err < 0)
return false;
return match_string(models, ARRAY_SIZE(models), model) >= 0;
}
static int name_card(struct snd_oxfw *oxfw)
{
struct fw_device *fw_dev = fw_parent_device(oxfw->unit);
const struct compat_info *info;
char vendor[24];
char model[32];
const char *d, *v, *m;
u32 firmware;
int err;
/* get vendor name from root directory */
err = fw_csr_string(fw_dev->config_rom + 5, CSR_VENDOR,
vendor, sizeof(vendor));
if (err < 0)
goto end;
/* get model name from unit directory */
err = fw_csr_string(oxfw->unit->directory, CSR_MODEL,
model, sizeof(model));
if (err < 0)
goto end;
err = snd_fw_transaction(oxfw->unit, TCODE_READ_QUADLET_REQUEST,
OXFORD_FIRMWARE_ID_ADDRESS, &firmware, 4, 0);
if (err < 0)
goto end;
be32_to_cpus(&firmware);
/* to apply card definitions */
if (oxfw->entry->vendor_id == VENDOR_GRIFFIN ||
oxfw->entry->vendor_id == VENDOR_LACIE) {
info = (const struct compat_info *)oxfw->entry->driver_data;
d = info->driver_name;
v = info->vendor_name;
m = info->model_name;
} else {
d = "OXFW";
v = vendor;
m = model;
}
strcpy(oxfw->card->driver, d);
strcpy(oxfw->card->mixername, m);
strcpy(oxfw->card->shortname, m);
snprintf(oxfw->card->longname, sizeof(oxfw->card->longname),
"%s %s (OXFW%x %04x), GUID %08x%08x at %s, S%d",
v, m, firmware >> 20, firmware & 0xffff,
fw_dev->config_rom[3], fw_dev->config_rom[4],
dev_name(&oxfw->unit->device), 100 << fw_dev->max_speed);
end:
return err;
}
static void oxfw_card_free(struct snd_card *card)
{
struct snd_oxfw *oxfw = card->private_data;
if (oxfw->has_output || oxfw->has_input)
snd_oxfw_stream_destroy_duplex(oxfw);
}
static int detect_quirks(struct snd_oxfw *oxfw)
ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-20 20:18:55 +08:00
{
struct fw_device *fw_dev = fw_parent_device(oxfw->unit);
struct fw_csr_iterator it;
int key, val;
int vendor, model;
/*
* Add ALSA control elements for two models to keep compatibility to
* old firewire-speaker module.
*/
if (oxfw->entry->vendor_id == VENDOR_GRIFFIN)
return snd_oxfw_add_spkr(oxfw, false);
if (oxfw->entry->vendor_id == VENDOR_LACIE)
return snd_oxfw_add_spkr(oxfw, true);
/*
* Stanton models supports asynchronous transactions for unique MIDI
* messages.
*/
if (oxfw->entry->vendor_id == OUI_STANTON) {
/* No physical MIDI ports. */
oxfw->midi_input_ports = 0;
oxfw->midi_output_ports = 0;
return snd_oxfw_scs1x_add(oxfw);
}
/*
* TASCAM FireOne has physical control and requires a pair of additional
* MIDI ports.
*/
if (oxfw->entry->vendor_id == VENDOR_TASCAM) {
oxfw->midi_input_ports++;
oxfw->midi_output_ports++;
return 0;
}
ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-20 20:18:55 +08:00
/* Seek from Root Directory of Config ROM. */
vendor = model = 0;
fw_csr_iterator_init(&it, fw_dev->config_rom + 5);
while (fw_csr_iterator_next(&it, &key, &val)) {
if (key == CSR_VENDOR)
vendor = val;
else if (key == CSR_MODEL)
model = val;
}
/*
* Mackie Onyx Satellite with base station has a quirk to report a wrong
* value in 'dbs' field of CIP header against its format information.
*/
if (vendor == VENDOR_LOUD && model == MODEL_SATELLITE)
oxfw->wrong_dbs = true;
return 0;
ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-20 20:18:55 +08:00
}
static void do_registration(struct work_struct *work)
{
struct snd_oxfw *oxfw = container_of(work, struct snd_oxfw, dwork.work);
int err;
if (oxfw->registered)
return;
err = snd_card_new(&oxfw->unit->device, -1, NULL, THIS_MODULE, 0,
&oxfw->card);
if (err < 0)
return;
oxfw->card->private_free = oxfw_card_free;
oxfw->card->private_data = oxfw;
err = name_card(oxfw);
if (err < 0)
goto error;
err = snd_oxfw_stream_discover(oxfw);
if (err < 0)
goto error;
err = detect_quirks(oxfw);
if (err < 0)
goto error;
ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-20 20:18:55 +08:00
if (oxfw->has_output || oxfw->has_input) {
err = snd_oxfw_stream_init_duplex(oxfw);
if (err < 0)
goto error;
err = snd_oxfw_create_pcm(oxfw);
if (err < 0)
goto error;
snd_oxfw_proc_init(oxfw);
err = snd_oxfw_create_midi(oxfw);
if (err < 0)
goto error;
err = snd_oxfw_create_hwdep(oxfw);
if (err < 0)
goto error;
}
err = snd_card_register(oxfw->card);
if (err < 0)
goto error;
oxfw->registered = true;
return;
error:
snd_card_free(oxfw->card);
dev_info(&oxfw->unit->device,
"Sound card registration failed: %d\n", err);
}
static int oxfw_probe(struct fw_unit *unit,
const struct ieee1394_device_id *entry)
{
struct snd_oxfw *oxfw;
if (entry->vendor_id == VENDOR_LOUD && !detect_loud_models(unit))
return -ENODEV;
/* Allocate this independent of sound card instance. */
oxfw = devm_kzalloc(&unit->device, sizeof(struct snd_oxfw), GFP_KERNEL);
if (!oxfw)
return -ENOMEM;
oxfw->unit = fw_unit_get(unit);
dev_set_drvdata(&unit->device, oxfw);
oxfw->entry = entry;
mutex_init(&oxfw->mutex);
spin_lock_init(&oxfw->lock);
init_waitqueue_head(&oxfw->hwdep_wait);
/* Allocate and register this sound card later. */
INIT_DEFERRABLE_WORK(&oxfw->dwork, do_registration);
snd_fw_schedule_registration(unit, &oxfw->dwork);
return 0;
}
static void oxfw_bus_reset(struct fw_unit *unit)
{
struct snd_oxfw *oxfw = dev_get_drvdata(&unit->device);
if (!oxfw->registered)
snd_fw_schedule_registration(unit, &oxfw->dwork);
fcp_bus_reset(oxfw->unit);
if (oxfw->registered) {
if (oxfw->has_output || oxfw->has_input) {
mutex_lock(&oxfw->mutex);
snd_oxfw_stream_update_duplex(oxfw);
mutex_unlock(&oxfw->mutex);
}
if (oxfw->entry->vendor_id == OUI_STANTON)
snd_oxfw_scs1x_update(oxfw);
}
}
static void oxfw_remove(struct fw_unit *unit)
{
struct snd_oxfw *oxfw = dev_get_drvdata(&unit->device);
/*
* 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(&oxfw->dwork);
if (oxfw->registered) {
// Block till all of ALSA character devices are released.
snd_card_free(oxfw->card);
}
mutex_destroy(&oxfw->mutex);
fw_unit_put(oxfw->unit);
}
static const struct compat_info griffin_firewave = {
.driver_name = "FireWave",
.vendor_name = "Griffin",
.model_name = "FireWave",
};
static const struct compat_info lacie_speakers = {
.driver_name = "FWSpeakers",
.vendor_name = "LaCie",
.model_name = "FireWire Speakers",
};
static const struct ieee1394_device_id oxfw_id_table[] = {
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID |
IEEE1394_MATCH_SPECIFIER_ID |
IEEE1394_MATCH_VERSION,
.vendor_id = VENDOR_GRIFFIN,
.model_id = 0x00f970,
.specifier_id = SPECIFIER_1394TA,
.version = VERSION_AVC,
.driver_data = (kernel_ulong_t)&griffin_firewave,
},
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID |
IEEE1394_MATCH_SPECIFIER_ID |
IEEE1394_MATCH_VERSION,
.vendor_id = VENDOR_LACIE,
.model_id = 0x00f970,
.specifier_id = SPECIFIER_1394TA,
.version = VERSION_AVC,
.driver_data = (kernel_ulong_t)&lacie_speakers,
},
/* Behringer,F-Control Audio 202 */
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID,
.vendor_id = VENDOR_BEHRINGER,
.model_id = 0x00fc22,
},
/*
* Any Mackie(Loud) models (name string/model id):
* Onyx-i series (former models): 0x081216
* Mackie Onyx Satellite: 0x00200f
* Tapco LINK.firewire 4x6: 0x000460
* d.2 pro: Unknown
* d.4 pro: Unknown
* U.420: Unknown
* U.420d: Unknown
*/
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_SPECIFIER_ID |
IEEE1394_MATCH_VERSION,
.vendor_id = VENDOR_LOUD,
.specifier_id = SPECIFIER_1394TA,
.version = VERSION_AVC,
},
/* TASCAM, FireOne */
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID,
.vendor_id = VENDOR_TASCAM,
.model_id = 0x800007,
},
/* Stanton, Stanton Controllers & Systems 1 Mixer (SCS.1m) */
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID,
.vendor_id = OUI_STANTON,
.model_id = 0x001000,
},
/* Stanton, Stanton Controllers & Systems 1 Deck (SCS.1d) */
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID,
.vendor_id = OUI_STANTON,
.model_id = 0x002000,
},
// APOGEE, duet FireWire
{
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID,
.vendor_id = OUI_APOGEE,
.model_id = 0x01dddd,
},
{ }
};
MODULE_DEVICE_TABLE(ieee1394, oxfw_id_table);
static struct fw_driver oxfw_driver = {
.driver = {
.owner = THIS_MODULE,
.name = KBUILD_MODNAME,
.bus = &fw_bus_type,
},
.probe = oxfw_probe,
.update = oxfw_bus_reset,
.remove = oxfw_remove,
.id_table = oxfw_id_table,
};
static int __init snd_oxfw_init(void)
{
return driver_register(&oxfw_driver.driver);
}
static void __exit snd_oxfw_exit(void)
{
driver_unregister(&oxfw_driver.driver);
}
module_init(snd_oxfw_init);
module_exit(snd_oxfw_exit);