ALSA: dice: Remove left-over license text

Following a commit 1dd0dd0b1fef ("ALSA: firewire: Remove some left-over
license text in sound/firewire"), this patch removes it added carelessly.

Fixes: 2133dc91d665 ("ALSA: dice: add support for Focusrite Saffire Pro 40 with TCD3070 ASIC")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20221201030100.31495-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: dice: add support for Focusrite Saffire Pro 40 with TCD3070 ASIC

TC Applied Technologies (TCAT) produces TCD3070 as final DICE ASIC for
communication in IEEE 1394 bus for IEC 61883-1/6 protocol. As long as I
know, latter model of Focusrite Saffire Pro 40 is an application of the
ASIC and only in the market for consumers.

This patchset adds support for the device. The device has several
remarkable points.

1. No support for extended synchronization information section in TCAT
general protocol. The value of GLOBAL_EXTENDED_STATUS register is always
zero. Additionally, NOTIFY_EXT_STATUS message is never emitted.

2. No support for TCAT protocol extension. Hard coding is required for
format of CIP payload.

3. During several seconds after changing sampling rate, the block to
process PCM frames is under disfunction. When starting packet streaming
during the state, the block is never function till configuring different
sampling rate and several seconds.

This commit adds support for the device. The item 1 and 2 can be
adaptable, while item 3 is not. It's not preferable that user process
is forced to sleep during the disfunction in the call of ioctl(2) with
SNDRV_PCM_IOCTL_HW_PARAMS or SNDRV_PCM_IOCTL_PREPARE request. It's
inconvenient but let user configure preferable sampling rate in advance
of starting PCM substream.

The content of configuration ROM in the device I used is available at:
* https://github.com/takaswie/am-config-roms/

I note that any mixer control operation is implemented by unique
transaction. The frame of request consists of 16 bytes header followed
by payload.

header (4 quadlets):
1st: the type of request, prefixed with 0x8000
2nd: counter at 2 bytes in MSB side, the length of data at 2 bytes in LSB
side
3rd: parameter 0
4th: parameter 1

payload (variable length if need):
5th-: data according to parameters

The request frame is sent by block write request to 0x'ffff'e040'01c0.

The frame of response is similar to the frame of request, but it is
header only, thus fixed to 16 bytes. The response frame is sent to the
address which is registered by lock transaction to 0x'ffff'e040'0008.

If the operation results in batch of data, the 2nd quadlet of header
includes the length of data like request. The data is itself readable
by read block request to 0x'ffff'e040'0030, which includes both
header and payload for data, thus the length to read should be the
length of data plus 16 bytes for header

The actual value of request, parameter 0, parameter 1, and data is
unclear yet.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20221130143313.43880-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>