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@xxxxxxxxxxxxx> Thanks, applied. Takashi
