In protocols of MOTU FireWire series, when transferring MIDI messages,
transmitter set existence flag to one byte on first several quadlets. The
position differs depending on protocols and models, however two cases are
confirmed; in 5th byte and 8th byte from MSB side.

This commit adds a series of specification flag to describe them. When
the existence flag is in the 5th byte, SND_MOTU_SPEC_[R|T]X_MIDI_2ND_Q is
used. Else, another set of the flag is used. Here, '_Q' means quadlet.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3

MOTU 828mk3 (FireWire/Hybrid) is one of third generation in MOTU FireWire
series, produced in 2008/2014. This model consists of three chips for
functionality on IEEE 1394 bus:

 * TI TSB41AB2 (Physical layer for IEEE 1394 bus)
 * Xilinx Spartan-3E FPGA Family (Link layer for IEEE 1394 bus, packet
   processing and data block processing layer)
 * TI TMS320C6722 (Digital signal processing)

This commit adds a support for this model, with its unique protocol as
version 3. This protocol has some additional features to protocol
version 2.

 * Support several optical interfaces.
 * Support a data chunk for return of reverb effect.
 * Have a quirk of tx packets.
 * Support heartbeat asynchronous transaction.

In this protocol, series of transferred packets has some quirks. Below
fields in CIP headers of the packets are out of IEC 61883-1:
 - SID (source node id): always 0x0d
 - DBS (data block size): always 0x04
 - DBC (data block counter): always 0x00
 - EOH (End of header): always 0x00

Below is an actual sample of transferred packets.

quads CIP1       CIP2
520   0x0D040400 0x22FFFFFF
  8   0x0D040400 0x22FFFFFF
520   0x0D040400 0x22FFFFFF
520   0x0D040400 0x22FFFFFF
  8   0x0D040400 0x22FFFFFF

Status of clock is configured by write transactions to 0x'ffff'f000'0b14,
as well as version 2, while meanings of fields are different from the
former protocols. Modes of optical interfaces are configured by write
transactions to 0x'ffff'f000'0c94.

Drivers can register its address to receive heatbeat transactions from the
unit. 0x'ffff'f000'0b0c is for the higher part and 0x'ffff'f000'0b10 is
for the lower part. Nevertheless, this feature is not useless for this
driver and this commit omits it.

Each data block consists of two parts in a point of the number of included
data chunks. In both of 'fixed' and 'differed' parts, the number of
included data blocks are a multiple of 4, thus depending on models there's
some empty data chunks. For example, 828mk3 includes one pair of empty
data chunks in its fixed part. When optical interface is configured to
S/PDIF, 828mk3 includes one pair of empty data chunks in its differed part.
To reduce consumption of CPU cycles with additional conditions/loops, this
commit just exposes these empty chunks to user space as PCM channels.

Additionally, 828mk3 has a non-negligible overhead to change its sampling
transfer frequency. When softwares send asynchronous transaction to
perform it, LED on the unit starts to blink. In a worst case, it continues
blink during several seconds; e.g. 10 seconds. When stopping blinking,
the unit seems to be prepared for the requested sampling transfer
frequency. To wait for the preparation, this commit forces the driver
to call task scheduler and applications sleeps for 4 seconds.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

MOTU 828mk2 is one of second generation in MOTU FireWire series, produced in
2003. This model consists of four chips:
 * TI TSB41AB2 (Physical layer for IEEE 1394 bus)
 * PDI 1394L40BE (Link layer for IEEE 1394 bus and packet processing layer)
 * ALTERA ACEX 1K EP1K30 Series FPGA (Data block processing layer)
 * TI TMS320VC5402 (Digital signal processing)

This commit adds a support for this model, with its unique protocol as
version 2. The features of this protocol are:

 * Support data chunks for status and control messages for both
   directions.
 * Support a pair of MIDI input/output.
 * Support a data chunk for mic/instrument independent of analog line in.
 * Support a data chunk for playback return.
 * Support independent data chunks for S/PDIF of both optical/coaxial
   interfaces.
 * Support independent data chunks for each of main out and phone out.

Status of clock is configured by write transactions to 0x'ffff'f000'0b14.
Modes of optical interfaces are configured by write transactions to
0x'ffff'f000'0c04.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds hwdep interface so as the other sound drivers for units
on IEEE 1394 bus have.

This interface is designed for mixer/control applications. By using this
interface, an application can get information about firewire node, can
lock/unlock kernel streaming and can get notification at starting/stopping
kernel streaming.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In MOTU FireWire series, MIDI messages are multiplexed to isochronous
packets as well as PCM frames, while the way is different from the one
in IEC 61883-6.

MIDI messages are put into a certain position in message chunks. One data
block can includes one byte of the MIDI messages. When data block includes
a MIDI byte, the block has a flag in a certain position of the message
chunk. These positions are unique depending on protocols.

Once a data block includes a MIDI byte, some following data blocks includes
no MIDI bytes. Next MIDI byte appears on a data block corresponding to
next cycle of physical MIDI bus. This seems to avoid buffer overflow caused
by bandwidth differences between IEEE 1394 bus and physical MIDI bus.

This commit adds MIDI functionality to transfer/receive MIDI messages.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds PCM functionality to transmit/receive PCM samples.

When one of PCM substreams are running or external clock source is
selected, current sampling rate is used. Else, the sampling rate is
changed according to requests from a userspace application.

Available number of samples in a frame of PCM substream is determined at
open(2) to corresponding PCM character device. Later, packet streaming
starts by ioctl(2) with SNDRV_PCM_IOCTL_PREPARE. In theory, between them,
applications can change state of the unit by any write transaction to
change the number. In this case, this driver may fail packet streaming due
to wrong data format.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a proc node for debugging purpose.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a functionality to manage packet streaming for MOTU
FireWire series.

The streaming is not controlled by CMP, thus against IEC 61883-1. Write
transaction to certain addresses start/stop packet streaming.

Transactions to 0x'ffff'f000'0b00 results in isochronous channel number for
both directions and starting/stopping transmission of packets. The
isochronous channel number is represented in 6 bit field, thus units can
identify the channels up to 64, as IEEE 1394 bus specification described.

Transactions to 0x'ffff'f000'0b10 results in packet format for both
directions and transmission speed. When each of data block includes fixed
part of data chunks only, corresponding flags stand.

When bus reset occurs, the units continue to transmit packets with
non-contiguous data block counter. This causes discontinuity detection in
packet streaming engine and ALSA PCM applications receives EPIPE from any
I/O operation. In this case, typical applications manage to recover
corresponding PCM substream. This behaviour is kicked much earlier than
callback of bus reset handler by Linux FireWire subsystem, therefore
status of packet streaming is not changed in the handler.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

All models of MOTU FireWire series can be controlled by write transaction
to addresses in a range from 0x'ffff'f0000'0b00 to 0x'ffff'f000'0cff.

The models support asynchronous notification. This notification has 32 bit
field data, and is transferred when status of clock changes. Meaning of
the value is not enough clear yet.

Drivers can register its address to receive the notification. Write
transaction to 0x'ffff'f000'0b04 registers higher 16 bits of the address.
Write transaction to 0x'ffff'f0000'0b08 registers the rest of bits. The
address includes node ID, thus it should be registered every time of bus
reset.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.

This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.

When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.

When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.

In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.

In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

MOTU FireWire series doesn't tell drivers their capabilities, thus
the drivers should have and apply model-dependent parameters to detected
models.

This commit adds a structure to represent such parameters. Capabilities
are represented by enumeration except for the number of analog line
in/out. Identification name also be in the structure because the units has
no registers for this purpose.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just after appearing on IEEE 1394 bus, this unit generates several bus
resets. This is due to loading firmware from on-board flash memory and
initialize hardware. It's better to postpone sound card registration.

This commit applies this idea.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds an new driver for MOTU FireWire series. In this commit,
this driver just creates/removes card instance according to bus event.
More functionalities will be added in following commits.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>