In former commits, proxy structure get members for cache of stream
formats. This commit fills the cache with stream formats at current mode
of sampling transmission frequency.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Products with DICE interface in market can support variable stream
formats for three levels of sampling transmission frequencies. To
record these formats, a proxy structure got several fields in former
commit.

This commit adds a proc node to output the stream formats for debugging
purpose.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Unlike the other drivers in ALSA firewire stack, ALSA dice driver does't
create 'firewire' directory for proc nodes because it has 'dice' node
only. But this is inconvenient because I have a plan to add another proc
node to output available stream formats from cache.

This commit let the driver to create the directory and put 'dice' node
into it.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A previous commit 6f688268 ('ALSA: dice: purge generating channel
cache') purged cache of stream formats. DICE interface originally has
no feature to assist drivers to retrieve available formats for all of
supported sampling transmission frequencies, without changing the
frequency actually.

For later release of Dice ASICs such as TCD2210, Dice interface has
extended protocol and can support the feature. This assists drivers
to retrieve available stream formats.

This commit is a first step to regain the cache to generate PCM rules
for all of supported sampling transmission frequencies.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In early stage of firmware SDK, DICE seems to lose its backward
compatibility due to some registers on global address section. I found
this with Alesis Multimix 12 FireWire with ancient firmware (approx.
shipped version).

According to retrieved log from the unit, global section has 96 byte
space. On the other hand, current version of ALSA dice driver assumes
that all of supported unit has at least 100 byte space.

$ ./firewire-request /dev/fw1 read 0xffffe0000000 28
result: 000: 00 00 00 0a 00 00 00 18 00 00 00 22 00 00 00 8a
result: 010: 00 00 00 ac 00 00 01 12 00 00 00 00 00 00 00 00
result: 020: 00 00 00 00 00 00 00 00

This commit adds support for the ancient firmware. Check of global section
is loosened to accept the smaller space. The lack of information is
already compensated by hard-coded parameters.

I experienced that the latest version of Windows driver for this model
can't handle this unit, too. This means that TCAT releases firmware SDK
without backward compatibility for the ancient firmware.

Below list is a early history of driver/firmware package released by
Alesis. I investigated on wayback machine on Internet Archive:
 * Unknown: PAL v1.0.41.2, firmware v1.0.3
 * Mar 2006: PAL v1.54.0, firmware v1.0.4
 * Dec 2006: PAL v2.0.0.2, firmware v2.0
 * Jun 2007: PAL v3.0.41.5, firmware v2.0
 * Jul 2007: PAL v3.0.56.2. firmware v2.0
 * Jan 2008: PAL v3.0.81.1080, firmware v2.0

If I can assume that firmware version is the same as DICE version, DICE
version for the issued firmware may be v1.0.3. According to code base of
userspace driver project (FFADO), I can read DICE v1.0.4 supports global
space larger than 100 byte. I guess the smaller space of global section is
a feature of DICE v1.0.3.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

OUI for TC Electronic is 0x000166, for TC GROUP A/S. 0x001486 is for Echo
Digital Audio Corporation.

Fixes: 7cafc65b ('ALSA: dice: force to add two pcm devices for listed models')
Cc: <stable@vger.kernel.org> # v4.6+
Reference: http://standards-oui.ieee.org/oui/oui.txtSigned-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers in ALSA firewire stack still includes some symbols which can be
moved to a section for read-only symbols.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In ALSA firewire stack, 8 drivers uses IEC 61883-1/6 engine for data
transmission. They have common PCM info/constraints and duplicated codes.

This commit unifies the codes into fireiwre-lib.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In recent commit for ALSA PCM core, some arrangement is done for
'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
explicitly moved in intermediate buffer for PCM frames, except for
some cases described later.

For drivers in ALSA firewire stack, usage of this callback has a merit to
reduce latency between time of PCM frame queueing and handling actual
packets in recent isochronous cycle, because no need to wait for software
IRQ context from isochronous context of OHCI 1394.

If this works well in a case that mapped page frame is used for the
intermediate buffer, user process should execute some commands for ioctl(2)
to tell the number of handled PCM frames in the intermediate buffer just
after handling them. Therefore, at present, with a combination of below
conditions, this doesn't work as expected and user process should wait for
the software IRQ context as usual:
 - when ALSA PCM core judges page frame mapping is available for status
   data (struct snd_pcm_mmap_status) and control data
   (struct snd_pcm_mmap_control).
 - user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
   and 'snd_pcm_mmap_commit()'.
 - user process uses PCM hw plugin in alsa-lib to operate I/O without
   'sync_ptr_ioctl' option.

Unfortunately, major use case include these three conditions.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In IEC 61883-6, AM824 is described as format of data block. In this
format, one data block consists of several data channels, which is aligned
to 32 bit. One data channel has 8 bit label field and 24 bit data field.
PCM frames are transferred in Multi Bit Linear Audio (MBLA) data channel.
This channel can include 16/20/24 bit PCM sample.

As long as I know, models which support IEC 61883-1/6 doesn't allow to
switch bit length of PCM sample in MBLA data channel. They always
transmit/receive PCM frames of 24 bit length. This can be seen for the
other models which support protocols similar to IEC 61883-1/6.

On the other hand, current drivers for these protocols supports 16 bit
length PCM sample in playback substream. In this case, PCM sample is put
into the MBLA data channel with 8 bit padding in LSB side. Although 16
bit PCM sample is major because it's in CD format, this doesn't represent
device capability as is.

This commit removes support for 16 bit PCM samples in playback substream.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>

Fix up affected files that include this signal functionality via sched.h.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Now snd_rawmidi_ops is maintained as a const pointer in snd_rawmidi,
we can constify the definitions.
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some identifiers are referred just by one functions. In this case, they
can be put into the function definition. This brings two merits; readers
can easily follow codes related to the identifiers, developers are free
from name conflict.

This commit moves such identifiers to each function definition.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As of kernel 4.10, ALSA dice driver is expected to be used in default
speed. In most cases, it's S400. While, IEEE 1394 specification describes
the other speed such as S800.

According to 'TCD30XX User Guide', its link layer controller supports
several transmission speed up to S800[0]. In Dice software interface,
transmission speed in output direction can be configured by asynchronous
transaction to 'TX_SPEED' offset in its address space. S800 may be
available.

This commit improves configuration of transmission unit before starting
packet streaming for this purpose. The value of 'max_speed' in 'fw_device'
data structure has available maximum speed decided in bus arbitration,
thus it's within capacity of the unit.

[0] TCD3xx User Guide - TCAT 1394 LLC, Revision 0.9.0-41360 (TC Applied Technologies, May 6 2015)
http://www.tctechnologies.tc/index.php/support/support-hardware/dice-iii-detailed-documentationSigned-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Check for snd_pcm_ops structures that are only stored in the ops field of a
snd_soc_platform_driver structure or passed as the third argument to
snd_pcm_set_ops.  The corresponding field or parameter is declared const,
so snd_pcm_ops structures that have this property can be declared as const
also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_pcm_ops i@p = { ... };

@ok1@
identifier r.i;
struct snd_soc_platform_driver e;
position p;
@@
e.ops = &i@p;

@ok2@
identifier r.i;
expression e1, e2;
position p;
@@
snd_pcm_set_ops(e1, e2, &i@p)

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_pcm_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct snd_pcm_ops i = { ... };
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

M-Audio Profire 610 has an unexpected value in version field of its config
ROM, thus ALSA dice driver is not assigned to the model due to a mismatch
of modalias.

This commit adds an entry to support the model. I expect the entry is
also for Profire 2626.

I note that Profire 610 uses TCD2220 (so-called Dice Jr.), and supports a
part of Extended Application Protocol (EAP).

$ cd linux-firewire-utils/src
$ ./crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               ------------------------------------------------------------
400  04047689  bus_info_length 4, crc_length 4, crc 30345
404  31333934  bus_name "1394"
408  e0ff8112  irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
               max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
40c  000d6c04  company_id 000d6c     |
410  04400002  device_id 0404400002  | EUI-64 000d6c0404400002

               root directory
               ------------------------------------------------------------
414  000695fe  directory_length 6, crc 38398
418  03000d6c  vendor
41c  8100000a  --> descriptor leaf at 444
420  17000011  model
424  8100000d  --> descriptor leaf at 458
428  0c0087c0  node capabilities per IEEE 1394
42c  d1000001  --> unit directory at 430

               unit directory at 430
               ------------------------------------------------------------
430  0004fb14  directory_length 4, crc 64276
434  12000d6c  specifier id
438  130100d1  version
43c  17000011  model
440  8100000c  --> descriptor leaf at 470

               descriptor leaf at 444
               ------------------------------------------------------------
444  0004b8e4  leaf_length 4, crc 47332
448  00000000  textual descriptor
44c  00000000  minimal ASCII
450  4d2d4175  "M-Au"
454  64696f00  "dio"

               descriptor leaf at 458
               ------------------------------------------------------------
458  00053128  leaf_length 5, crc 12584
45c  00000000  textual descriptor
460  00000000  minimal ASCII
464  50726f46  "ProF"
468  69726520  "ire "
46c  36313000  "610"

               descriptor leaf at 470
               ------------------------------------------------------------
470  00053128  leaf_length 5, crc 12584
474  00000000  textual descriptor
478  00000000  minimal ASCII
47c  50726f46  "ProF"
480  69726520  "ire "
484  36313000  "610"

$ cat /proc/asound/card1/dice
sections:
  global: offset 10, size 90
  tx: offset 100, size 142
  rx: offset 242, size 282
  ext_sync: offset 524, size 4
  unused2: offset 0, size 0
global:
  owner: ffc0:000100000000
  notification: 00000040
  nick name: FW610
  clock select: internal 48000
  enable: 1
  status: locked 48000
  ext status: 00000040
  sample rate: 48000
  version: 1.0.4.0
  clock caps: 32000 44100 48000 88200 96000 176400 192000 aes1 aes4 aes adat tdif wc arx1 arx2 internal
  clock source names: SPDIF\AES34\AES56\TOS\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\\
  ...
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In former commit, ALSA dice driver postpone sound card registration after
IEEE 1394 bus is calm. This idea has advantages for the other drivers.

This commit adds a helper function for it to firewire-lib module. The
function is really for the specific purpose. Callers should initialize
delayed work structure with callback function.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In former commit, ALSA dice driver doesn't generate kernel warnings
when unplugging units before initializing stream data.

This commit moves the initialization to delayed registration of sound
card, to simplify unit probe processing.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When sound card is going to be released, dice private data is
also released. Then all of data should be released. However,
stream data is not released. This causes memory leak when
unplugging dice unit.

This commit fixes the bug.

Fixes: 4bdc495c('ALSA: dice: handle several PCM substreams when any isochronous streams are available')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In dice interface, two blocks of register are accessible via IEEE 1394
asynchronous transaction to represent the number of supported isochronous
streams and the number of quadlets for stream information.

Current ALSA dice driver uses array with 'unsigned int' element for
temporary cache of these information. But using structure is preferable
for begin easily comprehensible.

This commit applies a local structure for this aim.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some models reduce the number of available isochronous streams for higher
sampling transfer frequency. Such models bring an issue about how to add
PCM substreams. When at lower sampling transfer frequency, the
models reports whole available streams, thus this driver can add enough
number of PCM substreams at probing time. On the other hand, at higher
sampling transfer frequency, this driver can just add reduced number of
PCM substreams. After probed, even if the sampling transfer frequency is
changed to lower rate, fewer PCM substreams are actually available. This
is inconvenience.

For the reason, this commit adds a list so that this driver assume models
on the list to have two pairs of PCM substreams. This list keeps the name
of model in which the number of available streams differs depending on
sampling transfer frequency.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In former commits, ALSA dice driver can handle available isochronous
streams. This commit adds support for several PCM substreams on the
streams.

The additional PCM substreams are available via another ALSA PCM character
devices so that one ALSA PCM application can handle them without cumbersome
operations. For example, two PCM substreams are available on each stream,
two ALSA character devices are added for them. In configuration space of
alsa-lib, it's represented with 'hw:0,0' and 'hw:0,1'.

The PCM substreams are constraint to parameters of the corresponding
streams. If the PCM substreams are unavailable for some reasons,
open(2) to ALSA PCM character device returns error and reports ENXIO.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit enables ALSA dice driver to handle whole available streams.

In Dice, certain registers represent the number of available streams at
current sampling transfer frequency for both directions. The parameters
of each stream are represented in a block of register. This block is
aligned sequentially. These streams start simultaneously by writing
enable bit to a register.

This commit operates these registers when starting/stopping streams.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently ALSA dice driver handles a pair of isochronous resources for
IEC 61883-1/6 packet streaming. While, according to some documents about
ASICs named as 'Dice', several isochronous streams are available.

Here, I start to describe ASICs produced under 'Dice' name.
 * Dice II (designed by wavefront semiconductor, including TCAT's IP)
   * STD (with limited functionality of DTCP)
   * CP  (with full functionality of DTCP)
 * TCD2210/2210-E (so-called 'Dice Mini')
 * TCD2220/2220-E (so-called 'Dice Jr.')
 * TCD3070-CH (so-called 'Dice III')

Some documents are public and we can see hardware design of them. We can
find some articles about hardware internal register definitions
(not registers exported to IEEE 1394 bus).

* DICE II User Guide
  * http://www.tctechnologies.tc/archive/downloads/dice_ii_user_guide.pdf
    * 6.1 AVS Audio Receivers
      * Table 6.1: AVS Audio Receiver Memory Map
        * ARX1-ARX4
    * 6.2 AVS Audio Transmitters
      * Table 6.2: AVS Audio Transmitter Memory Map
        * ATX1, ATX2
* TCD22xx User Guide
  * http://www.tctechnologies.tc/downloads/tcd22xx_user_guide.pdf
    * 6.1 AVS Audio Receivers
      * Table 66: AVS Audio Receiver Memory Map
        * ARX1, ARX2
    * 6/2 AVS Audio Transmitters
      * Table 67: AVS Audio Transmitter Memory Map
        * ATX1, ATX2
* DICE III
  * http://www.tctechnologies.tc/downloads/TCD3070-CH.pdf
    * Dual stream 63 channel transmitter/receiver

For Dice II and TCD22xx series, maximum 16 data channels are transferred in
an AMDTP packet, while for Dice III, maximum 32 data channels are
transferred.

According to the design of the series of these ASICs, this commit allows
this driver to handle additional set of isochronous resources. For
practical reason, two pair of isochronous resources are added. As of this
commit, this driver still use a pair of the first isochronous resources.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit drops implementation of duplex streams synchronization
from ALSA dice driver, due to a reason of hardware design. This patch
allows dice-based units to generate sounds correctly when isochronous
packet streaming starts at first time.

In IEC 61883-6:2005, CIP packetization layer for AM824 data format
utilizes the value of SYT field in CIP header of received packet for
a reference to phase lock loop. Figure 3 in clause 4.3 describes it.
The value is an offset from cycle_time field of every cycle start packet
from cycle master on IEEE 1394 bus. The time calculated with these two
fields is called as 'presentation timestamp' which represents the time
to play data included in the packet.

Although, this idea includes some problems due to accuracy of timekeep in
cycle master, accuracy of transmission of cycle start packet on the bus
with the other units, accuracy of sampling clock in data transmitter side
and accuracy of replay in data receiver side. In most case, these
accuracies somewhat worse because there's no such ideal hardwares in this
world.

For the issues, ASICs for Dice include Jitter Elimination Technologies
(JET) PLL. The PLL can handle several sources of clock and compensate it
with high-precision internal clock source. The sequence of value in syt
field of received AMDTP packets is one of the sources, therefore
transmitters on IEEE 1394 bus should transfer it.

On the other hand, current ALSA dice driver is programmed with a mode of
duplex streams with synchronization. In this mode, the driver outputs
packets after some incoming packets are handled, to re-use the value of
SYT field in incoming packets to the value for outgoing packets. This mode
is enabled when source signal of sampling clock is set to internal, and
this is a major use case. Thus, in most cases, the unit receives no packets
during a short time after packet streaming starts.

As long as I experienced, this causes the units to generate no sounds at
first time to receive packets. This issue occurs only with Dice II. I guess
this is due to a quirk of the PLL. In short, the PLL cannot generate firm
signals to ADCs/DACs or the other ICs when no packets are received in the
beginning of packet streaming. While, on second time or later, the unit
generates sound correctly. I guess that starting packet streaming at first
time sets the PLL correctly.

Well, still based on my hypothesis and no way to prove it, this commit
drops duplex streams synchronization from this driver. At least, the PLL
requires the sequence of value in SYT field of received AMDTP packets as
one of source of clock signals with internal clock source.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As long as I tested, Dice-based models produced by TC Electronic with
factory-configured settings transfer no notification within
ensure_phase_lock(). On the other hand, with upgraded firmwares, it
starts to transfer the notification. This seems to be a quirk of earlier
firmwares.

This commit ensures phase lock by reading a register after waiting for
the notification. Even if it's timed-out, ensure_phase_lock() return
success as long as the register has expected clock status.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With former patchset, ALSA dice driver doesn't change clock parameters
anymore, while the driver still touch clock configuration for phase lock.

Although the locking status is in Dice notification, the driver doesn't
detect it. Usually, this causes no issues because in most case
NOTIFY_LOCK_CHG notification transfers after NOTIFY_CLOCK_ACCEPTED
notification, while it's better to detect locking status.

This commit changes notification mask just to detect lock status change.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In former commits, probing process has no need to set sampling transfer
frequency. Although it's OK to drop a function to change the frequency
from this module, some models require it before streaming. This seems to
be due to phase lock of clock source.

This commit moves the function from transaction layer to stream layer, and
rename it according to the purpose.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Dice interface design doesn't allow drivers to read supported combination
between sampling transfer frequencies and the number of Multi bit linear
audio data channels. Due to the design, ALSA dice driver changes current
sampling transfer frequency to generate cache of the combinations at
device probing processing.

Although, this idea is worse because ALSA dice driver changes the state of
clock. This is not what users want when they save favorite configuration
to the device in advance.

Furthermore, there's a possibility that the format of data block is decided
not only according to current sampling transfer frequency, but also the
other factors, i.e. data format for digital interface. It's not good to
generate channel cache according to the sampling transfer frequency only.

This commit purges processing cache data and related structure members. As
a result, users must set preferable sampling transfer frequency before
using ALSA PCM applications, as long as they want to start any PCM
substreams at the rate except for current one.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit is a preparation to remove members related to channel cache
for the number of channels for multi bit linear audio data and MIDI
ports. This commit changes the way to get the number of multi bit linear
audio data channel. It's directly retrieved by asynchronous transactions
to some registers.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit changes the way to add ALSA MIDI ports. This driver read the
number of multiplexed MIDI substreams from hardware register, then adds the
same number of ALSA MIDI ports. This commit is based on my assumption that
the number is fixed at all of supported sampling transfer frequency.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In previous commit, ALSA Dice driver limits PCM substreams at current
sampling transfer frequency and current number of Multi bit linear audio
data channel. Thus, the driver has no need to start AMDTP streams at
the other sampling transfer frequency except for current one. This is due
to Dice interface design.

This commit limits AMDTP stream at current sampling transfer frequency,
according to the design.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA PCM core has a functionality for rule of PCM substream parameters.
Typically, when userspace opens PCM character devices, each driver adds
its own rules to PCM substream according to design of hardware. When the
userspace executes hw_params ioctl with favorite parameters, the actual
parameters are calculated according to the rules and the given parameters.
Then, the result is returned to userspace.

Currently, ALSA Dice driver has the rule between channels and rates, while
Dice interface design doesn't allow drivers to retrieve all of the
combinations. Dice drivers are just allowed to get current sampling
transfer frequency and the number of multi bit linear audio data channels
in an data block of an AMDTP packet.

This commit purges the rule, and limit PCM substreams to current sampling
transfer frequency, following to the interface design.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some users have reported that their Dice based models generate ETIMEDOUT
when starting PCM playback. It means that current timeout (=100msec) is
not enough for their models to transfer notifications.

This commit expands the timeout up to 2 sec. As a result, in a worst case,
any operations to start AMDTP streams takes 2 sec or more. Then, in
userspace, snd_pcm_hw_params(), snd_pcm_prepare(), snd_pcm_recover(),
snd_rawmidi_open(), snd_seq_connect_from() and snd_seq_connect_to() may
take the time.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In previous commit, card registration is processed under situation
with few bus reset. There's no need to add a workaround of transaction
re-initialization at timeout.

This commit purges the re-initialization.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some models based on ASIC for Dice II series (STD, CP) change their
hardware configurations after appearing on IEEE 1394 bus. This is due to
interactions of boot loader (RedBoot), firmwares (eCos) and vendor's
configurations. This causes current ALSA dice driver to get wrong
information about the hardware's capability because its probe function
runs just after detecting unit of the model.

As long as I investigated, it takes a bit time (less than 1 second) to load
the firmware after bootstrap. Just after loaded, the driver can get
information about the unit. Then the hardware is initialized according to
vendor's configurations. After, the got information becomes wrong.
Between bootstrap, firmware loading and post configuration, some bus resets
are observed.

This commit offloads most processing of probe function into workqueue and
schedules the workqueue after successive bus resets. This has an effect to
get correct hardware information and avoid involvement to bus reset storm.

For code simplicity, this change effects all of Dice-based models, i.e.
Dice II, Dice Jr., Dice Mini and Dice III.

I use a loose strategy to manage a race condition between the work and the
bus reset. This is due to a specification of dice transaction. When bus
reset occurs, registered address for the transaction is cleared. Drivers
must re-register their own address again. While, this operation is required
for the work because the work includes to wait for the transaction. This
commit uses no lock primitives for the race condition. Instead, checking
'registered' member of 'struct snd_dice' avoid executing the work again.
If sound card is not registered, the work can be scheduled again by bus
reset handler.

When .remove callback is executed, the sound card is going to be released.
The work should not be pending or executed in the releasing. This commit
uses cancel_delayed_work_sync() in .remove callback and wait till the
pending work finished. After .remove callback, .update callback is not
executed, therefore no works are scheduled again.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Before allocating an instance of sound card, ALSA dice driver checks
chip_ID_hi in Bus information block of Config ROM, then also checks
subaddresses. The former operation reads cache of Config ROM in Linux
FireWire subsystem, while the latter operation sends read transaction.
The latter can be merged into initialization of transaction system.

This commit splits these two operations to reduce needless transactions
in probe processing.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>