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

[Takashi Iwai]

On Wed, 30 Nov 2022 15:33:13 +0100,
Takashi Sakamoto wrote:
> 
> 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 at sakamocchi.jp>

Thanks, applied.


Takashi