ALSA: fireface: make read-only const array for model names static

It is preferable not to populate the constant array for constant strings
on the stack.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230627235406.289970-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire: use 'GPL' string for module license contributed by Takashi Sakamoto

In MODULE_LICENSE macro, "GPL" string obsoletes "GPL v2" string by a
commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2"
bogosity").

This commit uses the preferable expression.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230611144445.221529-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: add local framework to message parser

This commit adds local framework to message parser. This is preparation
for future work to pass event of knob control for Fireface 400 to user
space.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230112120954.500692-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: cease from delayed card registration

The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: add support for RME Fireface UFX (untested)

Fireface UFX was shipped by RME GmbH in 2010, and now discontinued.
Although this model has some enhanced feature which Fireface 802
doesn't have (e.g. on-board USB mass storage device class, configuration
interface with color display), the functionality relevant to
packet communication on IEEE 1394 bus seems to be the same as
Fireface 802 (e.g. available number of channels for PCM frame in
each sampling transfer frequency).

With the assumption, this commit adds support for Fireface UFX. In ALSA
fireface driver, these two models are handled as the same one.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: add support for RME FireFace 802

Fireface 802 was shipped by RME GmbH in 2014. This model supports later
protocol for management of isochronous communication and synchronization
of sampling transmission frequency.

This model consists of below ICs:
* TI TSB41AB2
* Xilinx Spartan-6 FPGA XC6SLX16
* TI TMS320 C6747
* SMSC USB3250

Especially, this model just supports IEEE 1394a, against its name which
evokes Fireface 800.

This commit adds support for Fireface 802 (tested). Userspace applications
can transfer PCM frames and MIDI messages via ALSA PCM/Rawmidi interface.
I note that 4 channels for ADAt1 and ADAT2 are disabled at higher sampling
transfer frequency since isochronous resources reservation fails due to
bandwidth limitation of IEEE 1394a.

The value read from LATTER_SYNC_STATUS register is slightly different
from the one of Fireface UCX. The higher 4 bits and lower 4 bits are
swapped within the same byte.

Without any assist of userspace application, transmitted MIDI messages
from the device are not going to be processed. For detail, please refer
to my comment in code of latter protocol.

$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0404ffff bus_info_length 4, crc_length 4, crc 65535 (should be 26805)
404 31333934 bus_name "1394"
408 20008000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 8 (512)
40c 000a3504 company_id 000a35 |
410 38077423 device_id 0438077423 | EUI-64 000a350438077423

root directory
-----------------------------------------------------------------
414 0005ffff directory_length 5, crc 65535 (should be 9514)
418 0c0083c0 node capabilities per IEEE 1394
41c 03000a35 vendor
420 8100000b --> descriptor leaf at 44c
424 8d000007 --> eui-64 leaf at 440
428 d1000001 --> unit directory at 42c

unit directory at 42c
-----------------------------------------------------------------
42c 0004ffff directory_length 4, crc 65535 (should be 45134)
430 12000a35 specifier id
434 13000005 version
438 17101800 model
43c 81000008 --> descriptor leaf at 45c

eui-64 leaf at 440
-----------------------------------------------------------------
440 0002ffff leaf_length 2, crc 65535 (should be 60131)
444 000a3504 company_id 000a35 |
448 38077423 device_id 0438077423 | EUI-64 000a350438077423

descriptor leaf at 44c
-----------------------------------------------------------------
44c 0003ffff leaf_length 3, crc 65535 (should be 469)
450 00000000 textual descriptor
454 00000000 minimal ASCII
458 524d4521 "RME!"

descriptor leaf at 45c
-----------------------------------------------------------------
45c 0005ffff leaf_length 5, crc 65535 (should be 10561)
460 00000000 textual descriptor
464 00000000 minimal ASCII
468 46697265 "Fire"
46c 66616365 "face"
470 20383032 " 802"

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: code refactoring to decide name of sound card

This commit uses enumeration constants as index of table for the
list of name of sound card.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: code refactoring to add enumeration constants for model identification

In RME fireface series, version field of unit directory in configuration
ROM is used to distinguish each model. The value of field is known and
it's better to use enumeration constants for code representation.

This commit adds enumeration constants for model identification.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire: use KBUILD_MODNAME for struct driver.name instead of string

KBUILD_MODNAME is available to name kernel modules according to its object
name. This commit uses the macro instead of string for name field of
struct driver since drivers in ALSA firewire stack have the same name of
each object name.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200306135229.11659-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 345

Based on 1 normalized pattern(s):

licensed under the terms of the gnu general public license version 2

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 88 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000437.521539229@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: fireface: support rx MIDI functionality for Fireface UCX

In latter model of Fireface series, asynchronous transaction includes
a prefix byte to indicate the way to decode included MIDI bytes.

Upper 4 bits of the prefix byte indicates port number, and the rest 4
bits indicate the way to decode rest of bytes for MIDI messages.

Basically the rest bits indicates the number of bytes for MIDI message.
However, if the last byte of each MIDi message is included, the rest
bits are 0xf. For example:

message: f0 00 00 66 14 20 00 00 f7
offset: content (big endian, port 0)
'0030: 0x02f00000
'0030: 0x03006614
'0030: 0x03200000
'0030: 0x0ff70000

This commit supports encoding scheme for the above and allows
applications to transfer MIDI messages via ALSA rawmidi interface.
An unused member (running_status) is reused to keep state of
transmission of system exclusive messages.

For your information, this is a dump of config rom.

$ sudo ./hinawa-config-rom-printer /dev/fw1
{ 'bus-info': { 'bmc': False,
'chip_ID': 13225063715,
'cmc': False,
'cyc_clk_acc': 0,
'imc': False,
'isc': True,
'max_rec': 512,
'name': '1394',
'node_vendor_ID': 2613},
'root-directory': [ [ 'NODE_CAPABILITIES',
{ 'addressing': {'64': True, 'fix': True, 'prv': False},
'misc': {'int': False, 'ms': False, 'spt': True},
'state': { 'atn': False,
'ded': False,
'drq': True,
'elo': False,
'init': False,
'lst': True,
'off': False},
'testing': {'bas': False, 'ext': False}}],
['VENDOR', 2613],
['DESCRIPTOR', 'RME!'],
['EUI_64', 2873037108442403],
[ 'UNIT',
[ ['SPECIFIER_ID', 2613],
['VERSION', 4],
['MODEL', 1054720],
['DESCRIPTOR', 'Fireface UCX']]]]}

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

ALSA: fireface: add model-dependent parameter for address to receive async transaction for MIDI messages

Between former and latter models, destination address to receive
asynchronous transactions for MIDI messages is different.

This commit adds model-dependent parameter for the addresses.

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

ALSA: fireface: support tx MIDI functionality of Fireface UCX

Fireface UCX transfers asynchronous transactions for MIDI messages.
One transaction includes quadlet data therefore it can transfer 3
message bytes as maximum. Base address of the destination is
configured by two settings; a register for higher 8 byte of the
address, and a bitflag to option register indicates lower 8byte.

The register for higher address is 0x'ffff'0000'0034. Unfortunately,
firmware v24 includes a bug to ignore registered value for the
destination address and transfers to 0x0001xxxxxxxx always. This
driver doesn't work well if the bug exists, therefore users should
install the latest firmware (v27).

The bitflag is a part of value to be written to option register
(0x'ffff'0000'0014).

lower addr: bitflag (little endian)
'0000'0000: 0x00002000
'0000'0080: 0x00004000
'0000'0100: 0x00008000
'0000'0180: 0x00010000

This register includes more options but they are not relevant to
packet streaming or MIDI functionality. This driver don't touch it.

Furthermore, the transaction is sent to address offset incremented
by 4 byte to the offset in previous time. When it reaches base address
plus 0x7c, next offset is the base address.

Content of the transaction includes a prefix byte. Upper 4 bits of
the byte indicates port number, and the rest 4 bits indicate the way
to decode rest of bytes for MIDI message.

Except for system exclusive messages, the rest bits are the same as
status bits of the message without channel bits. For system exclusive
messages, the rest bits are encoded according to included message bytes.
For example:

message: f0 7e 7f 09 01 f7
offset: content (little endian, port 0)
'0000: 0x04f07e7f
'0004: 0x070901f7

message: f0 00 00 66 14 20 00 00 00 f7
offset: content (little endian, port 1)
'0014: 0x14f00000
'0018: 0x14661420
'001c: 0x14000000
'0020: 0x15f70000

message: f0 00 00 66 14 20 00 00 f7
offset: content (little endian, port 0)
'0078: 0x04f00000
'007c: 0x04661420
'0000: 0x070000f7

This commit supports decoding scheme for the above and allows
applications to receive MIDI messages via ALSA rawmidi interface.
The lower 8 bytes of destination address is fixed to 0x'0000'0000,
thus this driver expects userspace applications to configure option
register with bitflag 0x00002000 in advance.

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

ALSA: fireface: add model-dependent parameter for address range to receive async transaction

In Fireface series, drivers can register destination address for
asynchronous transaction which transfers MIDI messages from device.

In former models, all of the transactions arrive at the registered
address without any offset. In latter models, each of the transaction
arrives at the registered address with sequential offset within 0x00
to 0x7f. This seems to be for discontinuity detection.

This commit adds model-dependent member for the address range.

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

ALSA: fireface: add support for Fireface UCX

Fireface UFX was shipped by RME GmbH in 2012. This model supports later
protocol for management of isochronous communication and synchronization
of sampling transmission frequency.

This commit adds support for the model. At present, it's not clear how
to encode MIDI messages and decide destination address for asynchronous
transaction, thus this commit adds support for isochronous communication
for PCM frames only.

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

ALSA: fireface: code refactoring to handle model-specific registers

As a result of investigation for Fireface 800, 'struct snd_ff_spec.regs'
is just for higher address to receive tx asynchronous packets of MIDI
messages, thus it can be simplified.

This commit simplifies it.

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

ALSA: fireface: add support for packet streaming on Fireface 800

This commit adds a functionality to multiplex PCM frames into isochronous
packets and demultiplex PCM frames from isochronous packets for ALSA PCM
applications.

Fireface 800 voluntarily maintains resources for tx isochronous
communication. It performs reservation of isochronous channel and
allocation/update of bandwidth in some cases below:
- at a first request to allocation after bus resets
- at requests to allocation when further bandwidth is required

When request is grant and the unit is prepared, read data from
0x0000801c0008 represents isochronous channel for tx stream, then
the unit can handle requests to start communication. If driver
send the request without checking the register, the unit takes
panic to continue bus resets. The unit starts transmission of
tx packets after receiving several rx packets from driver.

I note that the unit can process tx/rx packets and generate/record
sound regardless of HOST LED.

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

ALSA: fireface: add support for Fireface 800 with MIDI functionality only

Fireface 800 is a flagship model of RME GmbH for audio and music units
on IEEE 1394 bus, shipped 2004. This model consists of four chips:
- TI TSB81BA3D for physical layer on cable environment of EEE 1394 bus
- TI TSB82AA2 for link layer for 1394 OHCI bus bridge to PCI bus
- Xilinx Spartan-3 FPGA XC3S400
- Xilinx High-Performance CPLD XC9572XL

This commit adds support Fireface 800. In this time, the support is
restricted to its MIDI functionality, thus this commit adds some
condition statements to avoid touching streaming functionality.

Unlike Fireface 400, Fireface 800 has no functionality to suppress
asynchronous transactions for MIDI messages except for unregister of
listen address in controller side, thus the feature is available as is.

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

ALSA: fireface: add driver data for register for MIDI high address

Fireface 400 and 800 have the same mechanism to decide address to which
asynchronous transactions are sent for MIDI messages, however they use
different registers for controllers to notify higher 4 byte of the
address.

This commit adds a model-specific parameter to represent the address.
Additionally, it corrects some comments. I note that these two models have
a difference to enable/disable the transaction.

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

ALSA: firewire: simplify cleanup process when failing to register sound card

In former commits, .private_free callback releases resources just for
data transmission. This release function can be called without the
resources are actually allocated in error paths.

This commit applies a small refactoring to clean up codes in error
paths.

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

ALSA: firewire: release reference count of firewire unit in .remove callback of bus driver

In a previous commit, drivers in ALSA firewire stack blocks .remove
callback of bus driver. This enables to release members of private
data in the callback after releasing device of sound card.

This commit simplifies codes to release the members.

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

ALSA: firewire: block .remove callback of bus driver till all of ALSA character devices are released

At present, in .remove callback of bus driver just decrease reference
count of device for ALSA card instance. This delegates release of the
device to a process in which the last of ALSA character device is
released.

On the other hand, the other drivers such as for devices on PCIe are
programmed to block .remove callback of bus driver till all of ALSA
character devices are released.

For consistency of behaviour for whole drivers, this probably confuses
users. This commit takes drivers in ALSA firewire stack to imitate the
above behaviour.

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

ALSA: firewire: use managed-resource of fw unit device for private data

At present, private data of each driver in ALSA firewire stack is
allocated/freed by kernel slab allocator for corresponding unit on
IEEE 1394 bus. In this case, resource-managed slab allocator is
available to release memory object automatically just before releasing
device structure for the unit. This idea can prevent runtime from
memory leak due to programming mistakes.

This commit uses the allocator for the private data. These drivers
already use reference counter to maintain lifetime of device structure
for the unit by a pair of fw_unit_get()/fw_unit_put(). The private data
is safely released in a callback of 'struct snd_card.private_free().

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

ALSA: firewire: add const qualifier to identifiers for read-only symbols

Drivers in ALSA firewire stack still includes some symbols which can be
moved to a section for read-only symbols.

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

ALSA: fireface: add support for Fireface 400

Fireface 400 is a second model of RME Fireface series, released in 2006.
This commit adds support for this model.

This model supports 8 analog channels, 2 S/PDIF channels and 8 ADAT
channels in both of tx/rx packet. The number of ADAT channels differs
depending on each mode of sampling transmission frequency.

$ python2 linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04107768 bus_info_length 4, crc_length 16, crc 30568 (should be 61311)
404 31333934 bus_name "1394"
408 20009002 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 9 (1024)
40c 000a3501 company_id 000a35 |
410 1bd0862a device_id 011bd0862a | EUI-64 000a35011bd0862a

root directory
-----------------------------------------------------------------
414 000485ec directory_length 4, crc 34284
418 03000a35 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 8d000006 --> eui-64 leaf at 438
424 d1000001 --> unit directory at 428

unit directory at 428
-----------------------------------------------------------------
428 000314c4 directory_length 3, crc 5316
42c 12000a35 specifier id
430 13000002 version
434 17101800 model

eui-64 leaf at 438
-----------------------------------------------------------------
438 000261a8 leaf_length 2, crc 25000
43c 000a3501 company_id 000a35 |
440 1bd0862a device_id 011bd0862a | EUI-64 000a35011bd0862a

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

ALSA: fireface: add hwdep interface

This commit adds hwdep interface so as the other drivers for audio and
music units on IEEE 1394 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: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: fireface: add support for PCM functionality

This commit adds PCM functionality to transmit/receive PCM frames on
isochronous packet streaming. This commit enables userspace applications
to start/stop packet streaming via ALSA PCM interface.

Sampling rate requested by applications is used as sampling transmission
frequency of IEC 61883-1/6packet streaming. As I described in followed
commits, units in this series manages sampling clock frequency
independently of sampling transmission frequency, and they supports
resampling between their packet streaming/data block processing layer and
sampling data processing layer. This commit take this driver to utilize
these features for usability.

When internal clock is selected as source signal of sampling clock, this
driver allows user space applications to start PCM substreams at any rate
which packet streaming engine supports as sampling transmission frequency.
In this case, this driver expects units to perform resampling PCM frames
for rx/tx packets when sampling clock frequency and sampling transmission
frequency are mismatched. This is for daily use cases.

When any external clock is selected as the source signal, this driver
gets configured sampling rate from units, then restricts available
sampling rate to the rate for PCM applications. This is for studio use
cases.

Models in this series supports 64.0/128.0 kHz of sampling rate, however
these frequencies are not supported by IEC 61883-6 as sampling transmission
frequency. Therefore, packet streaming engine of ALSA firewire stack can't
handle them. When units are configured to use any external clock as source
signal of sampling clock and one of these unsupported rate is configured
as rate of the sampling clock, this driver returns EIO to user space
applications.

Anyway, this driver doesn't voluntarily configure parameters of sampling
clock. It's better for users to work with appropriate user space
implementations to configure the parameters in advance of usage.

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

ALSA: fireface: add stream management functionality

This commit adds management functionality for packet streaming.

As long as investigating Fireface 400, there're three modes depending
on sampling transmission frequency. The number of data channels in each
data block is different depending on the mode. The set of available
data channels for each mode might be different for each protocol and
model.

The length of registers for the number of isochronous channel is just
three bits, therefore 0-7ch are available.

When bus reset occurs on IEEE 1394 bus, the device discontinues to
transmit packets. This commit aborts PCM substreams at bus reset handler.

As I described in followed commits, The device manages its sampling clock
independently of sampling transmission frequency against IEC 61883-6.
Thus, it's a lower cost to change the sampling transmission frequency,
while data fetch between streaming layer and DSP require larger buffer
for resampling. As a result, device latency might tend to be larger than
ASICs for IEC 61883-1/6 such as DM1000/DM1100/DM1500 (BeBoB),
DiceII/TCD2210/TCD2220/TCD3070 and OXFW970/971.

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

ALSA: fireface: add proc node to help debugging

Drivers can retrieve the state and configuration of clock by read
transactions.

This commit allows protocol abstraction layer to to dump the
information for debugging, via proc interface.

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

ALSA: fireface: add support for MIDI functionality

In previous commit, fireface driver supports unique transaction mechanism
for MIDI feature. This commit adds MIDI functionality for userspace
applications.

As I wrote in a followed commit, user space applications get some
requirement from this driver. It should not touch a register to which
units transmit MIDI messages. It should configure a register in which
MIDI transmission is controlled.

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

ALSA: fireface: add transaction support

As long as investigating Fireface 400, MIDI messages are transferred by
asynchronous communication over IEEE 1394 bus.

Fireface 400 receives MIDI messages by write transactions to two addresses;
0x'0000'0801'8000 and 0x'0000'0801'9000. Each of two seems to correspond to
MIDI port 1 and 2.

Fireface 400 transfers MIDI messages by write transactions to certain
addresses which configured by drivers. The drivers can decide upper 4 byte
of the addresses by write transactions to 0x'0000'0801'03f4. For the rest
part of the address, drivers can select from below options:
* 0x'0000'0000
* 0x'0000'0080
* 0x'0000'0100
* 0x'0000'0180

Selected options are represented in register 0x'0000'0801'051c as bit
flags. Due to this mechanism, drivers are restricted to use addresses on
'Memory space' of IEEE 1222, even if transactions to the address have
some side effects.

This commit adds transaction support for MIDI messaging, based on my
assumption that the similar mechanism is used on the other protocols. To
receive asynchronous transactions, the driver allocates a range of address
in 'Memory space'. I apply a strategy to use 0x'0000'0000 as lower 4 byte
of the address. When getting failure from Linux FireWire subsystem, this
driver retries to allocate addresses.

Unfortunately, read transaction to address 0x'0000'0801'051c returns zero
always, however write transactions have effects to the other features such
as status of sampling clock. For this reason, this commit delegates a task
to configure this register to user space applications. The applications
should set 3rd bit in LSB in little endian order.

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

ALSA: fireface: add model specific structure

RME Fireface series has several models and their specifications are
different. Currently, we find no way to retrieve the specifications
from actual devices and need to implement them in this driver.

This commit adds a structure to describe model specific data. This
structure has an identical name for each unit, and maximum number of
data channels in each mode. I'll describe about the mode in following
commits.

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

ALSA: fireface: postpone sound card registration

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 schedules workqueue to process actual probe processing
2 seconds after the last bus-reset. The card instance is kept at unit
probe callback and released at card free callback. Therefore, when the
actual probe processing fails, the memory block is wasted. This is due to
simplify driver implementation.

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

ALSA: fireface: add skeleton for RME Fireface series

This commit adds a new driver for RME Fireface series. This commit just
creates/removes card instance according to IEEE 1394 bus event. More
functions will be added in following commits.

Three types of firmware have released by RME GmbH; for Fireface 400, for
Fireface 800 and for UCX/802/UFX. It's reasonable that these models use
different protocol for communication. Currently, I've investigated
Fireface 400 and nothing others.

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