2011-09-05 04:04:49 +08:00
|
|
|
/*
|
|
|
|
* TC Applied Technologies Digital Interface Communications Engine driver
|
|
|
|
*
|
|
|
|
* Copyright (c) Clemens Ladisch <clemens@ladisch.de>
|
|
|
|
* Licensed under the terms of the GNU General Public License, version 2.
|
|
|
|
*/
|
|
|
|
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
#include "dice.h"
|
2011-09-05 04:04:49 +08:00
|
|
|
|
|
|
|
MODULE_DESCRIPTION("DICE driver");
|
|
|
|
MODULE_AUTHOR("Clemens Ladisch <clemens@ladisch.de>");
|
|
|
|
MODULE_LICENSE("GPL v2");
|
|
|
|
|
2012-02-14 04:55:13 +08:00
|
|
|
#define OUI_WEISS 0x001c6a
|
2015-11-14 15:42:04 +08:00
|
|
|
#define OUI_LOUD 0x000ff2
|
2016-03-07 21:35:45 +08:00
|
|
|
#define OUI_FOCUSRITE 0x00130e
|
2018-04-22 20:19:24 +08:00
|
|
|
#define OUI_TCELECTRONIC 0x000166
|
2018-05-02 18:16:44 +08:00
|
|
|
#define OUI_ALESIS 0x000595
|
2018-05-02 18:16:45 +08:00
|
|
|
#define OUI_MAUDIO 0x000d6c
|
2018-05-18 03:00:00 +08:00
|
|
|
#define OUI_MYTEK 0x001ee8
|
2012-02-14 04:55:13 +08:00
|
|
|
|
|
|
|
#define DICE_CATEGORY_ID 0x04
|
|
|
|
#define WEISS_CATEGORY_ID 0x00
|
2015-11-14 15:42:04 +08:00
|
|
|
#define LOUD_CATEGORY_ID 0x10
|
2011-09-05 04:16:02 +08:00
|
|
|
|
2018-05-02 18:16:44 +08:00
|
|
|
#define MODEL_ALESIS_IO_BOTH 0x000001
|
|
|
|
|
2015-12-31 12:58:11 +08:00
|
|
|
static int check_dice_category(struct fw_unit *unit)
|
2011-09-05 04:16:02 +08:00
|
|
|
{
|
|
|
|
struct fw_device *device = fw_parent_device(unit);
|
|
|
|
struct fw_csr_iterator it;
|
2015-12-31 12:58:11 +08:00
|
|
|
int key, val, vendor = -1, model = -1;
|
|
|
|
unsigned int category;
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
|
2011-09-05 04:16:02 +08:00
|
|
|
/*
|
|
|
|
* Check that GUID and unit directory are constructed according to DICE
|
|
|
|
* rules, i.e., that the specifier ID is the GUID's OUI, and that the
|
2012-02-14 04:55:13 +08:00
|
|
|
* GUID chip ID consists of the 8-bit category ID, the 10-bit product
|
|
|
|
* ID, and a 22-bit serial number.
|
2011-09-05 04:16:02 +08:00
|
|
|
*/
|
|
|
|
fw_csr_iterator_init(&it, unit->directory);
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
while (fw_csr_iterator_next(&it, &key, &val)) {
|
2011-09-05 04:16:02 +08:00
|
|
|
switch (key) {
|
|
|
|
case CSR_SPECIFIER_ID:
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
vendor = val;
|
2011-09-05 04:16:02 +08:00
|
|
|
break;
|
|
|
|
case CSR_MODEL:
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
model = val;
|
2011-09-05 04:16:02 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2016-03-07 21:35:45 +08:00
|
|
|
|
2012-02-14 04:55:13 +08:00
|
|
|
if (vendor == OUI_WEISS)
|
|
|
|
category = WEISS_CATEGORY_ID;
|
2015-11-14 15:42:04 +08:00
|
|
|
else if (vendor == OUI_LOUD)
|
|
|
|
category = LOUD_CATEGORY_ID;
|
2012-02-14 04:55:13 +08:00
|
|
|
else
|
|
|
|
category = DICE_CATEGORY_ID;
|
|
|
|
if (device->config_rom[3] != ((vendor << 8) | category) ||
|
2015-12-31 12:58:11 +08:00
|
|
|
device->config_rom[4] >> 22 != model)
|
|
|
|
return -ENODEV;
|
2011-09-05 04:16:02 +08:00
|
|
|
|
2015-12-31 12:58:11 +08:00
|
|
|
return 0;
|
2011-09-05 04:16:02 +08:00
|
|
|
}
|
|
|
|
|
2016-02-08 21:54:19 +08:00
|
|
|
static int check_clock_caps(struct snd_dice *dice)
|
2011-09-05 04:04:49 +08:00
|
|
|
{
|
2011-12-05 04:47:00 +08:00
|
|
|
__be32 value;
|
2016-02-08 21:54:19 +08:00
|
|
|
int err;
|
2011-09-05 04:04:49 +08:00
|
|
|
|
2011-12-05 04:47:00 +08:00
|
|
|
/* some very old firmwares don't tell about their clock support */
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
if (dice->clock_caps > 0) {
|
|
|
|
err = snd_dice_transaction_read_global(dice,
|
|
|
|
GLOBAL_CLOCK_CAPABILITIES,
|
|
|
|
&value, 4);
|
2011-12-05 04:47:00 +08:00
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
dice->clock_caps = be32_to_cpu(value);
|
|
|
|
} else {
|
|
|
|
/* this should be supported by any device */
|
|
|
|
dice->clock_caps = CLOCK_CAP_RATE_44100 |
|
|
|
|
CLOCK_CAP_RATE_48000 |
|
|
|
|
CLOCK_CAP_SOURCE_ARX1 |
|
|
|
|
CLOCK_CAP_SOURCE_INTERNAL;
|
|
|
|
}
|
|
|
|
|
2011-09-05 04:04:49 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-28 23:59:11 +08:00
|
|
|
static void dice_card_strings(struct snd_dice *dice)
|
2011-09-05 04:04:49 +08:00
|
|
|
{
|
|
|
|
struct snd_card *card = dice->card;
|
|
|
|
struct fw_device *dev = fw_parent_device(dice->unit);
|
|
|
|
char vendor[32], model[32];
|
|
|
|
unsigned int i;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
strcpy(card->driver, "DICE");
|
|
|
|
|
|
|
|
strcpy(card->shortname, "DICE");
|
|
|
|
BUILD_BUG_ON(NICK_NAME_SIZE < sizeof(card->shortname));
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
err = snd_dice_transaction_read_global(dice, GLOBAL_NICK_NAME,
|
|
|
|
card->shortname,
|
|
|
|
sizeof(card->shortname));
|
2011-09-05 04:04:49 +08:00
|
|
|
if (err >= 0) {
|
|
|
|
/* DICE strings are returned in "always-wrong" endianness */
|
|
|
|
BUILD_BUG_ON(sizeof(card->shortname) % 4 != 0);
|
|
|
|
for (i = 0; i < sizeof(card->shortname); i += 4)
|
|
|
|
swab32s((u32 *)&card->shortname[i]);
|
|
|
|
card->shortname[sizeof(card->shortname) - 1] = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
strcpy(vendor, "?");
|
|
|
|
fw_csr_string(dev->config_rom + 5, CSR_VENDOR, vendor, sizeof(vendor));
|
|
|
|
strcpy(model, "?");
|
|
|
|
fw_csr_string(dice->unit->directory, CSR_MODEL, model, sizeof(model));
|
|
|
|
snprintf(card->longname, sizeof(card->longname),
|
2011-09-05 04:16:02 +08:00
|
|
|
"%s %s (serial %u) at %s, S%d",
|
|
|
|
vendor, model, dev->config_rom[4] & 0x3fffff,
|
2011-09-05 04:04:49 +08:00
|
|
|
dev_name(&dice->unit->device), 100 << dev->max_speed);
|
|
|
|
|
|
|
|
strcpy(card->mixername, "DICE");
|
|
|
|
}
|
|
|
|
|
2018-10-10 14:35:02 +08:00
|
|
|
static void dice_card_free(struct snd_card *card)
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
{
|
2018-10-10 14:35:02 +08:00
|
|
|
struct snd_dice *dice = card->private_data;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
snd_dice_stream_destroy_duplex(dice);
|
|
|
|
snd_dice_transaction_destroy(dice);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void do_registration(struct work_struct *work)
|
2011-09-05 04:04:49 +08:00
|
|
|
{
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
struct snd_dice *dice = container_of(work, struct snd_dice, dwork.work);
|
2011-09-05 04:04:49 +08:00
|
|
|
int err;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
if (dice->registered)
|
|
|
|
return;
|
2011-09-05 04:16:02 +08:00
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
err = snd_card_new(&dice->unit->device, -1, NULL, THIS_MODULE, 0,
|
|
|
|
&dice->card);
|
2011-09-05 04:04:49 +08:00
|
|
|
if (err < 0)
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
return;
|
2018-10-10 14:35:02 +08:00
|
|
|
dice->card->private_free = dice_card_free;
|
|
|
|
dice->card->private_data = dice;
|
2011-09-05 04:04:49 +08:00
|
|
|
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
err = snd_dice_transaction_init(dice);
|
2011-09-05 04:04:49 +08:00
|
|
|
if (err < 0)
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
goto error;
|
2011-12-06 05:09:42 +08:00
|
|
|
|
2016-02-08 21:54:19 +08:00
|
|
|
err = check_clock_caps(dice);
|
2011-12-06 05:09:42 +08:00
|
|
|
if (err < 0)
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
goto error;
|
2011-09-05 04:04:49 +08:00
|
|
|
|
|
|
|
dice_card_strings(dice);
|
|
|
|
|
2018-05-02 18:16:43 +08:00
|
|
|
err = dice->detect_formats(dice);
|
2018-05-02 18:16:42 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
2016-03-31 07:47:03 +08:00
|
|
|
err = snd_dice_stream_init_duplex(dice);
|
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
snd_dice_create_proc(dice);
|
|
|
|
|
2014-11-28 23:59:15 +08:00
|
|
|
err = snd_dice_create_pcm(dice);
|
2011-09-05 04:04:49 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
err = snd_dice_create_midi(dice);
|
2011-09-05 04:04:49 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
err = snd_dice_create_hwdep(dice);
|
2014-12-08 23:10:39 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
err = snd_card_register(dice->card);
|
2011-09-05 04:04:49 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto error;
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
dice->registered = true;
|
|
|
|
|
|
|
|
return;
|
|
|
|
error:
|
|
|
|
snd_card_free(dice->card);
|
|
|
|
dev_info(&dice->unit->device,
|
|
|
|
"Sound card registration failed: %d\n", err);
|
|
|
|
}
|
|
|
|
|
2018-05-02 18:16:43 +08:00
|
|
|
static int dice_probe(struct fw_unit *unit,
|
|
|
|
const struct ieee1394_device_id *entry)
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
{
|
|
|
|
struct snd_dice *dice;
|
|
|
|
int err;
|
|
|
|
|
2018-05-02 18:16:43 +08:00
|
|
|
if (!entry->driver_data) {
|
|
|
|
err = check_dice_category(unit);
|
|
|
|
if (err < 0)
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
|
|
|
|
/* Allocate this independent of sound card instance. */
|
2018-10-03 07:21:50 +08:00
|
|
|
dice = devm_kzalloc(&unit->device, sizeof(struct snd_dice), GFP_KERNEL);
|
|
|
|
if (!dice)
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
dice->unit = fw_unit_get(unit);
|
|
|
|
dev_set_drvdata(&unit->device, dice);
|
|
|
|
|
2018-05-02 18:16:43 +08:00
|
|
|
if (!entry->driver_data) {
|
|
|
|
dice->detect_formats = snd_dice_stream_detect_current_formats;
|
|
|
|
} else {
|
|
|
|
dice->detect_formats =
|
|
|
|
(snd_dice_detect_formats_t)entry->driver_data;
|
|
|
|
}
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
spin_lock_init(&dice->lock);
|
|
|
|
mutex_init(&dice->mutex);
|
|
|
|
init_completion(&dice->clock_accepted);
|
|
|
|
init_waitqueue_head(&dice->hwdep_wait);
|
|
|
|
|
|
|
|
/* Allocate and register this sound card later. */
|
|
|
|
INIT_DEFERRABLE_WORK(&dice->dwork, do_registration);
|
2016-03-31 07:47:04 +08:00
|
|
|
snd_fw_schedule_registration(unit, &dice->dwork);
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
|
|
|
|
return 0;
|
2011-09-05 04:04:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void dice_remove(struct fw_unit *unit)
|
|
|
|
{
|
2014-11-28 23:59:11 +08:00
|
|
|
struct snd_dice *dice = dev_get_drvdata(&unit->device);
|
2011-09-05 04:04:49 +08:00
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08: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(&dice->dwork);
|
|
|
|
|
|
|
|
if (dice->registered) {
|
2018-10-27 16:13:31 +08:00
|
|
|
// Block till all of ALSA character devices are released.
|
|
|
|
snd_card_free(dice->card);
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
}
|
2018-10-10 14:35:00 +08:00
|
|
|
|
|
|
|
mutex_destroy(&dice->mutex);
|
|
|
|
fw_unit_put(dice->unit);
|
2011-09-05 04:04:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void dice_bus_reset(struct fw_unit *unit)
|
|
|
|
{
|
2014-11-28 23:59:11 +08:00
|
|
|
struct snd_dice *dice = dev_get_drvdata(&unit->device);
|
2011-09-05 04:04:49 +08:00
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
/* Postpone a workqueue for deferred registration. */
|
|
|
|
if (!dice->registered)
|
2016-03-31 07:47:04 +08:00
|
|
|
snd_fw_schedule_registration(unit, &dice->dwork);
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
|
ALSA: dice: Split transaction functionality into a file
This commit adds a file with some helper functions for transaction, and move
some codes into the file with some arrangements.
For Dice chipset, well-known FCP or AV/C commands are not used to control
devices. It's achieved by read/write transactions into specific addresses.
Dice's address area is split into 5 areas. Each area has its own role. The
offset for each area can be got by reading head of the address area. By
reading these areas, drivers can get to know device status. By writing these
areas, drivers can change device status.
Dice has a specific mechanism called as 'notification'. When device status is
changed, Dice devices tells the event by sending transaction. This notification
is sent to an address which drivers register in advance. But this causes an
issue to drivers.
To handle the notification, drivers need to allocate its own callback function
to the address region in host controller. This region is exclusive. For the
other applications, drivers must give a mechanism to read the received
notification. For this purpose, Dice driver already implements hwdep interface.
Dice chipset doesn't allow drivers to register several addresses. In this
reason, when this driver is applied to a device, the other drivers should
_not_ try to register its own address to the device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-28 23:59:13 +08:00
|
|
|
/* The handler address register becomes initialized. */
|
|
|
|
snd_dice_transaction_reinit(dice);
|
|
|
|
|
ALSA: dice: postpone card registration
Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.
As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.
This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.
For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.
I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.
When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-31 12:58:12 +08:00
|
|
|
/*
|
|
|
|
* After registration, userspace can start packet streaming, then this
|
|
|
|
* code block works fine.
|
|
|
|
*/
|
|
|
|
if (dice->registered) {
|
|
|
|
mutex_lock(&dice->mutex);
|
|
|
|
snd_dice_stream_update_duplex(dice);
|
|
|
|
mutex_unlock(&dice->mutex);
|
|
|
|
}
|
2011-09-05 04:04:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#define DICE_INTERFACE 0x000001
|
|
|
|
|
|
|
|
static const struct ieee1394_device_id dice_id_table[] = {
|
2018-05-02 18:16:45 +08:00
|
|
|
/* M-Audio Profire 2626 has a different value in version field. */
|
ALSA: dice: add support for M-Audio Profire 610 and perhaps 2626
M-Audio Profire 610 has an unexpected value in version field of its config
ROM, thus ALSA dice driver is not assigned to the model due to a mismatch
of modalias.
This commit adds an entry to support the model. I expect the entry is
also for Profire 2626.
I note that Profire 610 uses TCD2220 (so-called Dice Jr.), and supports a
part of Extended Application Protocol (EAP).
$ cd linux-firewire-utils/src
$ ./crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
------------------------------------------------------------
400 04047689 bus_info_length 4, crc_length 4, crc 30345
404 31333934 bus_name "1394"
408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
40c 000d6c04 company_id 000d6c |
410 04400002 device_id 0404400002 | EUI-64 000d6c0404400002
root directory
------------------------------------------------------------
414 000695fe directory_length 6, crc 38398
418 03000d6c vendor
41c 8100000a --> descriptor leaf at 444
420 17000011 model
424 8100000d --> descriptor leaf at 458
428 0c0087c0 node capabilities per IEEE 1394
42c d1000001 --> unit directory at 430
unit directory at 430
------------------------------------------------------------
430 0004fb14 directory_length 4, crc 64276
434 12000d6c specifier id
438 130100d1 version
43c 17000011 model
440 8100000c --> descriptor leaf at 470
descriptor leaf at 444
------------------------------------------------------------
444 0004b8e4 leaf_length 4, crc 47332
448 00000000 textual descriptor
44c 00000000 minimal ASCII
450 4d2d4175 "M-Au"
454 64696f00 "dio"
descriptor leaf at 458
------------------------------------------------------------
458 00053128 leaf_length 5, crc 12584
45c 00000000 textual descriptor
460 00000000 minimal ASCII
464 50726f46 "ProF"
468 69726520 "ire "
46c 36313000 "610"
descriptor leaf at 470
------------------------------------------------------------
470 00053128 leaf_length 5, crc 12584
474 00000000 textual descriptor
478 00000000 minimal ASCII
47c 50726f46 "ProF"
480 69726520 "ire "
484 36313000 "610"
$ cat /proc/asound/card1/dice
sections:
global: offset 10, size 90
tx: offset 100, size 142
rx: offset 242, size 282
ext_sync: offset 524, size 4
unused2: offset 0, size 0
global:
owner: ffc0:000100000000
notification: 00000040
nick name: FW610
clock select: internal 48000
enable: 1
status: locked 48000
ext status: 00000040
sample rate: 48000
version: 1.0.4.0
clock caps: 32000 44100 48000 88200 96000 176400 192000 aes1 aes4 aes adat tdif wc arx1 arx2 internal
clock source names: SPDIF\AES34\AES56\TOS\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\\
...
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-04-30 21:06:46 +08:00
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
2018-05-02 18:16:45 +08:00
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_MAUDIO,
|
|
|
|
.model_id = 0x000010,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_extension_formats,
|
|
|
|
},
|
|
|
|
/* M-Audio Profire 610 has a different value in version field. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_MAUDIO,
|
|
|
|
.model_id = 0x000011,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_extension_formats,
|
ALSA: dice: add support for M-Audio Profire 610 and perhaps 2626
M-Audio Profire 610 has an unexpected value in version field of its config
ROM, thus ALSA dice driver is not assigned to the model due to a mismatch
of modalias.
This commit adds an entry to support the model. I expect the entry is
also for Profire 2626.
I note that Profire 610 uses TCD2220 (so-called Dice Jr.), and supports a
part of Extended Application Protocol (EAP).
$ cd linux-firewire-utils/src
$ ./crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
------------------------------------------------------------
400 04047689 bus_info_length 4, crc_length 4, crc 30345
404 31333934 bus_name "1394"
408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
40c 000d6c04 company_id 000d6c |
410 04400002 device_id 0404400002 | EUI-64 000d6c0404400002
root directory
------------------------------------------------------------
414 000695fe directory_length 6, crc 38398
418 03000d6c vendor
41c 8100000a --> descriptor leaf at 444
420 17000011 model
424 8100000d --> descriptor leaf at 458
428 0c0087c0 node capabilities per IEEE 1394
42c d1000001 --> unit directory at 430
unit directory at 430
------------------------------------------------------------
430 0004fb14 directory_length 4, crc 64276
434 12000d6c specifier id
438 130100d1 version
43c 17000011 model
440 8100000c --> descriptor leaf at 470
descriptor leaf at 444
------------------------------------------------------------
444 0004b8e4 leaf_length 4, crc 47332
448 00000000 textual descriptor
44c 00000000 minimal ASCII
450 4d2d4175 "M-Au"
454 64696f00 "dio"
descriptor leaf at 458
------------------------------------------------------------
458 00053128 leaf_length 5, crc 12584
45c 00000000 textual descriptor
460 00000000 minimal ASCII
464 50726f46 "ProF"
468 69726520 "ire "
46c 36313000 "610"
descriptor leaf at 470
------------------------------------------------------------
470 00053128 leaf_length 5, crc 12584
474 00000000 textual descriptor
478 00000000 minimal ASCII
47c 50726f46 "ProF"
480 69726520 "ire "
484 36313000 "610"
$ cat /proc/asound/card1/dice
sections:
global: offset 10, size 90
tx: offset 100, size 142
rx: offset 242, size 282
ext_sync: offset 524, size 4
unused2: offset 0, size 0
global:
owner: ffc0:000100000000
notification: 00000040
nick name: FW610
clock select: internal 48000
enable: 1
status: locked 48000
ext status: 00000040
sample rate: 48000
version: 1.0.4.0
clock caps: 32000 44100 48000 88200 96000 176400 192000 aes1 aes4 aes adat tdif wc arx1 arx2 internal
clock source names: SPDIF\AES34\AES56\TOS\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\\
...
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-04-30 21:06:46 +08:00
|
|
|
},
|
2018-05-02 18:16:43 +08:00
|
|
|
/* TC Electronic Konnekt 24D. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000020,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
|
|
|
/* TC Electronic Konnekt 8. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000021,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
|
|
|
/* TC Electronic Studio Konnekt 48. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000022,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
|
|
|
/* TC Electronic Konnekt Live. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000023,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
|
|
|
/* TC Electronic Desktop Konnekt 6. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000024,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
|
|
|
/* TC Electronic Impact Twin. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000027,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
ALSA: dice: add stream format parameters for TC Electronic Digital Konnekt x32
TC Electronic Digital Konnekt x32 is an application of WaveFront DiceII STD
and doesn't support TCAT extended application protocol. For such devices,
ALSA dice driver needs to have hard-coded parameters for stream formats.
This commit adds stream format parameters for this model. Unfortunately, at
sampling transmission frequencies of 88.2/96.0kHz, I confirmed that current
ALSA dice driver doesn't drive the device appropriately due to detecting
packet discontinuities.
$ journalctl
kernel: snd_dice fw1.0: Detect discontinuity of CIP: 90 80
At the frequencies, the device transfers 16 data blocks per packet and 16
data channels per data block, as a result one packet includes 1032 bytes
if it's not NODATA. However, as long as I checked, the device often
postpone packet transmission and continue with truncated payload than
metadata in isochronous packet header. Below is a sample of sequence I got.
sec cycle bytes CIP1 CIP2
37 3314 1032 0x01100090 0x900449E2
37 3315 8 0x011000A0 0x9004FFFF
37 3316 1032 0x011000A0 0x900461E2
37 3317 1032 0x011000B0 0x900475E2
37 3318 1032 0x011000C0 0x900489E2
37 3319 8 0x011000D0 0x9004FFFF
37 3320 1032 0x011000D0 0x9004A1E2
37 3321 1032 0x011000E0 0x9004B5E2
37 3322 1032 0x011000F0 0x9004C9E2
37 3323 8 0x01100000 0x9004FFFF
37 3324 1032 0x01100000 0x9004E1E2
37 3325 1032 0x01100010 0x9004F5E2
37 3326 1032 0x01100020 0x900409E2
37 3327 8 0x01100030 0x9004FFFF
37 3328 1032 0x01100030 0x900421E2
37 3329 1032 0x01100040 0x900435E2
37 3330 (skip)
37 3331 (skip)
37 3332 (skip)
37 3333 (skip)
37 3334 (skip)
37 3335 (skip)
37 3336 (skip)
37 3337 (skip)
37 3338 (skip)
37 3339 (skip)
37 3340 (skip)
37 3341 (skip)
37 3342 (skip)
37 3343 (skip)
37 3344 (skip)
37 3345 (skip)
37 3346 (skip)
37 3347 (skip)
37 3348 (skip)
37 3349 (skip)
37 3350 (skip)
37 3351 (skip)
37 3352 (skip)
37 3353 (skip)
37 3354 (skip)
37 3355 (skip)
37 3356 (skip)
37 3357 (skip)
37 3358 (skip)
37 3359 (skip)
37 3360 (skip)
37 3361 (skip)
37 3362 (skip)
37 3363 (skip)
37 3364 (skip)
37 3365 (skip)
37 3366 (skip)
37 3367 1032 0x01100050 0x900461E1
37 3368 1032 0x01100060 0x900475E1
37 3369 1032 0x01100070 0x9004A1E1
37 3370 1032 0x01100080 0x9004A1E1 but content of payload is truncated.
37 3371 (skip)
37 3371 1032 0x01100080 0x9004B5E0 detect discontinuity
37 3372 1032 0x01100090 0x9004C9E0
37 3373 1032 0x011000A0 0x9004E1E0
37 3374 1032 0x011000B0 0x9004F5E0
37 3375 1032 0x011000C0 0x900409E0
37 3376 1032 0x011000D0 0x900421E0
37 3377 1032 0x011000E0 0x900435E0
37 3378 1032 0x011000F0 0x900449DF
37 3379 8 0x01100000 0x9004FFFF
37 3380 1032 0x01100000 0x900461DF
37 3381 1032 0x01100010 0x900475DF
37 3382 1032 0x01100020 0x900489DF
37 3383 8 0x01100030 0x9004FFFF
37 3384 1032 0x01100030 0x9004A1DF
37 3385 1032 0x01100040 0x9004B5DF
37 3386 1032 0x01100050 0x9004C9DF
37 3387 8 0x01100060 0x9004FFFF
I cannot confirm this quirks with Windows driver. ALSA dice driver has a
cause if assumed differences between these two drivers are ways of
timestampling to RX packets from the drivers to the device. I've already
reported timestamping quirk of Dice-based devices and this might bring
this issue.
[alsa-devel] Dice packet sequence quirk and ALSA firewire stack in Linux 4.6
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107715.html
Well, nevertheless, I enable ALSA dice driver to work at the frequencies.
This may brings inconvenience to users but I expect developers and users
to fix it.
$ cd linux-firewire-utils/src
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 040423bb bus_info_length 4, crc_length 4, crc 9147
404 31333934 bus_name "1394"
408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
40c 00016604 company_id 000166 |
410 0c232c28 device_id 040c232c28 | EUI-64 000166040c232c28
root directory
-----------------------------------------------------------------
414 0006b6cb directory_length 6, crc 46795
418 03000166 vendor
41c 8100000a --> descriptor leaf at 444
420 17000030 model
424 8100000f --> descriptor leaf at 460
428 0c0087c0 node capabilities per IEEE 1394
42c d1000001 --> unit directory at 430
unit directory at 430
-----------------------------------------------------------------
430 000476c2 directory_length 4, crc 30402
434 12000166 specifier id
438 13000001 version
43c 17000030 model
440 81000010 --> descriptor leaf at 480
descriptor leaf at 444
-----------------------------------------------------------------
444 0006c490 leaf_length 6, crc 50320
448 00000000 textual descriptor
44c 00000000 minimal ASCII
450 54432045 "TC E"
454 6c656374 "lect"
458 726f6e69 "roni"
45c 63000000 "c"
descriptor leaf at 460
-----------------------------------------------------------------
460 000772b4 leaf_length 7, crc 29364
464 00000000 textual descriptor
468 00000000 minimal ASCII
46c 44696769 "Digi"
470 74616c4b "talK"
474 6f6e6e65 "onne"
478 6b747833 "ktx3"
47c 32000000 "2"
descriptor leaf at 480
-----------------------------------------------------------------
480 000772b4 leaf_length 7, crc 29364
484 00000000 textual descriptor
488 00000000 minimal ASCII
48c 44696769 "Digi"
490 74616c4b "talK"
494 6f6e6e65 "onne"
498 6b747833 "ktx3"
49c 32000000 "2"
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-05-20 13:40:44 +08:00
|
|
|
/* TC Electronic Digital Konnekt x32. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_TCELECTRONIC,
|
|
|
|
.model_id = 0x000030,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_tcelectronic_formats,
|
|
|
|
},
|
2018-05-02 18:16:44 +08:00
|
|
|
/* Alesis iO14/iO26. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_ALESIS,
|
|
|
|
.model_id = MODEL_ALESIS_IO_BOTH,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_alesis_formats,
|
|
|
|
},
|
2018-05-18 03:00:00 +08:00
|
|
|
/* Mytek Stereo 192 DSD-DAC. */
|
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VENDOR_ID |
|
|
|
|
IEEE1394_MATCH_MODEL_ID,
|
|
|
|
.vendor_id = OUI_MYTEK,
|
|
|
|
.model_id = 0x000002,
|
|
|
|
.driver_data = (kernel_ulong_t)snd_dice_detect_mytek_formats,
|
|
|
|
},
|
2018-05-02 18:16:43 +08:00
|
|
|
{
|
|
|
|
.match_flags = IEEE1394_MATCH_VERSION,
|
|
|
|
.version = DICE_INTERFACE,
|
|
|
|
},
|
2011-09-05 04:04:49 +08:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(ieee1394, dice_id_table);
|
|
|
|
|
|
|
|
static struct fw_driver dice_driver = {
|
|
|
|
.driver = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.name = KBUILD_MODNAME,
|
|
|
|
.bus = &fw_bus_type,
|
|
|
|
},
|
|
|
|
.probe = dice_probe,
|
|
|
|
.update = dice_bus_reset,
|
|
|
|
.remove = dice_remove,
|
|
|
|
.id_table = dice_id_table,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init alsa_dice_init(void)
|
|
|
|
{
|
|
|
|
return driver_register(&dice_driver.driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit alsa_dice_exit(void)
|
|
|
|
{
|
|
|
|
driver_unregister(&dice_driver.driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(alsa_dice_init);
|
|
|
|
module_exit(alsa_dice_exit);
|