Currently, when two MIDI trigger callbacks can be called immediately,
transactions for the second MIDI messages can be postpone till next trigger
callback. This is not good for real-time message transmission.

This commit schedules work again at response handling callback if the
MIDI substream still includes untransferred MIDI messages.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, when waiting for a response, callers can start another
transaction by scheduling another work. This is not good for error
processing of transaction, especially the first response is too late.

This commit serialize request/response transactions, by adding one
boolean member to represent idling state.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some models receive MIDI messages via IEEE 1394 asynchronous transactions.
In this case, MIDI messages are transferred in fixed-length payload. It's
nice that firewire-lib module has common helper functions.

This commit implements this idea. Each driver adds
'struct snd_fw_async_midi_port' in its instance structure. In probing,
it should call snd_fw_async_midi_port_init() to initialize the
structure with some parameters such as target address, the length
of payload in a transaction and a pointer for callback function
to fill the payload buffer. At 'struct snd_rawmidi_ops.trigger()'
callback, it should call 'snd_fw_async_midi_port_run()' to start
transactions. Each driver should ensure that the lifetime of MIDI
substream continues till calling 'snd_fw_async_midi_port_finish()'.

The helper functions support retries to transferring MIDI messages when
transmission errors occur. When transactions are successful, the helper
functions call 'snd_rawmidi_transmit_ack()' internally to consume MIDI
bytes in the buffer. Therefore, Each driver is expected to use
'snd_rawmidi_transmit_peek()' to tell the number of bytes to transfer to
return value of 'fill' callback.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_seq_oss_readq_put_event() seems to be missing a memory barrier which
might cause the waker to not notice the waiter and miss sending a
wake_up as in the following figure.

    snd_seq_oss_readq_put_event		    snd_seq_oss_readq_wait
------------------------------------------------------------------------
					/* wait_event_interruptible_timeout */
					 /* __wait_event_interruptible_timeout */
					  /* ___wait_event */
					  for (;;) {									 prepare_to_wait_event(&wq, &__wait,
					    state);
spin_lock_irqsave(&q->lock, flags);
if (waitqueue_active(&q->midi_sleep))
/* The CPU might reorder the test for
   the waitqueue up here, before
   prior writes complete */
					  if ((q->qlen>0 || q->head==q->tail)
					  ...
					  __ret = schedule_timeout(__ret)
if (q->qlen >= q->maxlen - 1) {
memcpy(&q->q[q->tail], ev, sizeof(*ev));
q->tail = (q->tail + 1) % q->maxlen;
q->qlen++;
------------------------------------------------------------------------

There are two other place in sound/core/seq/oss/ which have similar
code.  The attached patch removes the call to waitqueue_active() leaving
just wake_up() behind.  This fixes the problem because the call to
spin_lock_irqsave() in wake_up() will be an ACQUIRE operation.

I found this issue when I was looking through the linux source code
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c  (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: NKosuke Tatsukawa <tatsu@ab.jp.nec.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now that we have introduced the core fns we should make hda use these
helpers
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current codec helpers are local to hda code and needs to be moved to
core so that other users can use it.
The helpers to read/write the codec and to check the
power state of widgets is copied
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

if the stream is decoupled and both link and host are used, while
releasing the stream, need to check if link and host stream are
not in use. This patch adds fix to check if the host/link stream
is in used before coupling it back when releasing the stream.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Bits in LOSIDV need to be set to map the stream id for specific link.
Fixing this by setting the required bits in the register.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Current ALSA BeBoB drivers has an entry for this model, while the value of
vendor ID seems to be wrong according to an user's report.

The vendor had released no updated firmware, thus we can judge that this
model had not changed the content of its config ROM. It's reasonable to fix
the ID according to the report.

$ ./linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom

               ROM header and bus information block
               -----------------------------------------------------------------
400  0425720f  bus_info_length 4, crc_length 37, crc 29199
404  31333934  bus_name "1394"
408  f0646122  irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 100,
               max_rec 6 (128), max_rom 1, gen 2, spd 2 (S400)
40c  00000ff2  company_id 00000f     |
410  00004697  device_id f200004697  | EUI-64 00000ff200004697

               root directory
               -----------------------------------------------------------------
414  000859be  directory_length 8, crc 22974
418  04000082  hardware version
41c  0c0083c0  node capabilities per IEEE 1394
420  03000ff2  vendor
424  8100000a  --> descriptor leaf at 44c
428  17010065  model
42c  8100000d  --> descriptor leaf at 460
430  13000910  version
434  d1000001  --> unit directory at 438

               unit directory at 438
               -----------------------------------------------------------------
438  0004ccec  directory_length 4, crc 52460
43c  1200a02d  specifier id: 1394 TA
440  13010001  version: AV/C
444  17010065  model
448  8100000d  --> descriptor leaf at 47c

               descriptor leaf at 44c
               -----------------------------------------------------------------
44c  0004152a  leaf_length 4, crc 5418
450  00000000  textual descriptor
454  00000000  minimal ASCII
458  4d61636b  "Mack"
45c  69650000  "ie"

               descriptor leaf at 460
               -----------------------------------------------------------------
460  000612b5  leaf_length 6, crc 4789
464  00000000  textual descriptor
468  00000000  minimal ASCII
46c  4f6e7978  "Onyx"
470  20466972  " Fir"
474  65776972  "ewir"
478  65000000  "e"

               descriptor leaf at 47c
               -----------------------------------------------------------------
47c  000612b5  leaf_length 6, crc 4789
480  00000000  textual descriptor
484  00000000  minimal ASCII
488  4f6e7978  "Onyx"
48c  20466972  " Fir"
490  65776972  "ewir"
494  65000000  "e"

$ cat /proc/asound/card3/firewire/firmware
Manufacturer:   bridgeCo
Protocol Ver:   1
Build Ver:      0
GUID:           0x00000FF200004697
Model ID:       0x82
Model Rev:      1
Firmware Date:  20040430
Firmware Time:  131527
Firmware ID:    0x10065
Firmware Ver:   2320
Base Addr:      0x20080000
Max Size:       1572864
Loader Date:    20040430
Loader Time:    112036
Reported-by: NAndrzej Gansiniec <andrzej@gansiniec.pl>
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 IEEE 1394 sound devices
has.

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>

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 as an userspace application requests.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds streaming functionality for both direction. To utilize
the sequence of the number of data blocks in packets, full duplex with
synchronization is applied.

Besides, TASCAM FireWire series allows drivers to decide which PCM data
channels are enabled. For convenience, this driver always enable whole the
data channels.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

TASCAM FireWire series uses non-blocking transmission for AMDTP packet
streaming, while the format of data blocks is unique.

The CIP headers includes specific value in FMT field and no SYT
information.

In transmitted packets, the first data channel represents event counter,
and the last data channel has status and control information. The rest
has 24bit PCM samples with right padding.

In received packets, all of data channels include 16, 24, 32bit PCM
samples. There's no other kind of information.

This commit adds support for this protocol. For convenience, the size of
PCM samples in outgoing packet is limited by 16 and 24bit. The status and
control information will be supported in future commits.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

TASCAM FireWire series has certain registers for firmware information.

This commit adds proc node to show the information.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

This commit adds a structure to represent such parameters.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a new driver for TASCAM FireWire series. In this commit,
this driver just creates/removes card instance according to bus event.
More functionalities will be added in following commits.

TASCAM FireWire series consists of:
 * PDI 1394P23 for IEEE 1394 PHY layer
 * PDI 1394L40 for IEEE 1394 LINK layer and IEC 61883 interface
 * XILINX XC9536XL
 * XILINX Spartan-II XC2S100
 * ATMEL AT91M42800A

Ilya Zimnovich had investigated TASCAM FireWire series in 2011, and
discover some features of his FW-1804. You can see a part of his research
in FFADO project.
http://subversion.ffado.org/wiki/Tascam

A part of my work are based on Ilya's investigation, while this series
doesn't support the FW-1804, because of a lack of config ROM
information and its protocol detail, especially for PCM channels.

I observed that FW-1884 and FW-1082 don't work properly with 1394 OHCI
controller based on VT6315. The controller can actually communicate packets
to these models, while these models generate no sounds. It may be due to
the PHY/LINK layer issues. Using 1394 OHCI controller produced by the other
vendors such as Texas Instruments may work. Or adding another node on the
bus.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: 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>

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

Any PCM substreams are jointed because incoming/outgoing AMDTP streams
are bound. When one of PCM substream is running or external clock source
is selected, current sampling rate is used. Else, the sampling rate is
changed as an userspace application requests.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds proc node to show current clock status for debugging.

As long as testing Digi 002 rack, registers can show local clock rate,
local clock source. When external clock input such as S/PDIF is
connected, the registers show the detection and external clock rate.

Additionally, the registers show the mode of optical digital input
interface. Although, a tester with Digi 003 rack reports this makes no
sense. Further investigation is required for Digi 003 series.

Besides, in Digi 002 rack, the S/PDIF format must be IEC 60958-4,
so-called professional.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a functionality to manage streaming.

The streaming is not controlled by CMP in IEC 61883-6. It's controlled by
IEEE 1394 write transaction to certain addresses.

Several clock sources are available, while there're no differences about
packet transmission. The value of SYT field in transmitted packets is
always zero. Thus, streams in both direction don't build synchronization.

And the device always requires received packets to transmit packets. This
driver keeps to transfer outgoing stream even if they're not required.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Digi 002/003 family uses its own format for data blocks. The format is
quite similar to AM824 in IEC 61883-6, while there're some differences:

 * The Valid Bit Length (VBL) code is always 0x40 in Multi-bit Linear Audio
   (MBLA) data channel.
 * The first data channel includes MIDI messages, against IEC 61883-6
   recommendation.
 * The Counter field is always zero in MIDI conformant data channel.
 * Sequence multiplexing in IEC 61883-6 is not applied to the MIDI
   conformant data channel.
 * PCM samples are scrambled in received AMDTP packets. We call the way
   as Double-Oh-Three (DOT). The algorithm was discovered by
   Robin Gareus and Damien Zammit in 2012.

This commit adds data processing layer to satisfy these differences.

There's a quirk about transmission mode for received packets. When this
driver applies non-blocking mode to outgoing packets with isochronous
channel 2 or more, after 15 to 20 seconds since playbacking, any PCM
samples causes noisy sound on the device. With isochronous channel 0 or 1,
this doesn't occur. As long as I investigated, this quirk is not observed
when applying blocking mode to the received packets.

This driver applies blocking mode to outgoing packets, while non-blocking
mode to incoming packgets.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a new driver for Digidesign 002/003 family. This commit
just creates/removes card instance according to bus event. More functions
will be added in following commits.

Digidesign 002/003 family consists of:
 * Agere FW802B for IEEE 1394 PHY layer
 * PDI 1394L40 for IEEE 1394 LINK layer and IEC 61883 interface
 * ALTERA ACEX EP1K50 for IEC 61883 layer and DSP controller
 * ADSP-21065L for signal processing

[minor cleanup using skip_spaces() by tiwai]
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The lack of const leads to a compile warning after merging i915
upstream tree:
   drivers/gpu/drm/i915/intel_audio.c:147:13: note: expected 'struct drm_display_mode *' but argument is of type 'const struct drm_display_mode *'
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_pcm_release_substream() always calls hw_free op when the stream
was opened.  This is superfluous in most cases because it's been
already released via explicit hw_free ioctl.  Although this double
call is usually OK as this callback should be written to be called
multiple times, it's better to avoid superfluous calls.
Reported-by: NVinod Koul <vinod.koul@intel.com>
Tested-by: NJeeja Kp <jeeja.kp@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit moves the codes related to data block processing from packet
streaming layer to AM824 layer.

Each driver initializes amdtp stream structure for AM824 data block by
calling amdtp_am824_init(). Then, a memory block is allocated for AM824
specific structure. This memory block is released by calling
amdtp_stream_destroy().

When setting streaming parameters, it calls amdtp_am824_set_parameters().
When starting packet streaming, it calls amdtp_stream_start(). When
stopping packet streaming, it calls amdtp_stream_stop().
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit renames some macros just related to AM824 format. In later
commit, they're moved to AM824 layer.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Setting the format of PCM substream to AMDTP stream structure is important
to set a handler to copy actual PCM samples between buffers. The
processing should be in data block processing layer because essentially
it has no relationship to packet streaming.

This commit renames PCM format setting function to prepare for integrating
AM824 layer.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In IEC 61883-6, MIDI messages are transferred in MIDI conformant data
channel. Essentially, packet streaming layer is not responsible for MIDI
functionality.

This commit moves MIDI trigger helper function from the layer to AM824
layer. The rest of codes related to MIDI functionality will be moved in
later commits.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In IEC 61883-6, several types of data are available in AM824 format. The
data is transferred in each data channel. The position of data channel in
data block differs depending on model.

Current implementation has an array to map the index of data channel in an
data block to the position of actual data channel. The implementation
allows each driver to access the mapping directly.

In later commit, the mapping is in specific structure pushed into an
opaque pointer. Helper functions are required.

This commit adds the helper functions for this purpose. In IEC 61883-6,
AM824 format supports many data types, while this specification easily
causes over-engineering. Current AM824 implementation is allowed to handle
two types of data, Multi Bit Linear Audio data (=PCM samples) and MIDI
conformant data (=MIDI messages).
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In IEC 61883-6, PCM frames are transferred in Multi Bit Linear Audio data
channel. The data channel transfers 16/20/24 bit PCM samples. Thus, PCM
substream has a constrain about it.

This commit moves codes related to the constraint from packet streaming
layer to AM824 data block processing layer.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The value of FDF field in CIP header is protocol-dependent. Thus, it's
better to allow data block processing layer to decide the value in any
timing.

In AM824 data format, the value of FDF field in CIP header indicates
N-flag and Nominal Sampling Frequency Code (sfc). The N-flag is for
switching 'Clock-based rate control mode' and 'Command-based rate control
mode'. In our implementation, 'Clock-based rate control mode' is just
supported. Therefore, When sampling transfer frequency is decided, then
the FDF can be set.

This commit replaces 'amdtp_stream_set_parameters' with
'amdtp_am824_set_parameters' to set the FDF. This is the same timing
to decide the ration between the number of data blocks and the number of
PCM frames.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds data block processing layer for AM824 format. The new
layer initializes streaming layer with its value for fmt field.

Currently, most implementation of data block processing still remains
streaming layer. In later commits, these codes will be moved to the layer.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In later commit, data block processing layer will be newly added. This
layer will be named as 'amdtp-am824'.

This commit renames current amdtp file to amdtp-stream, to distinguish it
from the new layer.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some vendor specific protocol uses its own value for fmt/fdf fields in
CIP header.

This commit support to set arbitrary values for the fields.

In IEC 61883-6, NO-DATA code is defined for FDF field. A packet with this
code includes no data even if it includes some data blocks. This commit
still leaves a condition to handle this special packet.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA: firewire-lib: add helper functions as interfaces between packet streaming layer and data block processing layer

ALSA PCM framework uses PCM buffer with a concept of 'period' to
synchronize userspace operations to hardware for nearly-realtime
processing. Each driver implements snd_pcm_period_elapsed() to tell across
of the period boundary to ALSA PCM middleware. To call the function, some
drivers utilize hardware interrupt handlers, the others count handled PCM
frames.

Drivers for sound units on IEEE 1394 bus are the latter. They use two
buffers; PCM buffer and DMA buffer for IEEE 1394 isochronous packet. PCM
frames are copied between these two buffers and 'amdtp_stream' structure
counts the handled PCM frames. Then, snd_pcm_period_elapsed() is called if
required.

Essentially, packet streaming layer should not be responsible for PCM
frame processing. The PCM frame processing should be handled in each data
block processing layer as a result of handling data blocks. Although, PCM
frame counting is a common work for all of protocols which ALSA firewire
stack is going to support.

This commit adds two new helper functions as interfaces between packet
streaming layer to data block processing layer. In future, each data block
processing layer implements these functions. The packet streaming layer
calls data block processing layer per packet by calling the functions. The
data block processing layer processes data blocks and PCM frames, and
returns the number of processed PCM frames. Then the packet streaming layer
calculates handled PCM frames and calls snd_pcm_period_elapsed().
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In future commit, interface between data block processing layer and packet
stream processing layer is defined. These two layers communicate the
number of data blocks and the number of PCM frames.

The data block processing layer has a responsibility for calculating the
number of PCM frames. Therefore, 'dual wire' of Dice quirk should be
handled in data block processing layer.

This commit adds a member of 'frame_multiplier'. This member represents
the ratio of the number of PCM frames against the number of data blocks.
Usually, the value of this member is 1, while it's 2 in Dice's 'dual wire'.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>