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 some model specific members in 'struct
snd_bebob' and model specific functions. Some parameters are write-only so this
commit also adds control interface for them.

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 can't handle frequent transactions. In this reason, this driver often
   fail to handle them.

This module don't support to upload firmware.
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
 - Firewire 1814
 - ProjectMix I/O

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.
speakers: Rename to oxfw

This commit rename 'firewire-speakers' to 'oxfw' to enhance support for
devices based on OXFW970/971.
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.
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 four members for name, 'driver', 'shortname',
'longname' and 'mixername'. The 'driver' is used to detect card configuratio
file but the others are not used for important functionality. So I 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 t
get information about stream:
 - 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 decide its formation when given sampling rate.

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

OXFW970/971 may supports AV/C Stream Format Information Specification 1.1
Working Draft (Apr 2005, 1394TA). So this driver uses 'EXTENDED STREAM FORMA
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, drivers can use '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.

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

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.
oxfw: Add support AMDTP in-stream and PCM capture

Previous commit adds support for some devices which can capture PCM samples.
They transmits AMDTP stream in non-blocking mode. This stream has a quirk fo
'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 it for out
stream.

In this reason, this driver handles both streams separately.

For your information, I note the sequence of CIP headers in stream transmitt
by  Behringer F-Control Audio 202:

When this driver gives no out-stream:
Index   Payload CIP_Header_0CIP_Header_1
38  14  00020092900103D1
39  12  00020098900102FF
40  12  0002009D9001027F
41  14  000200A290010396
42  14  000200A8900102E8
43  12  000200AE90010219
44  14  000200B390010331
45  12  000200B99001025F
46  14  000200BE90010376
47  12  000200C4900102A1
00  12  000200C99001023E
01  14  000200CE90010358
02  12  000200D490010289
03  16  000200D9900103A3
04  12  000200E0900102DD
05  14  000200E5900103F1
06  12  000200EB90010335
07  12  000200F090010263
08  14  000200F59001037C
09  12  000200FB900102AE

When this driver gives out-stream:
Index   Payload CIP_Header_0CIP_Header_1
38  12  000200BD900104A8
39  14  000200C2900104A8
40  12  000200C8900104AC
41  14  000200CD900104A9
42  12  000200D3900104B1
43  14  000200D8900104A8
44  12  000200DE900104AA
45  14  000200E3900104A9
46  14  000200E9900104AE
47  12  000200EF900104A8
00  14  000200F4900104AD
01  12  000200FA900104A7
02  14  000200FF900104A9
03  12  00020005900104A9
04  14  0002000A900104B1
05  12  00020010900104AA
06  14  00020015900104AD
07  12  0002001B900104A7
08  14  00020020900104AC
09  12  00020026900104A7
oxfw: Add support for capture/playback MIDI messages

I assume that 'if device formations of stream have MIDI conformant data
channels, the device has one MIDI port'. With this assumption, the driver
create MIDI devices.

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

When MIDI functionality have 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.