History log of /linux-master/sound/firewire/digi00x/digi00x-transaction.c
Revision Date Author Comments
# da607e19 29-May-2019 Thomas Gleixner <tglx@linutronix.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>


# fdb2b2ee 02-Apr-2017 Takashi Sakamoto <o-takashi@sakamocchi.jp>

ALSA: firewire-digi00x: remove transaction handler for unknown purpose

For digi00x series, asynchronous transaction is not used to transfer MIDI
messages to/from control surface. One of transction handlers in my previous
work loses its practical meaning.

This commit removes the handler. I note that unit of console type
transfers 0x00001000 to registered address of host space when switching
to 'standalone' mode. Then the unit generates bus reset.

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


# 86c8dd7f 30-Mar-2016 Takashi Sakamoto <o-takashi@sakamocchi.jp>

ALSA: firewire-digi00x: delayed registration of sound card

When some digi00x units are connected sequentially, userspace
applications are involved at bus-reset state on IEEE 1394 bus. In the
state, any communications can be canceled. Therefore, sound card
registration should be delayed till the bus gets calm.

This commit achieves it.

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


# b47f525f 10-Oct-2015 Takashi Sakamoto <o-takashi@sakamocchi.jp>

ALSA: firewire-digi00x: add support of asynchronous transaction for outgoing MIDI messages to physical controls

In previous commit, asynchronous transaction for incoming MIDI messages
from physical controls is supported. The physical controls may be
controlled by receiving MIDI messages at a certain address.

This commit supports asynchronous transaction for this purpose.

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


# 3646a54a 10-Oct-2015 Takashi Sakamoto <o-takashi@sakamocchi.jp>

ALSA: firewire-digi00x: add support of asynchronous transaction for incoming MIDI messages from physical controls

Digi 00x series has two types of model; rack and console. The console
models have physical controls. The model can transmit control messages.
These control messages are transferred by asynchronous transactions to
registered address.

This commit supports the asynchronous transaction.

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


# 44b73088 29-Sep-2015 Takashi Sakamoto <o-takashi@sakamocchi.jp>

ALSA: firewire-digi00x: add support for asynchronous messaging

Digi 002/003 family uses asynchronous transaction for messaging.
The address to transmit this message is stored on a certain register.

This commit allocates a range of address on OHCI 1394 host controller
to handle the messaging. As long as I know, the purpose of this message
seems to notify lost of synchronization. While, the meaning of content
of the message is not clear.

Actual examples of this messaging:
* When clock source is set as internal:
- 0x00007051
- 0x00007052
- 0x00007054
- 0x00007057
- 0x00007058
* When clock source is set as somewhat external:
- 0x00009000
- 0x00009010
- 0x00009020
- 0x00009021
- 0x00009022

The lost often occurs when using internal clock source. In this case,
users hear sounds with quite short gap every several minutes. In fact,
the lost is recovered temporarily.

When using with external clock source, the lost seems not to occur. The
mechanism is not clear yet.

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