2011-03-15 09:53:21 +03:00
# ifndef SOUND_FIREWIRE_AMDTP_H_INCLUDED
# define SOUND_FIREWIRE_AMDTP_H_INCLUDED
2011-09-05 00:15:44 +04:00
# include <linux/err.h>
2012-05-14 00:03:09 +04:00
# include <linux/interrupt.h>
2011-03-15 09:53:21 +03:00
# include <linux/mutex.h>
2013-11-19 08:29:24 +04:00
# include <sound/asound.h>
2011-03-15 09:53:21 +03:00
# include "packets-buffer.h"
/**
2014-04-25 17:44:42 +04:00
* enum cip_flags - describes details of the streaming protocol
2011-03-15 09:53:21 +03:00
* @ CIP_NONBLOCKING : In non - blocking mode , each packet contains
* sample_rate / 8000 samples , with rounding up or down to adjust
* for clock skew and left - over fractional samples . This should
* be used if supported by the device .
2011-09-05 00:12:48 +04:00
* @ CIP_BLOCKING : In blocking mode , each packet contains either zero or
* SYT_INTERVAL samples , with these two types alternating so that
* the overall sample rate comes out right .
2014-04-25 17:44:49 +04:00
* @ CIP_SYNC_TO_DEVICE : In sync to device mode , time stamp in out packets is
* generated by in packets . Defaultly this driver generates timestamp .
2014-04-25 17:45:03 +04:00
* @ CIP_EMPTY_WITH_TAG0 : Only for in - stream . Empty in - packets have TAG0 .
2014-04-25 17:45:04 +04:00
* @ CIP_DBC_IS_END_EVENT : Only for in - stream . The value of dbc in an in - packet
* corresponds to the end of event in the packet . Out of IEC 61883.
2014-04-25 17:45:05 +04:00
* @ CIP_WRONG_DBS : Only for in - stream . The value of dbs is wrong in in - packets .
* The value of data_block_quadlets is used instead of reported value .
2014-04-25 17:45:07 +04:00
* @ SKIP_DBC_ZERO_CHECK : Only for in - stream . Packets with zero in dbc is
* skipped for detecting discontinuity .
2014-04-25 17:45:16 +04:00
* @ CIP_SKIP_INIT_DBC_CHECK : Only for in - stream . The value of dbc in first
* packet is not continuous from an initial value .
2014-04-25 17:45:27 +04:00
* @ CIP_EMPTY_HAS_WRONG_DBC : Only for in - stream . The value of dbc in empty
* packet is wrong but the others are correct .
2011-03-15 09:53:21 +03:00
*/
2014-04-25 17:44:42 +04:00
enum cip_flags {
2014-04-25 17:44:49 +04:00
CIP_NONBLOCKING = 0x00 ,
CIP_BLOCKING = 0x01 ,
2014-04-25 17:44:51 +04:00
CIP_SYNC_TO_DEVICE = 0x02 ,
2014-04-25 17:45:03 +04:00
CIP_EMPTY_WITH_TAG0 = 0x04 ,
2014-04-25 17:45:04 +04:00
CIP_DBC_IS_END_EVENT = 0x08 ,
2014-04-25 17:45:05 +04:00
CIP_WRONG_DBS = 0x10 ,
2014-04-25 17:45:07 +04:00
CIP_SKIP_DBC_ZERO_CHECK = 0x20 ,
2014-04-25 17:45:16 +04:00
CIP_SKIP_INIT_DBC_CHECK = 0x40 ,
2014-04-25 17:45:27 +04:00
CIP_EMPTY_HAS_WRONG_DBC = 0x80 ,
2011-03-15 09:53:21 +03:00
} ;
/**
* enum cip_sfc - a stream ' s sample rate
*/
enum cip_sfc {
CIP_SFC_32000 = 0 ,
CIP_SFC_44100 = 1 ,
CIP_SFC_48000 = 2 ,
CIP_SFC_88200 = 3 ,
CIP_SFC_96000 = 4 ,
CIP_SFC_176400 = 5 ,
CIP_SFC_192000 = 6 ,
2011-09-05 00:16:10 +04:00
CIP_SFC_COUNT
2011-03-15 09:53:21 +03:00
} ;
2014-04-25 17:44:46 +04:00
# define AMDTP_IN_PCM_FORMAT_BITS SNDRV_PCM_FMTBIT_S32
2011-03-15 09:53:21 +03:00
# define AMDTP_OUT_PCM_FORMAT_BITS (SNDRV_PCM_FMTBIT_S16 | \
SNDRV_PCM_FMTBIT_S32 )
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 17:44:47 +04:00
2014-04-25 17:44:50 +04:00
/*
* This module supports maximum 64 PCM channels for one PCM stream
* This is for our convenience .
*/
# define AMDTP_MAX_CHANNELS_FOR_PCM 64
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 17:44:47 +04:00
/*
* AMDTP packet can include channels for MIDI conformant data .
* Each MIDI conformant data channel includes 8 MPX - MIDI data stream .
* Each MPX - MIDI data stream includes one data stream from / to MIDI ports .
*
* This module supports maximum 1 MIDI conformant data channels .
* Then this AMDTP packets can transfer maximum 8 MIDI data streams .
*/
# define AMDTP_MAX_CHANNELS_FOR_MIDI 1
2011-03-15 09:53:21 +03:00
struct fw_unit ;
struct fw_iso_context ;
struct snd_pcm_substream ;
2014-04-25 17:44:52 +04:00
struct snd_pcm_runtime ;
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 17:44:47 +04:00
struct snd_rawmidi_substream ;
2011-03-15 09:53:21 +03:00
2014-04-25 17:44:44 +04:00
enum amdtp_stream_direction {
AMDTP_OUT_STREAM = 0 ,
AMDTP_IN_STREAM
} ;
2014-04-25 17:44:42 +04:00
struct amdtp_stream {
2011-03-15 09:53:21 +03:00
struct fw_unit * unit ;
2014-04-25 17:44:42 +04:00
enum cip_flags flags ;
2014-04-25 17:44:44 +04:00
enum amdtp_stream_direction direction ;
2011-03-15 09:53:21 +03:00
struct fw_iso_context * context ;
struct mutex mutex ;
enum cip_sfc sfc ;
unsigned int data_block_quadlets ;
unsigned int pcm_channels ;
unsigned int midi_ports ;
2014-04-25 17:44:42 +04:00
void ( * transfer_samples ) ( struct amdtp_stream * s ,
2011-03-15 09:53:21 +03:00
struct snd_pcm_substream * pcm ,
__be32 * buffer , unsigned int frames ) ;
2014-04-25 17:44:50 +04:00
u8 pcm_positions [ AMDTP_MAX_CHANNELS_FOR_PCM ] ;
u8 midi_position ;
2011-03-15 09:53:21 +03:00
unsigned int syt_interval ;
2011-09-05 00:12:48 +04:00
unsigned int transfer_delay ;
2011-03-15 09:53:21 +03:00
unsigned int source_node_id_field ;
struct iso_packets_buffer buffer ;
struct snd_pcm_substream * pcm ;
2012-05-14 00:03:09 +04:00
struct tasklet_struct period_tasklet ;
2011-03-15 09:53:21 +03:00
2011-03-15 09:57:24 +03:00
int packet_index ;
2011-03-15 09:53:21 +03:00
unsigned int data_block_counter ;
unsigned int data_block_state ;
unsigned int last_syt_offset ;
unsigned int syt_offset_state ;
unsigned int pcm_buffer_pointer ;
unsigned int pcm_period_pointer ;
2012-05-13 21:07:22 +04:00
bool pointer_flush ;
2014-08-29 08:40:45 +04:00
bool double_pcm_frames ;
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 17:44:47 +04:00
struct snd_rawmidi_substream * midi [ AMDTP_MAX_CHANNELS_FOR_MIDI * 8 ] ;
2014-04-25 17:44:49 +04:00
2014-04-25 17:45:06 +04:00
/* quirk: fixed interval of dbc between previos/current packets. */
unsigned int tx_dbc_interval ;
2014-04-25 17:45:10 +04:00
/* quirk: the first count of data blocks in an rx packet for MIDI */
unsigned int rx_blocks_for_midi ;
2014-04-25 17:44:49 +04:00
bool callbacked ;
wait_queue_head_t callback_wait ;
struct amdtp_stream * sync_slave ;
2011-03-15 09:53:21 +03:00
} ;
2014-04-25 17:44:42 +04:00
int amdtp_stream_init ( struct amdtp_stream * s , struct fw_unit * unit ,
2014-04-25 17:44:44 +04:00
enum amdtp_stream_direction dir ,
2014-04-25 17:44:42 +04:00
enum cip_flags flags ) ;
void amdtp_stream_destroy ( struct amdtp_stream * s ) ;
2011-03-15 09:53:21 +03:00
2014-04-25 17:44:42 +04:00
void amdtp_stream_set_parameters ( struct amdtp_stream * s ,
unsigned int rate ,
unsigned int pcm_channels ,
unsigned int midi_ports ) ;
unsigned int amdtp_stream_get_max_payload ( struct amdtp_stream * s ) ;
2011-03-15 09:53:21 +03:00
2014-04-25 17:44:42 +04:00
int amdtp_stream_start ( struct amdtp_stream * s , int channel , int speed ) ;
void amdtp_stream_update ( struct amdtp_stream * s ) ;
void amdtp_stream_stop ( struct amdtp_stream * s ) ;
2011-03-15 09:53:21 +03:00
2014-04-25 17:44:52 +04:00
int amdtp_stream_add_pcm_hw_constraints ( struct amdtp_stream * s ,
struct snd_pcm_runtime * runtime ) ;
2014-04-25 17:44:42 +04:00
void amdtp_stream_set_pcm_format ( struct amdtp_stream * s ,
snd_pcm_format_t format ) ;
void amdtp_stream_pcm_prepare ( struct amdtp_stream * s ) ;
unsigned long amdtp_stream_pcm_pointer ( struct amdtp_stream * s ) ;
void amdtp_stream_pcm_abort ( struct amdtp_stream * s ) ;
2011-03-15 09:53:21 +03:00
2011-10-16 23:39:00 +04:00
extern const unsigned int amdtp_syt_intervals [ CIP_SFC_COUNT ] ;
2014-04-25 17:44:59 +04:00
extern const unsigned int amdtp_rate_table [ CIP_SFC_COUNT ] ;
2011-09-05 00:16:10 +04:00
2014-04-25 17:44:42 +04:00
/**
* amdtp_stream_running - check stream is running or not
* @ s : the AMDTP stream
*
* If this function returns true , the stream is running .
*/
static inline bool amdtp_stream_running ( struct amdtp_stream * s )
2011-09-05 00:15:44 +04:00
{
return ! IS_ERR ( s - > context ) ;
}
2011-03-15 09:57:24 +03:00
/**
2014-04-25 17:44:42 +04:00
* amdtp_streaming_error - check for streaming error
* @ s : the AMDTP stream
2011-03-15 09:57:24 +03:00
*
* If this function returns true , the stream ' s packet queue has stopped due to
* an asynchronous error .
*/
2014-04-25 17:44:42 +04:00
static inline bool amdtp_streaming_error ( struct amdtp_stream * s )
2011-03-15 09:57:24 +03:00
{
return s - > packet_index < 0 ;
}
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 17:44:47 +04:00
/**
* amdtp_stream_pcm_running - check PCM substream is running or not
* @ s : the AMDTP stream
*
* If this function returns true , PCM substream in the AMDTP stream is running .
*/
static inline bool amdtp_stream_pcm_running ( struct amdtp_stream * s )
{
return ! ! s - > pcm ;
}
2011-03-15 09:53:21 +03:00
/**
2014-04-25 17:44:42 +04:00
* amdtp_stream_pcm_trigger - start / stop playback from a PCM device
* @ s : the AMDTP stream
2011-03-15 09:53:21 +03:00
* @ pcm : the PCM device to be started , or % NULL to stop the current device
*
* Call this function on a running isochronous stream to enable the actual
* transmission of PCM data . This function should be called from the PCM
* device ' s . trigger callback .
*/
2014-04-25 17:44:42 +04:00
static inline void amdtp_stream_pcm_trigger ( struct amdtp_stream * s ,
struct snd_pcm_substream * pcm )
2011-03-15 09:53:21 +03:00
{
ACCESS_ONCE ( s - > pcm ) = pcm ;
}
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 17:44:47 +04:00
/**
* amdtp_stream_midi_trigger - start / stop playback / capture with a MIDI device
* @ s : the AMDTP stream
* @ port : index of MIDI port
* @ midi : the MIDI device to be started , or % NULL to stop the current device
*
* Call this function on a running isochronous stream to enable the actual
* transmission of MIDI data . This function should be called from the MIDI
* device ' s . trigger callback .
*/
static inline void amdtp_stream_midi_trigger ( struct amdtp_stream * s ,
unsigned int port ,
struct snd_rawmidi_substream * midi )
{
if ( port < s - > midi_ports )
ACCESS_ONCE ( s - > midi [ port ] ) = midi ;
}
2011-03-15 09:53:21 +03:00
static inline bool cip_sfc_is_base_44100 ( enum cip_sfc sfc )
{
return sfc & 1 ;
}
2014-04-25 17:44:49 +04:00
static inline void amdtp_stream_set_sync ( enum cip_flags sync_mode ,
struct amdtp_stream * master ,
struct amdtp_stream * slave )
{
if ( sync_mode = = CIP_SYNC_TO_DEVICE ) {
master - > flags | = CIP_SYNC_TO_DEVICE ;
slave - > flags | = CIP_SYNC_TO_DEVICE ;
master - > sync_slave = slave ;
} else {
master - > flags & = ~ CIP_SYNC_TO_DEVICE ;
slave - > flags & = ~ CIP_SYNC_TO_DEVICE ;
master - > sync_slave = NULL ;
}
slave - > sync_slave = NULL ;
}
/**
* amdtp_stream_wait_callback - sleep till callbacked or timeout
* @ s : the AMDTP stream
* @ timeout : msec till timeout
*
* If this function return false , the AMDTP stream should be stopped .
*/
static inline bool amdtp_stream_wait_callback ( struct amdtp_stream * s ,
unsigned int timeout )
{
return wait_event_timeout ( s - > callback_wait ,
s - > callbacked = = true ,
msecs_to_jiffies ( timeout ) ) > 0 ;
}
2011-03-15 09:53:21 +03:00
# endif