-
Takashi Sakamoto authored
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>
19174295