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 22:59:13 +07:00
|
|
|
/*
|
|
|
|
|
* dice.h - a part of driver for Dice based devices
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) Clemens Ladisch
|
|
|
|
|
* Copyright (c) 2014 Takashi Sakamoto
|
|
|
|
|
*
|
|
|
|
|
* Licensed under the terms of the GNU General Public License, version 2.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef SOUND_DICE_H_INCLUDED
|
|
|
|
|
#define SOUND_DICE_H_INCLUDED
|
|
|
|
|
|
|
|
|
|
#include <linux/compat.h>
|
|
|
|
|
#include <linux/completion.h>
|
|
|
|
|
#include <linux/delay.h>
|
|
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/firewire.h>
|
|
|
|
|
#include <linux/firewire-constants.h>
|
|
|
|
|
#include <linux/jiffies.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/mod_devicetable.h>
|
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
|
#include <linux/wait.h>
|
2017-02-03 01:15:33 +07:00
|
|
|
#include <linux/sched/signal.h>
|
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 22:59:13 +07:00
|
|
|
|
|
|
|
|
#include <sound/control.h>
|
|
|
|
|
#include <sound/core.h>
|
|
|
|
|
#include <sound/firewire.h>
|
|
|
|
|
#include <sound/hwdep.h>
|
|
|
|
|
#include <sound/info.h>
|
|
|
|
|
#include <sound/initval.h>
|
|
|
|
|
#include <sound/pcm.h>
|
|
|
|
|
#include <sound/pcm_params.h>
|
2014-12-08 22:10:39 +07:00
|
|
|
#include <sound/rawmidi.h>
|
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 22:59:13 +07:00
|
|
|
|
2015-09-19 09:21:55 +07:00
|
|
|
#include "../amdtp-am824.h"
|
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 22:59:13 +07:00
|
|
|
#include "../iso-resources.h"
|
|
|
|
|
#include "../lib.h"
|
|
|
|
|
#include "dice-interface.h"
|
|
|
|
|
|
ALSA: dice: have two sets of isochronous resources/streams
Currently ALSA dice driver handles a pair of isochronous resources for
IEC 61883-1/6 packet streaming. While, according to some documents about
ASICs named as 'Dice', several isochronous streams are available.
Here, I start to describe ASICs produced under 'Dice' name.
* Dice II (designed by wavefront semiconductor, including TCAT's IP)
* STD (with limited functionality of DTCP)
* CP (with full functionality of DTCP)
* TCD2210/2210-E (so-called 'Dice Mini')
* TCD2220/2220-E (so-called 'Dice Jr.')
* TCD3070-CH (so-called 'Dice III')
Some documents are public and we can see hardware design of them. We can
find some articles about hardware internal register definitions
(not registers exported to IEEE 1394 bus).
* DICE II User Guide
* http://www.tctechnologies.tc/archive/downloads/dice_ii_user_guide.pdf
* 6.1 AVS Audio Receivers
* Table 6.1: AVS Audio Receiver Memory Map
* ARX1-ARX4
* 6.2 AVS Audio Transmitters
* Table 6.2: AVS Audio Transmitter Memory Map
* ATX1, ATX2
* TCD22xx User Guide
* http://www.tctechnologies.tc/downloads/tcd22xx_user_guide.pdf
* 6.1 AVS Audio Receivers
* Table 66: AVS Audio Receiver Memory Map
* ARX1, ARX2
* 6/2 AVS Audio Transmitters
* Table 67: AVS Audio Transmitter Memory Map
* ATX1, ATX2
* DICE III
* http://www.tctechnologies.tc/downloads/TCD3070-CH.pdf
* Dual stream 63 channel transmitter/receiver
For Dice II and TCD22xx series, maximum 16 data channels are transferred in
an AMDTP packet, while for Dice III, maximum 32 data channels are
transferred.
According to the design of the series of these ASICs, this commit allows
this driver to handle additional set of isochronous resources. For
practical reason, two pair of isochronous resources are added. As of this
commit, this driver still use a pair of the first isochronous resources.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-07 20:35:42 +07:00
|
|
|
/*
|
|
|
|
|
* This module support maximum 2 pairs of tx/rx isochronous streams for
|
|
|
|
|
* our convinience.
|
|
|
|
|
*
|
|
|
|
|
* In documents for ASICs called with a name of 'DICE':
|
|
|
|
|
* - ASIC for DICE II:
|
|
|
|
|
* - Maximum 2 tx and 4 rx are supported.
|
|
|
|
|
* - A packet supports maximum 16 data channels.
|
|
|
|
|
* - TCD2210/2210-E (so-called 'Dice Mini'):
|
|
|
|
|
* - Maximum 2 tx and 2 rx are supported.
|
|
|
|
|
* - A packet supports maximum 16 data channels.
|
|
|
|
|
* - TCD2220/2220-E (so-called 'Dice Jr.')
|
|
|
|
|
* - 2 tx and 2 rx are supported.
|
|
|
|
|
* - A packet supports maximum 16 data channels.
|
|
|
|
|
* - TCD3070-CH (so-called 'Dice III')
|
|
|
|
|
* - Maximum 2 tx and 2 rx are supported.
|
|
|
|
|
* - A packet supports maximum 32 data channels.
|
|
|
|
|
*
|
|
|
|
|
* For the above, MIDI conformant data channel is just on the first isochronous
|
|
|
|
|
* stream.
|
|
|
|
|
*/
|
|
|
|
|
#define MAX_STREAMS 2
|
|
|
|
|
|
2018-05-02 17:16:39 +07:00
|
|
|
enum snd_dice_rate_mode {
|
|
|
|
|
SND_DICE_RATE_MODE_LOW = 0,
|
|
|
|
|
SND_DICE_RATE_MODE_MIDDLE,
|
|
|
|
|
SND_DICE_RATE_MODE_HIGH,
|
|
|
|
|
SND_DICE_RATE_MODE_COUNT,
|
|
|
|
|
};
|
|
|
|
|
|
2018-05-02 17:16:43 +07:00
|
|
|
struct snd_dice;
|
|
|
|
|
typedef int (*snd_dice_detect_formats_t)(struct snd_dice *dice);
|
|
|
|
|
|
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 22:59:13 +07:00
|
|
|
struct snd_dice {
|
|
|
|
|
struct snd_card *card;
|
|
|
|
|
struct fw_unit *unit;
|
|
|
|
|
spinlock_t lock;
|
|
|
|
|
struct mutex mutex;
|
|
|
|
|
|
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 11:58:12 +07:00
|
|
|
bool registered;
|
|
|
|
|
struct delayed_work dwork;
|
|
|
|
|
|
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 22:59:13 +07:00
|
|
|
/* Offsets for sub-addresses */
|
|
|
|
|
unsigned int global_offset;
|
|
|
|
|
unsigned int rx_offset;
|
|
|
|
|
unsigned int tx_offset;
|
|
|
|
|
unsigned int sync_offset;
|
|
|
|
|
unsigned int rsrv_offset;
|
|
|
|
|
|
|
|
|
|
unsigned int clock_caps;
|
2018-05-02 17:16:39 +07:00
|
|
|
unsigned int tx_pcm_chs[MAX_STREAMS][SND_DICE_RATE_MODE_COUNT];
|
|
|
|
|
unsigned int rx_pcm_chs[MAX_STREAMS][SND_DICE_RATE_MODE_COUNT];
|
|
|
|
|
unsigned int tx_midi_ports[MAX_STREAMS];
|
|
|
|
|
unsigned int rx_midi_ports[MAX_STREAMS];
|
2018-05-02 17:16:43 +07:00
|
|
|
snd_dice_detect_formats_t detect_formats;
|
2014-12-08 22:10:36 +07: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 22:59:13 +07:00
|
|
|
struct fw_address_handler notification_handler;
|
|
|
|
|
int owner_generation;
|
2014-12-08 22:10:36 +07:00
|
|
|
u32 notification_bits;
|
|
|
|
|
|
|
|
|
|
/* For uapi */
|
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 22:59:13 +07:00
|
|
|
int dev_lock_count; /* > 0 driver, < 0 userspace */
|
|
|
|
|
bool dev_lock_changed;
|
|
|
|
|
wait_queue_head_t hwdep_wait;
|
2014-12-08 22:10:36 +07:00
|
|
|
|
|
|
|
|
/* For streaming */
|
ALSA: dice: have two sets of isochronous resources/streams
Currently ALSA dice driver handles a pair of isochronous resources for
IEC 61883-1/6 packet streaming. While, according to some documents about
ASICs named as 'Dice', several isochronous streams are available.
Here, I start to describe ASICs produced under 'Dice' name.
* Dice II (designed by wavefront semiconductor, including TCAT's IP)
* STD (with limited functionality of DTCP)
* CP (with full functionality of DTCP)
* TCD2210/2210-E (so-called 'Dice Mini')
* TCD2220/2220-E (so-called 'Dice Jr.')
* TCD3070-CH (so-called 'Dice III')
Some documents are public and we can see hardware design of them. We can
find some articles about hardware internal register definitions
(not registers exported to IEEE 1394 bus).
* DICE II User Guide
* http://www.tctechnologies.tc/archive/downloads/dice_ii_user_guide.pdf
* 6.1 AVS Audio Receivers
* Table 6.1: AVS Audio Receiver Memory Map
* ARX1-ARX4
* 6.2 AVS Audio Transmitters
* Table 6.2: AVS Audio Transmitter Memory Map
* ATX1, ATX2
* TCD22xx User Guide
* http://www.tctechnologies.tc/downloads/tcd22xx_user_guide.pdf
* 6.1 AVS Audio Receivers
* Table 66: AVS Audio Receiver Memory Map
* ARX1, ARX2
* 6/2 AVS Audio Transmitters
* Table 67: AVS Audio Transmitter Memory Map
* ATX1, ATX2
* DICE III
* http://www.tctechnologies.tc/downloads/TCD3070-CH.pdf
* Dual stream 63 channel transmitter/receiver
For Dice II and TCD22xx series, maximum 16 data channels are transferred in
an AMDTP packet, while for Dice III, maximum 32 data channels are
transferred.
According to the design of the series of these ASICs, this commit allows
this driver to handle additional set of isochronous resources. For
practical reason, two pair of isochronous resources are added. As of this
commit, this driver still use a pair of the first isochronous resources.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-07 20:35:42 +07:00
|
|
|
struct fw_iso_resources tx_resources[MAX_STREAMS];
|
|
|
|
|
struct fw_iso_resources rx_resources[MAX_STREAMS];
|
|
|
|
|
struct amdtp_stream tx_stream[MAX_STREAMS];
|
|
|
|
|
struct amdtp_stream rx_stream[MAX_STREAMS];
|
2014-12-08 22:10:36 +07:00
|
|
|
bool global_enabled;
|
|
|
|
|
struct completion clock_accepted;
|
|
|
|
|
unsigned int substreams_counter;
|
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 22:59:13 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum snd_dice_addr_type {
|
|
|
|
|
SND_DICE_ADDR_TYPE_PRIVATE,
|
|
|
|
|
SND_DICE_ADDR_TYPE_GLOBAL,
|
|
|
|
|
SND_DICE_ADDR_TYPE_TX,
|
|
|
|
|
SND_DICE_ADDR_TYPE_RX,
|
|
|
|
|
SND_DICE_ADDR_TYPE_SYNC,
|
|
|
|
|
SND_DICE_ADDR_TYPE_RSRV,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int snd_dice_transaction_write(struct snd_dice *dice,
|
|
|
|
|
enum snd_dice_addr_type type,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len);
|
|
|
|
|
int snd_dice_transaction_read(struct snd_dice *dice,
|
|
|
|
|
enum snd_dice_addr_type type, unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len);
|
|
|
|
|
|
|
|
|
|
static inline int snd_dice_transaction_write_global(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_write(dice,
|
|
|
|
|
SND_DICE_ADDR_TYPE_GLOBAL, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_read_global(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_read(dice,
|
|
|
|
|
SND_DICE_ADDR_TYPE_GLOBAL, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_write_tx(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_write(dice, SND_DICE_ADDR_TYPE_TX, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_read_tx(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_read(dice, SND_DICE_ADDR_TYPE_TX, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_write_rx(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_write(dice, SND_DICE_ADDR_TYPE_RX, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_read_rx(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_read(dice, SND_DICE_ADDR_TYPE_RX, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_write_sync(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_write(dice, SND_DICE_ADDR_TYPE_SYNC, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
static inline int snd_dice_transaction_read_sync(struct snd_dice *dice,
|
|
|
|
|
unsigned int offset,
|
|
|
|
|
void *buf, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
return snd_dice_transaction_read(dice, SND_DICE_ADDR_TYPE_SYNC, offset,
|
|
|
|
|
buf, len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int snd_dice_transaction_get_clock_source(struct snd_dice *dice,
|
|
|
|
|
unsigned int *source);
|
|
|
|
|
int snd_dice_transaction_get_rate(struct snd_dice *dice, unsigned int *rate);
|
|
|
|
|
int snd_dice_transaction_set_enable(struct snd_dice *dice);
|
|
|
|
|
void snd_dice_transaction_clear_enable(struct snd_dice *dice);
|
|
|
|
|
int snd_dice_transaction_init(struct snd_dice *dice);
|
|
|
|
|
int snd_dice_transaction_reinit(struct snd_dice *dice);
|
|
|
|
|
void snd_dice_transaction_destroy(struct snd_dice *dice);
|
|
|
|
|
|
|
|
|
|
#define SND_DICE_RATES_COUNT 7
|
|
|
|
|
extern const unsigned int snd_dice_rates[SND_DICE_RATES_COUNT];
|
|
|
|
|
|
2018-05-02 17:16:42 +07:00
|
|
|
int snd_dice_stream_get_rate_mode(struct snd_dice *dice, unsigned int rate,
|
|
|
|
|
enum snd_dice_rate_mode *mode);
|
2019-06-11 20:21:16 +07:00
|
|
|
int snd_dice_stream_start_duplex(struct snd_dice *dice);
|
2014-12-08 22:10:36 +07:00
|
|
|
void snd_dice_stream_stop_duplex(struct snd_dice *dice);
|
|
|
|
|
int snd_dice_stream_init_duplex(struct snd_dice *dice);
|
|
|
|
|
void snd_dice_stream_destroy_duplex(struct snd_dice *dice);
|
2019-06-11 20:21:16 +07:00
|
|
|
int snd_dice_stream_reserve_duplex(struct snd_dice *dice, unsigned int rate);
|
2014-12-08 22:10:36 +07:00
|
|
|
void snd_dice_stream_update_duplex(struct snd_dice *dice);
|
2018-05-02 17:16:42 +07:00
|
|
|
int snd_dice_stream_detect_current_formats(struct snd_dice *dice);
|
2014-11-28 22:59:14 +07:00
|
|
|
|
|
|
|
|
int snd_dice_stream_lock_try(struct snd_dice *dice);
|
|
|
|
|
void snd_dice_stream_lock_release(struct snd_dice *dice);
|
|
|
|
|
|
2014-11-28 22:59:15 +07:00
|
|
|
int snd_dice_create_pcm(struct snd_dice *dice);
|
|
|
|
|
|
2014-11-28 22:59:16 +07:00
|
|
|
int snd_dice_create_hwdep(struct snd_dice *dice);
|
|
|
|
|
|
2014-11-28 22:59:17 +07:00
|
|
|
void snd_dice_create_proc(struct snd_dice *dice);
|
|
|
|
|
|
2014-12-08 22:10:39 +07:00
|
|
|
int snd_dice_create_midi(struct snd_dice *dice);
|
|
|
|
|
|
2018-05-02 17:16:43 +07:00
|
|
|
int snd_dice_detect_tcelectronic_formats(struct snd_dice *dice);
|
2018-05-02 17:16:44 +07:00
|
|
|
int snd_dice_detect_alesis_formats(struct snd_dice *dice);
|
2018-05-02 17:16:45 +07:00
|
|
|
int snd_dice_detect_extension_formats(struct snd_dice *dice);
|
2018-05-18 02:00:00 +07:00
|
|
|
int snd_dice_detect_mytek_formats(struct snd_dice *dice);
|
ALSA: dice: add stream format parameters for PreSonus FireStudio
FireStudio was launched by PreSonus 2009. This model consists of three
ICs for its packet processing on IEEE 1394 bus:
- Texus Instruments TSB41AB2 for physical layer of IEEE 1394 bus
- WaveFront semiconductor, Dice II STD ASIC for link layer of IEEE 1394
bus and protocol layer
- Xilinx Spartan XG3S500E FPGA for signal processing
This model don't support TCAT extended application protocol. For such
devices, ALSA dice driver needs to have hard-coded parameters for stream
formats.
This commit adds hard-coded table for this model. As a result, sampling
transfer frequencies of 88.2/96.0 kHz are supported. I note that this
patch can be backported to Linux kernel v4.18 and later.
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04042eda bus_info_length 4, crc_length 4, crc 11994
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 000a9204 company_id 000a92 |
410 023a8b7f device_id 04023a8b7f | EUI-64 000a9204023a8b7f
root directory
-----------------------------------------------------------------
414 000661b6 directory_length 6, crc 25014
418 03000a92 vendor
41c 8100000a --> descriptor leaf at 444
420 17000008 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 00041c75 directory_length 4, crc 7285
434 12000a92 specifier id
438 13000001 version
43c 17000008 model
440 8100000c --> descriptor leaf at 470
descriptor leaf at 444
-----------------------------------------------------------------
444 00047c11 leaf_length 4, crc 31761
448 00000000 textual descriptor
44c 00000000 minimal ASCII
450 50726553 "PreS"
454 6f6e7573 "onus"
descriptor leaf at 458
-----------------------------------------------------------------
458 0005d7b3 leaf_length 5, crc 55219
45c 00000000 textual descriptor
460 00000000 minimal ASCII
464 46495245 "FIRE"
468 53545544 "STUD"
46c 494f0000 "IO"
descriptor leaf at 470
-----------------------------------------------------------------
470 0005d7b3 leaf_length 5, crc 55219
474 00000000 textual descriptor
478 00000000 minimal ASCII
47c 46495245 "FIRE"
480 53545544 "STUD"
484 494f0000 "IO"
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-05-17 09:56:22 +07:00
|
|
|
int snd_dice_detect_presonus_formats(struct snd_dice *dice);
|
2018-05-02 17:16:43 +07: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 22:59:13 +07:00
|
|
|
#endif
|