linux_dsm_epyc7002/sound/firewire/oxfw/oxfw.c

447 lines
11 KiB
C
Raw Normal View History

/*
* oxfw.c - a part of driver for OXFW970/971 based devices
*
* Copyright (c) Clemens Ladisch <clemens@ladisch.de>
* Licensed under the terms of the GNU General Public License, version 2.
*/
#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
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 19:18:55 +07: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 09:36:08 +07: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_free(struct snd_oxfw *oxfw)
{
snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->rx_stream);
if (oxfw->has_output)
snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->tx_stream);
mutex_destroy(&oxfw->mutex);
fw_unit_put(oxfw->unit);
}
/*
* This module releases the FireWire unit data after all ALSA character devices
* are released by applications. This is for releasing stream data or finishing
* transactions safely. Thus at returning from .remove(), this module still keep
* references for the unit.
*/
static void oxfw_card_free(struct snd_card *card)
{
oxfw_free(card->private_data);
}
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 19:18:55 +07: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;
/* Output stream exists but no data channels are useful. */
oxfw->has_output = false;
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 19:18:55 +07: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 19:18:55 +07: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;
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 19:18:55 +07:00
err = snd_oxfw_stream_init_simplex(oxfw, &oxfw->rx_stream);
if (err < 0)
goto error;
if (oxfw->has_output) {
err = snd_oxfw_stream_init_simplex(oxfw, &oxfw->tx_stream);
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;
/*
* After registered, oxfw instance can be released corresponding to
* releasing the sound card instance.
*/
oxfw->card->private_free = oxfw_card_free;
oxfw->card->private_data = oxfw;
oxfw->registered = true;
return;
error:
snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->rx_stream);
if (oxfw->has_output)
snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->tx_stream);
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) {
mutex_lock(&oxfw->mutex);
ALSA: oxfw: Add support AMDTP in-stream Previous commit adds support for some devices which can capture PCM samples. These devices transmit AMDTP stream in non-blocking mode. This commit adds functionality to handle AMDTP incoming stream. OXFW seems to have two quirks: - Transmits packets with non-zero dbc in its beginning - Transmits packets with wrong values in syt field For the first quirk, this commit adds CIP_SKIP_INIT_DBC_CHECK flag for incoming stream to skip first check of dbc. For the second quirk, this commit doesn't add duplex stream which Fireworks/BeBoB drivers use. So OXFW driver generates syt value for outgoing stream. Here are examples of a sequence of packets transmitted by Behringer F-Control Audio 202. There are differences between sequences of syt value when OXFW driver transfers outgoing stream or not. When driver gives no outgoing stream: Index Payload CIP_Header_0 CIP_Header_1 38 14 00020092 900103D1 39 12 00020098 900102FF 40 12 0002009D 9001027F 41 14 000200A2 90010396 42 14 000200A8 900102E8 43 12 000200AE 90010219 44 14 000200B3 90010331 45 12 000200B9 9001025F 46 14 000200BE 90010376 47 12 000200C4 900102A1 00 12 000200C9 9001023E 01 14 000200CE 90010358 02 12 000200D4 90010289 03 16 000200D9 900103A3 04 12 000200E0 900102DD 05 14 000200E5 900103F1 06 12 000200EB 90010335 07 12 000200F0 90010263 08 14 000200F5 9001037C 09 12 000200FB 900102AE When driver gives outgoing stream: Index Payload CIP_Header_0 CIP_Header_1 38 12 000200BD 900104A8 39 14 000200C2 900104A8 40 12 000200C8 900104AC 41 14 000200CD 900104A9 42 12 000200D3 900104B1 43 14 000200D8 900104A8 44 12 000200DE 900104AA 45 14 000200E3 900104A9 46 14 000200E9 900104AE 47 12 000200EF 900104A8 00 14 000200F4 900104AD 01 12 000200FA 900104A7 02 14 000200FF 900104A9 03 12 00020005 900104A9 04 14 0002000A 900104B1 05 12 00020010 900104AA 06 14 00020015 900104AD 07 12 0002001B 900104A7 08 14 00020020 900104AC 09 12 00020026 900104A7 Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-12-08 22:10:46 +07:00
snd_oxfw_stream_update_simplex(oxfw, &oxfw->rx_stream);
if (oxfw->has_output)
snd_oxfw_stream_update_simplex(oxfw, &oxfw->tx_stream);
ALSA: oxfw: Add support AMDTP in-stream Previous commit adds support for some devices which can capture PCM samples. These devices transmit AMDTP stream in non-blocking mode. This commit adds functionality to handle AMDTP incoming stream. OXFW seems to have two quirks: - Transmits packets with non-zero dbc in its beginning - Transmits packets with wrong values in syt field For the first quirk, this commit adds CIP_SKIP_INIT_DBC_CHECK flag for incoming stream to skip first check of dbc. For the second quirk, this commit doesn't add duplex stream which Fireworks/BeBoB drivers use. So OXFW driver generates syt value for outgoing stream. Here are examples of a sequence of packets transmitted by Behringer F-Control Audio 202. There are differences between sequences of syt value when OXFW driver transfers outgoing stream or not. When driver gives no outgoing stream: Index Payload CIP_Header_0 CIP_Header_1 38 14 00020092 900103D1 39 12 00020098 900102FF 40 12 0002009D 9001027F 41 14 000200A2 90010396 42 14 000200A8 900102E8 43 12 000200AE 90010219 44 14 000200B3 90010331 45 12 000200B9 9001025F 46 14 000200BE 90010376 47 12 000200C4 900102A1 00 12 000200C9 9001023E 01 14 000200CE 90010358 02 12 000200D4 90010289 03 16 000200D9 900103A3 04 12 000200E0 900102DD 05 14 000200E5 900103F1 06 12 000200EB 90010335 07 12 000200F0 90010263 08 14 000200F5 9001037C 09 12 000200FB 900102AE When driver gives outgoing stream: Index Payload CIP_Header_0 CIP_Header_1 38 12 000200BD 900104A8 39 14 000200C2 900104A8 40 12 000200C8 900104AC 41 14 000200CD 900104A9 42 12 000200D3 900104B1 43 14 000200D8 900104A8 44 12 000200DE 900104AA 45 14 000200E3 900104A9 46 14 000200E9 900104AE 47 12 000200EF 900104A8 00 14 000200F4 900104AD 01 12 000200FA 900104A7 02 14 000200FF 900104A9 03 12 00020005 900104A9 04 14 0002000A 900104B1 05 12 00020010 900104AA 06 14 00020015 900104AD 07 12 0002001B 900104A7 08 14 00020020 900104AC 09 12 00020026 900104A7 Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-12-08 22:10:46 +07:00
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);
} else {
/* Don't forget this case. */
oxfw_free(oxfw);
}
}
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,
},
{ }
};
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);