fireworks: Add skelton for Fireworks based devices

This commit adds a new driver with no functionality. This driver just
creates/removes card instance according to callbacks.

Fireworks is a board module which Echo Audio produced. This module consists
of three chipsets:
 - Communication chipset for IEEE1394 PHY/Link and IEC 61883-1/6
 - DSP or/and FPGA for signal processing
 - Flash Memory to store firmwares

Current supported devices:
 - Mackie Onyx 400F/1200F
 - Echo AudioFire12/8(until 2009 July)
 - Echo AudioFire2/4/Pre8/8(since 2009 July)
 - Echo Fireworks 8/HDMI
 - Gibson Robot Interface pack/GoldTop
fireworks: Add transaction and some commands

Fireworks uses own command and response. This commit adds functionality to
transact and adds some commands required for sound card instance and kernel
streaming.

There are two ways to deliver substance of this transaction:
1.AV/C vendor dependent command for command/response
2.Async transaction to specific addresses for command/response

By way 1, I confirm AudioFire12 cannot correctly response to some commands with
firmware version 5.0 or later. This is also confirmed by FFADO. So this module
implement way 2.

The address for response gives an issue. When this driver allocate own callback
function into the address, then no one can allocate its own callback function.
This situation is not good for applications in user-land. Currently this commit
don't solve this issue. This issue is solved in later commit.

I note there is a command to change the address for response if the device
supports. But this module uses default value. So users should not execute this
command as long as hoping this module works correctly.
fireworks: Add connection and stream management

Fireworks manages connections by CMP and can transmit/receive AMDTP streams
with a few quirks. This commit adds functionality to start/stop the streams.

Major Fireworks products don't support 'SYT-Match' mode, except for
AudioFire12/8(till 2009 July) with firmware version 1.0. Already in previous
commit, this driver don't support such old firmwares in previous commit. So
this commit adds support for non 'SYT-Match' mode.

I note that there is a short gap for MIDI streams when starting PCM data. When
AMDTP streams are running only for MIDI data and PCM data is going to be joined
at different sampling rate, then AMDTP streams are stopped once and started
again after changing sampling rate.

Fireworks quirks:

1.Fireworks transmits packets with both TAG0 and TAG1
In IEC 61883-1, each common isochronous packet (CIP) has 'tag' field in its
packet header. The value is generally 0x01 ('CIP header is included' = TAG1).
But Fireworks in 'IEC 61883 compliant mode' transmits 'no data' packet with 0x00
('No CIP header is included' = TAG0) but actually the packet includes CIP
structure. To handle 'presentation timestamp' for duplex streams
synchronization, this packets must be handled.

2.Fireworks transmits 'no data' packet out of specification
Fireworks transmits 'no data' packet with 'NO-DATA' FDF and no dummy data. It
includes CIP headers only. In IEC 61883-6, 'no data' packet is generated by two
ways. One is empty CIP packet defined in IEC 61883-1. Another is
'special non-empty packet' defined in IEC 61883-6. Fireworks uses strange
combination of them.

3.Fireworks can handle MIDI messages in the first 8 data blocks of out-packet
Fireworks ignores MIDI messages in other data blocks.

4.AudioFirePre8 transmits packets with wrong data block size
One of Fireworks device, AudioFirePre8, always reports 8 data block size in
transmitted packets and increments the data block counter by 8. But this is not
actual value.

I confirm them with firmware version 4.8 or later with Windows. According to
a contact persion in Echo Audio, there is no difference between firmwares
installed by Windows/OS X.
fireworks: Add proc interface for debugging purpose

This commit adds proc interface to output infomation for debugging.
 - firmware information
 - sampling rate and clock source
 - physical metering (linear value)
fireworks: Add MIDI interface

This commit adds a functionality to capture/playback MIDI messages.

When no AMDTP streams are running, this module starts AMDTP stream at current
sampling rate for MIDI stream.
fireworks: Add PCM interface

This commit adds a functionality to capture/playback PCM samples.

When AMDTP stream is already running for PCM or the source of clock is not
internal, available sampling rate is limited at current one.
fireworks: 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.
fireworks: Add command/response functionality into hwdep interface

This commit adds two functionality for hwdep interface, adds two parameters for
this module, add a node for proc interface.

To receive responses from devices, this module already allocate own callback
into private address area in host controller. This means no one can allocate
its own callback to the address. So this module must give a way for user
applications to receive responses.

This commit adds a functionality to receive responses via hwdep interface. The
application can receive responses to read from this interface. To achieve this,
this commit adds a buffer to queue responses. The default size of this buffer is
1024 bytes. This size can be changed to give preferrable size to
'resp_buf_size' parameter for this module. The application should notice rest
of space in this buffer because this module don't push responses when this
buffer has no space.

Additionaly, this commit adds a functionality to transmit commands via hwdep
interface. The application can transmit commands to write into this interface.
I note that the application can transmit one command at once, but can receive
as many responses as possible untill the user-buffer is full.

When using these interfaces, the application must keep maximum number of
sequence number within the number in firewire.h because this module uses this
number to distinguish the response is against the command by the application or
this module.

Usually responses against commands which the application transmits are pushed
into this buffer. But to enable 'resp_buf_debug' parameter for this module, all
responses are pushed into the buffer. When using this mode, I reccomend to
expand the size of buffer.

Finally this commit adds a new node into proc interface to output status of the
buffer.
bebob: Add skelton for BeBoB based devices

This commit add a new driver for BeBoB based devices with no functionality. This driver just create/remove
card instance according to callbacks.

BeBoB is 'BridgeCo enhanced Breakout Box'. This is installed to firewire devices with
DM1000/1000E/1100/1500 chipset. It gives common way for host system to handle BeBoB based devices.

Current supported devices:
 - Edirol FA-66/FA-101
 - PreSonus FIREBOX/FIREPOD/Inspire1394
 - BridgeCo RDAudio1/Audio5
 - Mackie Onyx 1220/1620/1640 (Firewire I/O Card)
 - Mackie d.2 (Firewire Option)
 - Stanton FinalScratch 2 (ScratchAmp)
 - Tascam IF-FW DM
 - Behringer XENIX UFX 1204/1604
 - Behringer Digital Mixer X32 series (X-UF Card)
 - Apogee Rosetta 200/Rosetta 400 (X-FireWire card)
 - Apogee DA-16X/AD-16X/DD-16X (X-FireWire card)
 - Apogee Ensemble
 - ESI Quotafire610
 - AcousticReality eARMasterOne
 - CME MatrixKFW
 - Phonix Helix Board 12 MkII/18 MkII/24 MkII
 - Phonic Helix Board 12 Universal/18 Universal/24 Universal
 - Lynx Aurora 8/16 (LT-FW)
 - ICON FireXon
 - PrismSound Orpheus/ADA-8XR

Devices possible to be supported if identifying IDs:
 - Apogee Mini-Me Firewire/Mini-DAC Firewire
 - Behringer FCA 610/1616
 - Cakewalk Sonar Power Studio 66
 - CME UF400e
 - ESI Quotafire XL
 - Infrasonic DewX/Windy6
 - Mackie Digital X Bus x.200/400
 - Phonic Helix Board 12/18/24
 - Phonic FireFly 202/302
 - Rolf Spuler Firewire Guitar
bebob: Add commands and connections/streams management

This commit adds management functionality for connections and streams.
DM1000/BeBob uses CMP to manage connections and uses AMDTP for streams.

This commit also adds some BridgeCo's AV/C extension commands. There are many
BridgeCo's AV/C extension commands but this commit adds below commands to get
device's capability and status:

 1.Extended Plug Info commands
  - Plug Channel Position Specific Data
  - Plug Type Specific Data
  - Cluster(Section) Info Specific Data
  - Plug Input Specific Data
 2.Extended Stream Format Information commands
  - Extended Stream Format Information Command - Single Request

For Extended Plug Info commands for Cluster Info Specific Data, I pick up
'section' instead of 'cluster' from document to prevent from misunderstanding
because 'cluster' is also used in IEC 61883-6.
bebob: Add proc interface for debugging purpose

This commit adds proc interface to get information for debugging.
 - firmware information
 - stream formation
 - current clock source and sampling rate
bebob: Add MIDI interface

This commit adds a functionality to capture/playback MIDI messages.

When no AMDTP streams are running, this module starts AMDTP stream at current
sampling rate for MIDI stream.
bebob: Add PCM interface

This commit adds a functionality to capture/playback PCM samples.

When AMDTP stream is already running for PCM or the source of clock is not
internal, available sampling rate is limited at current one.
bebob: 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.
bebob: Prepare for device specific operations

This commit is for some devices which have its own operations or quirks.

Many functionality should be implemented in user land. Then this commit adds
functionality related to stream such as sampling frequency or clock source. For
help to debug, this commit adds the functionality to get metering information
if it's available.

To help these functionalities, this commit adds some AV/C commands defined in
'AV/C Audio Subunit Specification (1394TA).
bebob: Add support for Terratec PHASE, EWS series and Aureon

This commit allows this driver to support all of models which Terratec produced
with DM1000/BeBoB. They are:
 - PHASE 24 FW
 - PHASE X24 FW
 - PHASE 88 Rack FW
 - EWS MIC2
 - EWS MIC4
 - Aureon 7.1 Firewire

For Phase series, this commit adds a Terratec specific operation. To get source
of clock. AV/C Audio Subunit command is used.

For EWS series and Aureon, this module uses normal operations.
bebob: Add support for Yamaha GO series

This commit allows this driver to support all of models which Yamaha produced
with DM1000/BeBoB. They are:
 - GO44
 - GO46

This commit adds Yamaha specific operations. To get source of clock, AV/C Audio
Subunit command is used.

I note that their appearances are similar to some models of TerraTec; 'Go44' is
similar to 'PHASE 24 FW' and 'GO46' is similar to 'PHASE X24 FW'. But their
combination of Audio/Music subunit are a bit different.
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: 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.