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 16:59:13 +01: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>
|
|
|
|
|
|
|
|
|
|
#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 16:10:39 +01: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 16:59:13 +01:00
|
|
|
|
2015-09-19 04:21:55 +02: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 16:59:13 +01: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 14:35:42 +01: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
|
|
|
|
|
|
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 16:59:13 +01: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 05:58:12 +01: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 16:59:13 +01: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;
|
2014-12-08 16:10:36 +01: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 16:59:13 +01:00
|
|
|
struct fw_address_handler notification_handler;
|
|
|
|
|
int owner_generation;
|
2014-12-08 16:10:36 +01: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 16:59:13 +01:00
|
|
|
int dev_lock_count; /* > 0 driver, < 0 userspace */
|
|
|
|
|
bool dev_lock_changed;
|
|
|
|
|
wait_queue_head_t hwdep_wait;
|
2014-12-08 16:10:36 +01: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 14:35:42 +01: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 16:10:36 +01: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 16:59:13 +01: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];
|
|
|
|
|
|
2014-12-08 16:10:36 +01:00
|
|
|
int snd_dice_stream_start_duplex(struct snd_dice *dice, unsigned int rate);
|
|
|
|
|
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);
|
|
|
|
|
void snd_dice_stream_update_duplex(struct snd_dice *dice);
|
2014-11-28 16:59:14 +01:00
|
|
|
|
|
|
|
|
int snd_dice_stream_lock_try(struct snd_dice *dice);
|
|
|
|
|
void snd_dice_stream_lock_release(struct snd_dice *dice);
|
|
|
|
|
|
2014-11-28 16:59:15 +01:00
|
|
|
int snd_dice_create_pcm(struct snd_dice *dice);
|
|
|
|
|
|
2014-11-28 16:59:16 +01:00
|
|
|
int snd_dice_create_hwdep(struct snd_dice *dice);
|
|
|
|
|
|
2014-11-28 16:59:17 +01:00
|
|
|
void snd_dice_create_proc(struct snd_dice *dice);
|
|
|
|
|
|
2014-12-08 16:10:39 +01:00
|
|
|
int snd_dice_create_midi(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 16:59:13 +01:00
|
|
|
#endif
|