2019-05-30 07:57:59 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
/*
|
|
|
|
* ff-transaction.c - a part of driver for RME Fireface series
|
|
|
|
*
|
|
|
|
* Copyright (c) 2015-2017 Takashi Sakamoto
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "ff.h"
|
|
|
|
|
|
|
|
static void finish_transmit_midi_msg(struct snd_ff *ff, unsigned int port,
|
|
|
|
int rcode)
|
|
|
|
{
|
|
|
|
struct snd_rawmidi_substream *substream =
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 05:07:29 +08:00
|
|
|
READ_ONCE(ff->rx_midi_substreams[port]);
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
|
|
|
|
if (rcode_is_permanent_error(rcode)) {
|
|
|
|
ff->rx_midi_error[port] = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rcode != RCODE_COMPLETE) {
|
|
|
|
/* Transfer the message again, immediately. */
|
2017-04-14 22:06:54 +08:00
|
|
|
ff->next_ktime[port] = 0;
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
schedule_work(&ff->rx_midi_work[port]);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
snd_rawmidi_transmit_ack(substream, ff->rx_bytes[port]);
|
|
|
|
ff->rx_bytes[port] = 0;
|
|
|
|
|
|
|
|
if (!snd_rawmidi_transmit_empty(substream))
|
|
|
|
schedule_work(&ff->rx_midi_work[port]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void finish_transmit_midi0_msg(struct fw_card *card, int rcode,
|
|
|
|
void *data, size_t length,
|
|
|
|
void *callback_data)
|
|
|
|
{
|
|
|
|
struct snd_ff *ff =
|
|
|
|
container_of(callback_data, struct snd_ff, transactions[0]);
|
|
|
|
finish_transmit_midi_msg(ff, 0, rcode);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void finish_transmit_midi1_msg(struct fw_card *card, int rcode,
|
|
|
|
void *data, size_t length,
|
|
|
|
void *callback_data)
|
|
|
|
{
|
|
|
|
struct snd_ff *ff =
|
|
|
|
container_of(callback_data, struct snd_ff, transactions[1]);
|
|
|
|
finish_transmit_midi_msg(ff, 1, rcode);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void transmit_midi_msg(struct snd_ff *ff, unsigned int port)
|
|
|
|
{
|
|
|
|
struct snd_rawmidi_substream *substream =
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 05:07:29 +08:00
|
|
|
READ_ONCE(ff->rx_midi_substreams[port]);
|
2019-01-22 21:17:04 +08:00
|
|
|
int quad_count;
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
|
|
|
|
struct fw_device *fw_dev = fw_parent_device(ff->unit);
|
|
|
|
unsigned long long addr;
|
|
|
|
int generation;
|
|
|
|
fw_transaction_callback_t callback;
|
2019-01-22 21:17:04 +08:00
|
|
|
int tcode;
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
|
|
|
|
if (substream == NULL || snd_rawmidi_transmit_empty(substream))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (ff->rx_bytes[port] > 0 || ff->rx_midi_error[port])
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Do it in next chance. */
|
|
|
|
if (ktime_after(ff->next_ktime[port], ktime_get())) {
|
|
|
|
schedule_work(&ff->rx_midi_work[port]);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-01-22 21:17:04 +08:00
|
|
|
quad_count = ff->spec->protocol->fill_midi_msg(ff, substream, port);
|
|
|
|
if (quad_count <= 0)
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (port == 0) {
|
2019-01-22 21:17:03 +08:00
|
|
|
addr = ff->spec->midi_rx_addrs[0];
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
callback = finish_transmit_midi0_msg;
|
|
|
|
} else {
|
2019-01-22 21:17:03 +08:00
|
|
|
addr = ff->spec->midi_rx_addrs[1];
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
callback = finish_transmit_midi1_msg;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set interval to next transaction. */
|
|
|
|
ff->next_ktime[port] = ktime_add_ns(ktime_get(),
|
2021-01-11 21:02:50 +08:00
|
|
|
ff->rx_bytes[port] * 8 * (NSEC_PER_SEC / 31250));
|
2019-01-22 21:17:04 +08:00
|
|
|
|
|
|
|
if (quad_count == 1)
|
|
|
|
tcode = TCODE_WRITE_QUADLET_REQUEST;
|
|
|
|
else
|
|
|
|
tcode = TCODE_WRITE_BLOCK_REQUEST;
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In Linux FireWire core, when generation is updated with memory
|
|
|
|
* barrier, node id has already been updated. In this module, After
|
|
|
|
* this smp_rmb(), load/store instructions to memory are completed.
|
|
|
|
* Thus, both of generation and node id are available with recent
|
|
|
|
* values. This is a light-serialization solution to handle bus reset
|
|
|
|
* events on IEEE 1394 bus.
|
|
|
|
*/
|
|
|
|
generation = fw_dev->generation;
|
|
|
|
smp_rmb();
|
2019-01-22 21:17:04 +08:00
|
|
|
fw_send_request(fw_dev->card, &ff->transactions[port], tcode,
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
fw_dev->node_id, generation, fw_dev->max_speed,
|
2019-01-22 21:17:04 +08:00
|
|
|
addr, &ff->msg_buf[port], quad_count * 4,
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
callback, &ff->transactions[port]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void transmit_midi0_msg(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct snd_ff *ff = container_of(work, struct snd_ff, rx_midi_work[0]);
|
|
|
|
|
|
|
|
transmit_midi_msg(ff, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void transmit_midi1_msg(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct snd_ff *ff = container_of(work, struct snd_ff, rx_midi_work[1]);
|
|
|
|
|
|
|
|
transmit_midi_msg(ff, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void handle_midi_msg(struct fw_card *card, struct fw_request *request,
|
|
|
|
int tcode, int destination, int source,
|
|
|
|
int generation, unsigned long long offset,
|
|
|
|
void *data, size_t length, void *callback_data)
|
|
|
|
{
|
|
|
|
struct snd_ff *ff = callback_data;
|
|
|
|
__le32 *buf = data;
|
|
|
|
|
|
|
|
fw_send_response(card, request, RCODE_COMPLETE);
|
|
|
|
|
2019-01-22 21:17:00 +08:00
|
|
|
offset -= ff->async_handler.offset;
|
|
|
|
ff->spec->protocol->handle_midi_msg(ff, (unsigned int)offset, buf,
|
|
|
|
length);
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int allocate_own_address(struct snd_ff *ff, int i)
|
|
|
|
{
|
|
|
|
struct fw_address_region midi_msg_region;
|
|
|
|
int err;
|
|
|
|
|
2019-01-22 21:17:01 +08:00
|
|
|
ff->async_handler.length = ff->spec->midi_addr_range;
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
ff->async_handler.address_callback = handle_midi_msg;
|
|
|
|
ff->async_handler.callback_data = ff;
|
|
|
|
|
|
|
|
midi_msg_region.start = 0x000100000000ull * i;
|
|
|
|
midi_msg_region.end = midi_msg_region.start + ff->async_handler.length;
|
|
|
|
|
|
|
|
err = fw_core_add_address_handler(&ff->async_handler, &midi_msg_region);
|
|
|
|
if (err >= 0) {
|
|
|
|
/* Controllers are allowed to register this region. */
|
|
|
|
if (ff->async_handler.offset & 0x0000ffffffff) {
|
|
|
|
fw_core_remove_address_handler(&ff->async_handler);
|
|
|
|
err = -EAGAIN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-01-24 17:32:03 +08:00
|
|
|
// Controllers are allowed to register higher 4 bytes of destination address to
|
|
|
|
// receive asynchronous transactions for MIDI messages, while the way to
|
|
|
|
// register lower 4 bytes of address is different depending on protocols. For
|
|
|
|
// details, please refer to comments in protocol implementations.
|
|
|
|
//
|
|
|
|
// This driver expects userspace applications to configure registers for the
|
|
|
|
// lower address because in most cases such registers has the other settings.
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
int snd_ff_transaction_reregister(struct snd_ff *ff)
|
|
|
|
{
|
|
|
|
struct fw_card *fw_card = fw_parent_device(ff->unit)->card;
|
|
|
|
u32 addr;
|
|
|
|
__le32 reg;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Controllers are allowed to register its node ID and upper 2 byte of
|
|
|
|
* local address to listen asynchronous transactions.
|
|
|
|
*/
|
|
|
|
addr = (fw_card->node_id << 16) | (ff->async_handler.offset >> 32);
|
|
|
|
reg = cpu_to_le32(addr);
|
|
|
|
return snd_fw_transaction(ff->unit, TCODE_WRITE_QUADLET_REQUEST,
|
2018-12-16 16:32:33 +08:00
|
|
|
ff->spec->midi_high_addr,
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
®, sizeof(reg), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
int snd_ff_transaction_register(struct snd_ff *ff)
|
|
|
|
{
|
|
|
|
int i, err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate in Memory Space of IEC 13213, but lower 4 byte in LSB should
|
|
|
|
* be zero due to device specification.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < 0xffff; i++) {
|
|
|
|
err = allocate_own_address(ff, i);
|
|
|
|
if (err != -EBUSY && err != -EAGAIN)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
err = snd_ff_transaction_reregister(ff);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
INIT_WORK(&ff->rx_midi_work[0], transmit_midi0_msg);
|
|
|
|
INIT_WORK(&ff->rx_midi_work[1], transmit_midi1_msg);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void snd_ff_transaction_unregister(struct snd_ff *ff)
|
|
|
|
{
|
|
|
|
__le32 reg;
|
|
|
|
|
|
|
|
if (ff->async_handler.callback_data == NULL)
|
|
|
|
return;
|
|
|
|
ff->async_handler.callback_data = NULL;
|
|
|
|
|
|
|
|
/* Release higher 4 bytes of address. */
|
|
|
|
reg = cpu_to_le32(0x00000000);
|
|
|
|
snd_fw_transaction(ff->unit, TCODE_WRITE_QUADLET_REQUEST,
|
2018-12-16 16:32:33 +08:00
|
|
|
ff->spec->midi_high_addr,
|
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>
2017-03-31 21:06:03 +08:00
|
|
|
®, sizeof(reg), 0);
|
|
|
|
|
|
|
|
fw_core_remove_address_handler(&ff->async_handler);
|
|
|
|
}
|