This commit adds a new driver for BeBoB based devices with no specific
operations. Currently this driver just create/remove card instance according
to callbacks.

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

Current supported devices:
 - Edirol FA-66/FA-101
 - PreSonus FIREBOX/FIREPOD/FP10/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 F-Control Audio 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

Tested-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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

To receive responses from devices, this driver already allocate own callback
into initial memory space in host controller. This means no one can allocate
its own callback to the address. So this driver 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 driver. The application should notice rest
of space in this buffer because this driver 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 in command within the number in firewire.h because this driver
uses this number to distinguish the response is against the command by the
application or this driver.

Usually responses against commands which the application transmits are pushed
into this buffer. But to enable 'resp_buf_debug' parameter for this driver, 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.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fireworks has a quirk to ignore MIDI messages in data blocks more than 8.
This commit adds a flag for this quirk and codes to skip 8 or more data
blocks to transfer MIDI messages.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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

When no AMDTP streams are running, this driver starts AMDTP stream for MIDI
stream at current sampling rate.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fireworks has a quirk to reset data block counter at bus reset.

This commit adds a flag of CIP_SKIP_DBC_ZERO_CHECK. This flag has an effect
to skip checking dbc continuity when dbc is zero.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fireworks firmware version 5.5 reports fix interval for dbc in each packet.

For example, AudioFire4:
CIP0     CIP1     Payload
00070000 900484FF 72
00070008 9004A8FF 72
00070008 90FFFFFF 02
00070010 9004D0FF 72
00070018 9004C4FF 72
00070020 9004E8FF 72
00070020 90FFFFFF 02
00070028 900410FE 72

The interval of each dbc should be 16 except for empty packet but it's still 8.

This commit adds a flag for this quirk and codes to refer to a fixed value.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

One of Fireworks firmware, named  as 'AudioFire9', seems to transmit
packets with wrong value of dbs. It's always 0x11 but actual size of
data block is different.

This commit adds a flag for this quirk and some codes to calculate
correct size.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fireworks has a quirk for the value of dbc field in transmitted packets.
For Fireworks, dbc means the end of events in current packet. This is out
of specification.

For example, AudioFire4:
CIP0        CIP1    Payload
01070092 90FFFFFF 02
0107009A 9001E17B 3A <-
010700A2 9001F6E5 3A
010700A2 90FFFFFF 02
010700AA 9001104F 3A <-
010700B2 900125B9 3A
010700BA 90013B23 3A
010700BA 90FFFFFF 02
010700C2 9001548E 3A <-
010700CA 900169F8 3A
010700CA 90FFFFFF 02
010700D2 90018362 3A <-
010700DA 900198CC 3A

According to IEC 61883-1/6, a packet following to empty packet has the same
value for its dbc. But for Fireworks, it's incremented and empty packet has
the same value as previous packet in dbc field.

This commit adds a flag for Fireworks and some codes to checking dbc continuity.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fireworks has a quirk to transmit empty packets with TAG0. This commit
adds handling this quirk for full duplex stream synchronization.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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' clock source 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. So this commit
adds support for non 'SYT-Match' clock source modes.

I note that this driver has a short gap for MIDI streams when starting PCM
stream. 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.

Unfortunately, Fireworks is not fully compliant to IEC 61883-1/6. Some commits
following to this commit add these quirks.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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 driver
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. 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 driver uses default value. So users should not execute this
command as long as hoping this driver works correctly.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This commit adds a new driver for devices based on Fireworks. 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

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This commit adds three commands, which may be used by some firewire device
drivers. These commands are defined in 'AV/C Digital Interface Command Set
General Specification Version 4.2 (2004006, 1394TA)'.

1. PLUG INFO command (clause 10.1)
2. INPUT PLUG SIGNAL FORMAT command (clause 10.10)
3. OUTPUT PLUG SIGNAL FORMAT command (clause 10.11)

By the command 1, the drivers can get the number of plugs for AV/C unit or
subunit.
By the command 2 and 3, the drivers can get/set sampling frequency.

The 'firewire-speakers' already uses INPUT PLUG SIGNAL FORMAT command to set
sampling rate. So this commit also affects the driver.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Some devices based on BeBoB use this type of AV/C transaction.

'Deferred Transaction' is defined in 'AV/C Digital Interface Command Set
General Specification' and is used by targets to make a response deferred
during processing it.

If a target may not be able to complete a command within 100msec since
receiving the command, then the target shall return INTERIM response,
to which final response will follow later. CONTROL/NOTIFY commands are
allowed for deferred transaction.

In the specification, devices allow to send INTERIM response just one time.
But this commit allows to handle several INTERIM response with two reasons.
One reason is to simplify codes, and another reason is to prepare for
devices which is out of specification.

There is an issue. In the specification, the interval between INTERIM
response and final response is 'Unspecified interval'. The specification
depends on each subunit specification for this interval.

But we promise to finish this function for caller. In this reason, I use
FCP_TIMEOUT_MS for this interval. Currently it's 125msec. When we find
devices which needs more time for this interval, then let us add some codes
to apply more interval for 'Unspecified interval'.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Plug Control Registers have two fields related to the number of established
connections, one is 'Broadcast connection counter' and another is
'Point-to-point connection counter'. The driver can know there are established
connections or not to check these fields.

This commit is for considering about JACK/FFADO streaming. Currently, when
JACK/FFADO starts its streaming to the device, cmp_connection_establish() is
failed expectedly. This seems to be enough but there are some devices which
needs to change sampling frequency before trying to establish connections.
For such devices, this functionality is needed.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds some macros, codes with condition of direction and new functions
to handle output connection. Once cmp_connection_init() is executed with its
direction, CMP input and output connection can be handled by the same way.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds 'direction' member to 'cmp_connection' structure to indicate
the direction of connection. This patch also adds 'direction' argument to
cmp_connection_init() function to determine the direction.

The cmp_connection_init() function is exported and used in snd-firewire-speakers
so this patch also affect it.

This patch just add them. Actual implementation will be done by followed
patches.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Referring to IEC 61883-1, oMPR and iMPR, oPCR and iPCR have some fields with
the same role in the same position. This patch renames some macros, variables
and function arguments with "i" in its prefix to reuse them between oMPR and
iMPR, oPCR and iPCR.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Currently, drivers can bring XRUN state for PCM substreams when error to
queue packets or detecting discontinuity of packet. The application may try to
recover this state by calling snd_pcm_prepare().

Depending on each driver, .prepare() includes restart streaming. Then there
is a state that PCM substreams are running but isochronous contexts are
stopped. In this case, when .pointer() is called, it refers to error pointer.

This commit is for a prevention of this bug.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This commit adds common PCM constraints according to current firewire-lib
implementation.

1.Maximum width for each sample is limited by 24.
AM824 in IEC 61883-6 can deliver 24bit data.

2. Minimum time for period is 5msec.
Apply the old value. For shorter latency, further works are needed.

3. In blocking mode, frames per period/buffer is aligned to 32.
Each packet can include some frames depending on its sampling rate. In
blocking mode, the number equals to SYT_INTERVAL. Currently firewire-lib
can schedule snd_pcm_period_elapsed() for each packet. So, for accurate
PCM interrupt, the number of frames per period/buffer should be aligned
to SYT_INTERVAL.
Currently firewire-lib is lack of better rules to achieve this. So LCM of
each value of SYT_INTERVALs (=32) is applied. This can be improved for
further work.

[Fixed the compile error due to the missing "&" by tiwai]

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

In previous commit, AMDTP functionality in firewire-lib supports mapping
for PCM data channels. With this mapping, firewire-lib can obsolete
a flag, CIP_HI_DUALWIRE, but Dice driver still keeps dual wire mode.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Some devices arrange the position of PCM/MIDI data channel in AMDTP packet.
This commit allows drivers to set channel mapping.

To be simple, the mapping table is an array with fixed length. Then the number
of channels for PCM is restricted by 64 channels.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Generally, the devices can synchronize to handle 'presentation timestamp'
in CIP packets. This commit adds functionality to pick up this timestamp from
in-packets transmitted by the device, then use it for out packets.

In current implementation, this module generated the timestamp by itself. This
is 'SYT Match' mode. Then drivers with this module acts as synchronization
master. This commit allows this module to act as synchronization slave.

This commit restricts this mechanism is only available in blocking mode because
handling the timestamp in non-blocking mode is more complicated than in
blocking mode.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

For duplex streams with synchronization, drivers should pick up
'presentation timestamp' from in-packets and use the timestamp for
out-packets. This commit is preparation for this.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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>

For capturing PCM, this commit adds the functionality to handle in-stream.
This is also applied for dual-wire mode.

Currently, capturing 32bit samples are supported.

When the sequence of in-packet has discontinuity of dbc, in-stream isn't handled
and amdtp_streaming_error() returns true.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Some codes can be reused to handle in-stream. This commit adds new functions.
This commit also renames some functions to keep naming consistency.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds 'direction' member to amdtp_stream structure to indicate its
direction. This patch also adds 'direction' argument to amdtp_stream_init()
function to determine its direction.

The amdtp_stream_init() function is exported and used by firewire-speakers and
dice so this patch also affects them.

This patch just add them. Actual implementation will be done by followed
patches.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds some macros instead of fixed value for AMDTP according to
IEC 61883-1/6. These macros will also be used by followed patches.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch renames some functions, a structure and its member to reuse them
in both AMDTP in/out stream.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Pull two powerpc fixes from Ben Herrenschmidt:
 "Here are a couple of fixes for 3.15.  One from Anton fixes a nasty
  regression I introduced when trying to fix a loss of irq_work whose
  consequences is that we can completely lose timer interrupts on a
  CPU... not pretty.

  The other one is a change to our PCIe reset hook to use a firmware
  call instead of direct config space accesses to trigger a fundamental
  reset on the root port.  This is necessary so that the FW gets a
  chance to disable the link down error monitoring, which would
  otherwise trip and cause subsequent fatal EEH error"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: irq work racing with timer interrupt can result in timer interrupt hang
  powerpc/powernv: Reset root port in firmware

Pull two btrfs fixes from Chris Mason:
 "This has two fixes that we've been testing for 3.16, but since both
  are safe and fix real bugs, it makes sense to send for 3.15 instead"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: send, fix incorrect ref access when using extrefs
  Btrfs: fix EIO on reading file after ioctl clone works on it

Pull two ceph fixes from Sage Weil:
 "The first patch fixes a problem when we have a page count of 0 for
  sendpage which is triggered by zfs.  The second fixes a bug in CRUSH
  that was resolved in the userland code a while back but fell through
  the cracks on the kernel side"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
  crush: decode and initialize chooseleaf_vary_r
  libceph: fix corruption when using page_count 0 page in rbd

Pull xfs fixes from Dave Chinner:
 "Code inspection of the XFS error number sign translations found a
  bunch of issues, including returning incorrectly signed errors for
  some data integrity operations.

  These leak to userspace and result in applications not getting the
  errors correctly reported.  Hence they need fixing sooner rather than
  later.

  A couple of the bugs are in data integrity operations, a couple more
  are in the new COLLAPSE_RANGE code.  One of these came in through a
  recent ext4 merge and so I had to update the base tree to 3.15-rc5
  before fixing the issues"

* tag 'xfs-for-linus-3.15-rc6' of git://oss.sgi.com/xfs/xfs:
  xfs: list_lru_init returns a negative error
  xfs: negate xfs_icsb_init_counters error value
  xfs: negate mount workqueue init error value
  xfs: fix wrong err sign on xfs_set_acl()
  xfs: fix wrong errno from xfs_initxattrs
  xfs: correct error sign on COLLAPSE_RANGE errors
  xfs: xfs_commit_metadata returns wrong errno
  xfs: fix incorrect error sign in xfs_file_aio_read
  xfs: xfs_dir_fsync() returns positive errno

Pull renameat2 arch support from Miklos Szeredi:
 "I've collected architecture patches for the renameat2 syscall that
  maintainers acked and/or asked me to queue.

  This adds architecture support for the renameat2 syscall to m68k,
  parisc, ia64 and through asm-generic to arc, arm64, c6x, hexagon,
  metag, openrisc, score, tile, unicore32"

* 'renameat2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
  scripts/checksyscalls.sh: Make renameat optional
  asm-generic: Add renameat2 syscall
  ia64: add renameat2 syscall
  parisc: add renameat2 syscall
  m68k: add renameat2 syscall

Pull iommu fixes from Joerg Roedel:
 "Three fixes for the AMD IOMMU driver:
   - fix a locking issue around get_user_pages()
   - fix two issues with device aliasing and exclusion range handling"

* tag 'iommu-fixes-v3.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/amd: fix enabling exclusion range for an exact device
  iommu/amd: Take mmap_sem when calling get_user_pages
  iommu/amd: Fix interrupt remapping for aliased devices