| Message ID | 1399991272-5807-13-git-send-email-o-takashi@sakamocchi.jp (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Takashi Iwai |
| Headers | show |
Takashi Sakamoto wrote: > Some devices produced by Behringer/Mackie are based on OXFW970/971. This > commit adds support for them. > > +++ b/sound/firewire/oxfw/oxfw.c > @@ -16,6 +16,8 @@ > > #define VENDOR_GRIFFIN 0x001292 > #define VENDOR_LACIE 0x00d04b > +#define VEN_BEHRINGER 0x001564 > +#define VEN_LOUD 0x000ff2 These IDs were supposed to be ordered. :) And why "VEN_" instead of "VENDOR_"? > + ... > + { > + .match_flags = IEEE1394_MATCH_VENDOR_ID | > + IEEE1394_MATCH_MODEL_ID, > + .vendor_id = VEN_LOUD, > + .model_id = 0x000460, > + }, > + /* IDs are unknown but able to be supported */ > + /* Mackie(Loud), d.2 pro */ > + /* Mackie(Loud), d.4 pro */ > + /* Mackie(Loud), U.420 */ > + /* Mackie(Loud), U.420d */ To support all Mackie devices, use one ID entry with only the vendor ID, and abort with -ENODEV from the _probe function if the hardware is not actually an OXFW97x device (try to read the HARDWARE_ID and/or FIRMWARE_ID registers). Regards, Clemens
On Aug 11 2014 00:54, Clemens Ladisch wrote: > Takashi Sakamoto wrote: >> Some devices produced by Behringer/Mackie are based on OXFW970/971. This >> commit adds support for them. >> >> +++ b/sound/firewire/oxfw/oxfw.c >> @@ -16,6 +16,8 @@ >> >> #define VENDOR_GRIFFIN 0x001292 >> #define VENDOR_LACIE 0x00d04b >> +#define VEN_BEHRINGER 0x001564 >> +#define VEN_LOUD 0x000ff2 > > These IDs were supposed to be ordered. :) OK, indeed. > And why "VEN_" instead of "VENDOR_"? I avoided to type three letters "DOR" and use the same way as BeBoB driver. But I don't mind to use "VENDOR_" instead. >> + ... >> + { >> + .match_flags = IEEE1394_MATCH_VENDOR_ID | >> + IEEE1394_MATCH_MODEL_ID, >> + .vendor_id = VEN_LOUD, >> + .model_id = 0x000460, >> + }, >> + /* IDs are unknown but able to be supported */ >> + /* Mackie(Loud), d.2 pro */ >> + /* Mackie(Loud), d.4 pro */ >> + /* Mackie(Loud), U.420 */ >> + /* Mackie(Loud), U.420d */ > > To support all Mackie devices, use one ID entry with only the vendor ID, > and abort with -ENODEV from the _probe function if the hardware is not > actually an OXFW97x device (try to read the HARDWARE_ID and/or > FIRMWARE_ID registers). In this idea, OXFW driver transfers the transaction(s) for all of Mackie(Loud) devices on IEEE 1394 bus when they're probed. I want to avoid such changes possible to affects the other models on the same bus because I'm afraid of side effects. Thanks Takashi Sakamoto o-takashi@sakamocchi.jp
Takashi Sakamoto wrote: > On Aug 11 2014 00:54, Clemens Ladisch wrote: >> Takashi Sakamoto wrote: >>> + /* IDs are unknown but able to be supported */ >>> + /* Mackie(Loud), d.2 pro */ >>> + /* Mackie(Loud), d.4 pro */ >>> + /* Mackie(Loud), U.420 */ >>> + /* Mackie(Loud), U.420d */ >> >> To support all Mackie devices, use one ID entry with only the vendor ID, >> and abort with -ENODEV from the _probe function if the hardware is not >> actually an OXFW97x device (try to read the HARDWARE_ID and/or >> FIRMWARE_ID registers). > > In this idea, OXFW driver transfers the transaction(s) for all of > Mackie(Loud) devices on IEEE 1394 bus when they're probed. I want to > avoid such changes possible to affects the other models on the same bus > because I'm afraid of side effects. The only other known Mackie devices are the 400F/1200F. The Fireworks firmware doesn't blow up if you try to read unsupported registers, but if you want to be sure, you can blacklist these two IDs. Or just do the detection like the Windows driver, through the vendor/ model name strings (this is what my old Fireworks driver did because I didn't know all model IDs; see match_echofire_device_name). The Mackie driver's .inf file has this list of device identifiers: "AVC\Loud_Technologies_Inc.&Onyxi&typ_1" "AVC\Loud_Technologies_Inc.&Onyx_1640i&typ_1" "AVC\Loud_Technologies_Inc.&Onyx-i&typ_1" "AVC\Loud_Technologies_Inc.&d.Pro&typ_1" "AVC\Loud_Technologies_Inc.&Mackie_Onyx_Satellite&typ_1" "AVC\Loud_Technologies_Inc.&Tapco_LINK.firewire_4x6&typ_1" "AVC\Loud_Technologies_Inc.&U.420&typ_1" "AVC\Mackie&Onyx_Firewire&typ_1" (This format is documented at <http://msdn.microsoft.com/en-us/library/windows/hardware/ff556371.aspx>; apparently, spaces are replaced with "_".) Regards, Clemens
On Aug 12 2014 16:33, Clemens Ladisch wrote: > Takashi Sakamoto wrote: >> On Aug 11 2014 00:54, Clemens Ladisch wrote: >>> Takashi Sakamoto wrote: >>>> + /* IDs are unknown but able to be supported */ >>>> + /* Mackie(Loud), d.2 pro */ >>>> + /* Mackie(Loud), d.4 pro */ >>>> + /* Mackie(Loud), U.420 */ >>>> + /* Mackie(Loud), U.420d */ >>> >>> To support all Mackie devices, use one ID entry with only the vendor ID, >>> and abort with -ENODEV from the _probe function if the hardware is not >>> actually an OXFW97x device (try to read the HARDWARE_ID and/or >>> FIRMWARE_ID registers). >> >> In this idea, OXFW driver transfers the transaction(s) for all of >> Mackie(Loud) devices on IEEE 1394 bus when they're probed. I want to >> avoid such changes possible to affects the other models on the same bus >> because I'm afraid of side effects. > > The only other known Mackie devices are the 400F/1200F. The Fireworks > firmware doesn't blow up if you try to read unsupported registers, but > if you want to be sure, you can blacklist these two IDs. As long as I know, Mackie (Loud) produced FireWire sound devices with Fireworks, OXFW and Dice. But I don't know all models at all. There may be models with the other chipset. Furthermore, hardware vendors sometimes add customization to firmware for their models. I think we should not stand on such assumption. > Or just do the detection like the Windows driver, through the vendor/ > model name strings (this is what my old Fireworks driver did because > I didn't know all model IDs; see match_echofire_device_name). The > Mackie driver's .inf file has this list of device identifiers: > > "AVC\Loud_Technologies_Inc.&Onyxi&typ_1" > "AVC\Loud_Technologies_Inc.&Onyx_1640i&typ_1" > "AVC\Loud_Technologies_Inc.&Onyx-i&typ_1" > "AVC\Loud_Technologies_Inc.&d.Pro&typ_1" > "AVC\Loud_Technologies_Inc.&Mackie_Onyx_Satellite&typ_1" > "AVC\Loud_Technologies_Inc.&Tapco_LINK.firewire_4x6&typ_1" > "AVC\Loud_Technologies_Inc.&U.420&typ_1" > "AVC\Mackie&Onyx_Firewire&typ_1" > > (This format is documented at <http://msdn.microsoft.com/en-us/library/windows/hardware/ff556371.aspx>; > apparently, spaces are replaced with "_".) This is a good idea. I note that Mackie Onyx-i series has two revisions. OXFW was used for the former revision. Dice is used for the latter revision. See: http://www.mackie.com/products/onyxiseries/drivers/ When using this idea, we have a need to distinguish these two revisions for prevention from applying OXFW driver to the latter revision. Do you have any good idea? Regards Takashi Sakamoto (In summer vacation) o-takashi@sakamocchi.jp
Takashi Sakamoto wrote: > On Aug 12 2014 16:33, Clemens Ladisch wrote: >> Or just do the detection like the Windows driver, through the vendor/ >> model name strings (this is what my old Fireworks driver did because >> I didn't know all model IDs; see match_echofire_device_name). The >> Mackie driver's .inf file has this list of device identifiers: >> >> "AVC\Loud_Technologies_Inc.&Onyxi&typ_1" >> "AVC\Loud_Technologies_Inc.&Onyx_1640i&typ_1" >> "AVC\Loud_Technologies_Inc.&Onyx-i&typ_1" >> "AVC\Loud_Technologies_Inc.&d.Pro&typ_1" >> "AVC\Loud_Technologies_Inc.&Mackie_Onyx_Satellite&typ_1" >> "AVC\Loud_Technologies_Inc.&Tapco_LINK.firewire_4x6&typ_1" >> "AVC\Loud_Technologies_Inc.&U.420&typ_1" >> "AVC\Mackie&Onyx_Firewire&typ_1" > > This is a good idea. > > I note that Mackie Onyx-i series has two revisions. OXFW was used for > the former revision. Dice is used for the latter revision. See: > http://www.mackie.com/products/onyxiseries/drivers/ > > When using this idea, we have a need to distinguish these two revisions > for prevention from applying OXFW driver to the latter revision. Do you > have any good idea? The OXFW devices work with Core Audio, so they are marked as AV/C devices; the DICE devices are not. So it would be possible to use different specifier_id/version entries. Anyway, the Windows DICE driver uses detection by name, too; the .inf entries show a different vendor name: 1394\LOUD&Onyxi 1394\LOUD&OnyxBlackbird Regards, Clemens
On Aug 13 2014 15:41, Clemens Ladisch wrote: > The OXFW devices work with Core Audio, so they are marked as AV/C > devices; the DICE devices are not. So it would be possible to use > different specifier_id/version entries. OK. As long as using SPECIFIER_1394TA (0x00a02d) and VERSION_AVC(0x010001), OXFW driver doesn't probe Mackie devices based on Dice. > Anyway, the Windows DICE driver uses detection by name, too; the .inf > entries show a different vendor name: > > 1394\LOUD&Onyxi > 1394\LOUD&OnyxBlackbird The latter revisions use "Onyxi", however the former revisons use "Onyx-i". That's nice to distinguish. Thanks Takashi Sakamoto (In summer vacation) o-takashi@sakamocchi.jp
Takashi Sakamoto wrote: > On Aug 13 2014 15:41, Clemens Ladisch wrote: >> Anyway, the Windows DICE driver uses detection by name, too; the .inf >> entries show a different vendor name: >> >> 1394\LOUD&Onyxi >> 1394\LOUD&OnyxBlackbird > > The latter revisions use "Onyxi", however the former revisons use > "Onyx-i". That's nice to distinguish. The OXFW driver has entries for both names: "AVC\Loud_Technologies_Inc.&Onyxi&typ_1" "AVC\Loud_Technologies_Inc.&Onyx-i&typ_1" Regards, Clemens
On 2014?08?13? 16:07, Clemens Ladisch wrote: > The OXFW driver has entries for both names: > > "AVC\Loud_Technologies_Inc.&Onyxi&typ_1" > "AVC\Loud_Technologies_Inc.&Onyx-i&typ_1" Oops, exactly! Thanks for your correction. Takashi Sakamoto o-takashi@sakamocchi.jp
diff --git a/sound/firewire/Kconfig b/sound/firewire/Kconfig index 63f3cea..38027bd 100644 --- a/sound/firewire/Kconfig +++ b/sound/firewire/Kconfig @@ -35,6 +35,10 @@ config SND_OXFW Oxford Semiconductor OXFW970/971 chipset. * Griffin Firewave * LaCie Firewire Speakers + * Behringer F-Control Audio 202 + * Mackie(Loud) Onyx-i series (former models) + * Mackie(Loud) Onyx Satellite + * Mackie(Loud) Tapco Link.Firewire To compile this driver as a module, choose M here: the module will be called snd-oxfw. diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index 825377a..0c9b8e2 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -16,6 +16,8 @@ #define VENDOR_GRIFFIN 0x001292 #define VENDOR_LACIE 0x00d04b +#define VEN_BEHRINGER 0x001564 +#define VEN_LOUD 0x000ff2 #define SPECIFIER_1394TA 0x00a02d #define VERSION_AVC 0x010001 @@ -44,19 +46,40 @@ static const struct device_info lacie_speakers = { static int name_card(struct snd_oxfw *oxfw) { struct fw_device *fw_dev = fw_parent_device(oxfw->unit); + char vendor[24] = {0}; + char model[32] = {0}; 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); - d = oxfw->device_info->driver_name; - v = oxfw->device_info->vendor_name; - m = oxfw->device_info->driver_name; + /* to apply card definitions */ + if (oxfw->device_info) { + d = oxfw->device_info->driver_name; + v = oxfw->device_info->vendor_name; + m = oxfw->device_info->driver_name; + } else { + d = "OXFW"; + v = vendor; + m = model; + } strcpy(oxfw->card->driver, d); strcpy(oxfw->card->shortname, m); @@ -109,16 +132,18 @@ static int oxfw_probe(struct fw_unit *unit, if (err < 0) goto error; - err = oxfw_create_mixer(oxfw); - if (err < 0) - goto error; + if (oxfw->device_info) { + err = snd_oxfw_create_mixer(oxfw); + if (err < 0) + goto error; + } + + snd_oxfw_proc_init(oxfw); err = snd_oxfw_stream_init_simplex(oxfw); if (err < 0) goto error; - snd_oxfw_proc_init(oxfw); - err = snd_card_register(card); if (err < 0) { snd_oxfw_stream_destroy_simplex(oxfw); @@ -173,6 +198,39 @@ static const struct ieee1394_device_id oxfw_id_table[] = { .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 = VEN_BEHRINGER, + .model_id = 0x00fc22, + }, + /* Mackie(Loud), Onyx-i series (former models) */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = VEN_LOUD, + .model_id = 0x081216, + }, + /* Mackie(Loud), Onyx Satellite */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = VEN_LOUD, + .model_id = 0x00200f, + }, + /* Mackie(Loud), Tapco Link.Firewire */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = VEN_LOUD, + .model_id = 0x000460, + }, + /* IDs are unknown but able to be supported */ + /* Mackie(Loud), d.2 pro */ + /* Mackie(Loud), d.4 pro */ + /* Mackie(Loud), U.420 */ + /* Mackie(Loud), U.420d */ { } }; MODULE_DEVICE_TABLE(ieee1394, oxfw_id_table);
Some devices produced by Behringer/Mackie are based on OXFW970/971. This commit adds support for them. Additionally, this commit changes the way to name card with some information in config rom. The devices support capture/playback of PCM-samples and some of them supports capture/playback of MIDI messages. These functionalities are implemented by followed commits. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> --- sound/firewire/Kconfig | 4 +++ sound/firewire/oxfw/oxfw.c | 74 +++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 70 insertions(+), 8 deletions(-)