bebob: Add support for Focusrite Saffire/SaffirePro series

This commit allows this driver to support all of models which Focusrite
produces with DM1000/BeBoB. They are:
 - Saffire
 - Saffire LE
 - SaffirePro 10 I/O
 - SaffirePro 26 I/O

This commit adds Focusrite specific operations:
1. Get source of clock
2. Get/Set sampling frequency
3. Get metering information

The driver uses these functionalities to read/write specific address by async
transaction.
bebob: Add support for M-Audio usual Firewire series

This commit allows this driver to support some models which M-Audio produces
with DM1000/DM1000E with usual firmware. They are:
 - Firewire 410
 - Firewire AudioPhile
 - Firewire Solo
 - Ozonic
 - NRV10
 - FirewireLightBridge

According to person of BridgeCo, Some models are produced with 'Pre-BeBoB'. This
means that these products were released before BeBoB was officially produced. So
these models have some quirks.

M-Audio usual firmware quirks:
 - Just after powering on, 'Firewire 410' waits to download firmware. This
   state is changed when receiving cue. Then bus reset is generated and the
   device is recognized as a different model with the uploaded firmware.
 - 'Firewire Audiophile' also waits to download firmware but its
   vendor id/model id is the same as the one after loading firmware.
 - The information of channel mapping for MIDI conformant data channel is
   invalid against BridgeCo specification.

This commit adds some codes for these quirks but don't support to upload
firmware.

This commit also adds specific operations to get metering information. The
metering information also includes status of clock synchronization if the model
supports to switch source of clock.

The specification of FirewireLightBridge is unknown. So in this time, normal
operations are applied for this model.
bebob: Send a cue to load firmware for M-Audio Firewire series

Just powering on, these devices below wait to download firmware.
 - Firewire Audiophile
 - Firewire 410

But firmware version 5058 or later, flash memory in the device stores the
firmware. So this driver can enable these devices by sending a certain cue to
load the firmware.
bebob: Add support for M-Audio special Firewire series

This commit allows this driver to support some models which M-Audio produces
with DM1000 but its firmware is special. They are:
 - Firewire 1814
 - ProjectMix I/O

They have heavily customized firmware. The usual operations can't be applied to
them. For this reason, this commit adds a model specific member in 'struct
snd_bebob' and some model specific functions. Some parameters are write-only so
this commit also adds control interface for applications.

M-Audio special firmware quirks:
 - Just after powering on, they wait to download firmware. This state is
   changed when receiving cue. Then bus reset is generated and the device is
   recognized as a different model with the uploaded firmware.
 - They don't respond against BridgeCo AV/C extension commands. So drivers
   can't get their stream formations and so on.
 - They do not start to transmit packets only by establishing connection but
   also by receiving SIGNAL FORMAT command.
 - They often handle requests without responding. In this reason, this driver
   often fail to handle them correctly.

This module don't support to upload firmware.

Here are three examples of transactions between BeBoB driver and M-Audio
Firewire 1814. An fallback at timeout in the operations for CMP was already
added by previous commit. But for isochronous resource management, no fallbacks
are added. Further works are needed for Linux Firewire Subsystem.

At releasing connections/resources for both direction:
[27200.724273] firewire_ohci 0000:0c:06.0: AT spd 2 tl 28, ffc0 -> ffc1, ack_pending , Lk req, fffff0000984 8,2
[27200.724921] firewire_ohci 0000:0c:06.0: AR spd 2 tl 28, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27200.725037] firewire_ohci 0000:0c:06.0: AT spd 0 tl 29, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27200.725598] firewire_ohci 0000:0c:06.0: AR spd 2 tl 29, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27200.725714] firewire_ohci 0000:0c:06.0: AT spd 0 tl 2a, ffc0 -> ffc1, ack_pending , Lk req, fffff0000220 8,2
[27202.727199] firewire_ohci 0000:0c:06.0: AT spd 0 tl 2b, ffc0 -> ffc1, ack_pending , Lk req, fffff0000220 8,2
[27202.727735] firewire_ohci 0000:0c:06.0: AR spd 2 tl 2b, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27202.727858] firewire_ohci 0000:0c:06.0: AT spd 2 tl 2c, ffc0 -> ffc1, ack_pending , Lk req, fffff0000904 8,2
[27204.750950] firewire_ohci 0000:0c:06.0: AT spd 2 tl 2d, ffc0 -> ffc1, ack_pending , Lk req, fffff0000904 8,2
[27206.777677] firewire_ohci 0000:0c:06.0: AT spd 2 tl 2e, ffc0 -> ffc1, ack_pending , Lk req, fffff0000904 8,2
[27208.779327] snd-bebob fw1.0: transaction failed: timeout
[27208.779333] snd-bebob fw1.0: oPCR0: plug is still connected
(The device handled a first operation for oPCR0 but not respond.)

At releasing connections/resources for both direction:
[27603.200092] firewire_ohci 0000:0c:06.0: AT spd 2 tl 02, ffc0 -> ffc1, ack_pending , Lk req, fffff0000904 8,2
[27603.200455] firewire_ohci 0000:0c:06.0: AR spd 2 tl 02, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27603.200629] firewire_ohci 0000:0c:06.0: AT spd 0 tl 03, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27605.203315] firewire_ohci 0000:0c:06.0: AT spd 0 tl 04, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27605.203962] firewire_ohci 0000:0c:06.0: AR spd 2 tl 04, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27605.204077] firewire_ohci 0000:0c:06.0: AT spd 0 tl 05, ffc0 -> ffc1, ack_pending , Lk req, fffff0000220 8,2
[27605.204507] firewire_ohci 0000:0c:06.0: AR spd 2 tl 05, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27605.204569] snd-bebob fw1.0: isochronous resource deallocation failed
(The device handled a first operation for CSR_CHANNELS_AVAILABLE_HI but not respond.)

At keeping resources and establising connections:
[27212.950366] firewire_ohci 0000:0c:06.0: AT spd 0 tl 35, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27212.950922] firewire_ohci 0000:0c:06.0: AR spd 2 tl 35, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.951060] firewire_ohci 0000:0c:06.0: AT spd 0 tl 36, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27212.951505] firewire_ohci 0000:0c:06.0: AR spd 2 tl 36, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.951590] firewire_ohci 0000:0c:06.0: AT spd 0 tl 37, ffc0 -> ffc1, ack_pending , Lk req, fffff0000220 8,2
[27212.952101] firewire_ohci 0000:0c:06.0: AR spd 2 tl 37, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.952220] firewire_ohci 0000:0c:06.0: AT spd 2 tl 38, ffc0 -> ffc1, ack_pending , Lk req, fffff0000904 8,2
[27212.952568] firewire_ohci 0000:0c:06.0: AR spd 2 tl 38, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.952715] firewire_ohci 0000:0c:06.0: AT spd 2 tl 39, ffc0 -> ffc1, ack_pending , Lk req, fffff0000904 8,2
[27212.953044] firewire_ohci 0000:0c:06.0: AR spd 2 tl 39, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.953178] firewire_ohci 0000:0c:06.0: AT spd 0 tl 3a, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27212.953504] firewire_ohci 0000:0c:06.0: AR spd 2 tl 3a, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.953588] firewire_ohci 0000:0c:06.0: AT spd 0 tl 3b, ffc0 -> ffc1, ack_pending , Lk req, fffff0000224 8,2
[27212.954017] firewire_ohci 0000:0c:06.0: AR spd 2 tl 3b, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.954077] firewire_ohci 0000:0c:06.0: AT spd 0 tl 3c, ffc0 -> ffc1, ack_pending , Lk req, fffff0000220 8,2
[27212.954364] firewire_ohci 0000:0c:06.0: AR spd 2 tl 3c, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27212.954429] firewire_ohci 0000:0c:06.0: AT spd 2 tl 3d, ffc0 -> ffc1, ack_pending , Lk req, fffff0000984 8,2
[27214.980602] firewire_ohci 0000:0c:06.0: AT spd 2 tl 3e, ffc0 -> ffc1, ack_pending , Lk req, fffff0000984 8,2
[27214.981135] firewire_ohci 0000:0c:06.0: AR spd 2 tl 3e, ffc1 -> ffc0, ack_complete, Lk resp 4,2
[27214.981195] snd-bebob fw1.0: iPCR0: plug is already in use
(The device handled a first operation for iPCR0 but not respond.)
speakers: Rename to oxfw

This commit rename 'firewire-speakers' to 'oxfw' to enhance support for
devices based on OXFW970/971.

And a line is added for MODULE_ALIAS.
oxfw: Move to its own directory

Followed commits add much codes. I'll split them to some files.
In this reason, this commit make own directory and move current
source to it.
oxfw: Split stream functionality to a new file and add a header file

To make it easy to work in followed commit.

And this commit remove 'fw_unit_get()/fw_unit_put()' because these
are called by helper functions in 'snd-firewire-lib'.
oxfw: Split PCM functionality to a new file

To make it easy to work in followed commit.
oxfw: Split control functionality to a new file

To make it easy to work in followed commit.
oxfw: Change the way to name card

'struct snd_card' has 4 members for name. They're 'driver', 'shortname',
'longname' and 'mixername'. The 'driver' is used to detect card
Configuration file but the others are not used for important
functionality. So it's OK to name them with the information from config
ROM.

This commit adds 'name_card()' function and change the way to name card.
The 'driver' is still given by 'struct device_info'. The 'shortname' and
'mixername' is given by 'model' and the 'longname' is given by 'vendor'
and 'model'.
oxfw: Change the way to make PCM rules/constraints

For PCM rules/constrains, drivers need to know stream formation at each
supported sampling rates in advance. This commit adds
'struct snd_oxfw_stream_formation' to save formation information.

According to datasheet of OXFW970/971, they support 32.0kHz to 196.0kHz.
So this commit adds 'rx_stream_formations' member to 'struct snd_oxfw'. It's
an array with 7 elements. Each element corresponds to each sampling rate.

With these data structure, this commit changes the way to make PCM
rules/constraints.

I don't know whether Griffin/LaCie devices supports SINGLE/LIST subfunction
'AV/C Stream Format Information' command. So this commit adds codes to
generate formations for them.
oxfw: Add proc interface for debugging purpose

The previous commit adds stream formation. This commit adds proc interface
to get information about:
 - stream formation
 - current sampling rate
oxfw: Change the way to start stream

In past commit, driver can keep formations for each sampling rate. So its
stream functionality can set its formation when given sampling rate.

But PCM functionality still set it. This commit move some codes to set
stream formation from PCM functionality to stream functionality.
oxfw: Add some AV/C commands to get stream formation and supported sample rate

OXFW970/971 may supports AV/C Stream Format Information Specification 1.1
Working Draft (Apr 2005, 1394TA). So this driver uses 'EXTENDED STREAM FORMAT
INFORMATION' command.

This command has two subfunctions, 'SINGLE' and 'LIST'. Drivers can use
'SINGLE' subfunction to know current formation of AMDTP stream, Drivers can
use 'LIST' subfunction to know an available formation of AMDTP stream in a
certain sampling rate. Followed commit adds parser for returned information.

This commit adds 'inquiry' version of 'PLUG SIGNAL FORMAT' command. When
device doesn't support 'LIST' subfunction of 'AV/C Stream Format Information
command, this driver uses 'inquiry' command to get supported sampling rates.
oxfw: Add support for Behringer/Mackie devices

FFADO project have already identified that some devices produced by
Behringer/Mackie are based on OXFW970/971.

Behringer/Mackie devices support capture/playback of PCM-samples and some
of them supports capture/playback of MIDI-messages. Followed commits will
add these functionalities.

They support 'AV/C Stream Format Information' command. But some of them
don't implement 'LIST' subfunction. So this commit uses an assumption
that 'if they don't implement it, they don't change formation of stream
for each sampling rate'.

With this assumption, this driver generate formations for the devices by:
 1.getting current formation by SINGLE subfunction
 2.getting supported sampling rates
 3.applying current formation for all of supported sampling rates
oxfw: Add support AMDTP in-stream and PCM capture

Previous commit adds support for some devices which can capture PCM samples.
These devices transmit AMDTP stream in non-blocking mode. The stream from
these devices has a quirk for 'presentation timestamp'.

The sequence of 'presentation timestamp' is invalid even if header of packet
shows 'CIP header with SYT field'. So this driver can't reuse the timestamp
for out stream.

In this reason, this driver handles both streams separately.

These are examples of a sequence of packets transmitted by Behringer F-Control
Audio 202.

When driver gives no out-stream:
Index	Payload	CIP_Header_0	CIP_Header_1
38	14	00020092	900103D1
39	12	00020098	900102FF
40	12	0002009D	9001027F
41	14	000200A2	90010396
42	14	000200A8	900102E8
43	12	000200AE	90010219
44	14	000200B3	90010331
45	12	000200B9	9001025F
46	14	000200BE	90010376
47	12	000200C4	900102A1
00	12	000200C9	9001023E
01	14	000200CE	90010358
02	12	000200D4	90010289
03	16	000200D9	900103A3
04	12	000200E0	900102DD
05	14	000200E5	900103F1
06	12	000200EB	90010335
07	12	000200F0	90010263
08	14	000200F5	9001037C
09	12	000200FB	900102AE

When driver gives out-stream:
Index	Payload	CIP_Header_0	CIP_Header_1
38	12	000200BD	900104A8
39	14	000200C2	900104A8
40	12	000200C8	900104AC
41	14	000200CD	900104A9
42	12	000200D3	900104B1
43	14	000200D8	900104A8
44	12	000200DE	900104AA
45	14	000200E3	900104A9
46	14	000200E9	900104AE
47	12	000200EF	900104A8
00	14	000200F4	900104AD
01	12	000200FA	900104A7
02	14	000200FF	900104A9
03	12	00020005	900104A9
04	14	0002000A	900104B1
05	12	00020010	900104AA
06	14	00020015	900104AD
07	12	0002001B	900104A7
08	14	00020020	900104AC
09	12	00020026	900104A7
oxfw: Add support for capture/playback MIDI messages

I assume that 'if the device has MIDI comformant data channels in its
stream formation, the device has one MIDI port'. With this assumption,
this driver create MIDI devices.

When no streams have already started, MIDI functionality starts stream
with current sampling rate.

When MIDI functionality has already starts some streams and PCM
functionality is going to start streams at different sampling rate,
this driver stops streams once and changes sampling rate, then restarts
streams.
oxfw: Add hwdep interface

This interface is designed for mixer/control application. To use hwdep
interface, the application can get information about firewire node, can
lock/unlock kernel streaming and can get notification at starting/stopping
kernel streaming.