tc358743-audio.dts overlay allows audio to be captured. I2S audio is a 48kHz sampling rate at 32 bit/sample.
According to gstreamer, the following caps are supported. This seems to indicate that up to 8-channel audio (likely 7.1) capture is supported by the tc35874x driver. I haven't tested more than stereo, and haven't made sure it isn't just mono.
audio/x-raw, format={ (string)S32LE, (string)S24_32LE, (string)S16LE, (string)S8 }, layout=interleaved, rate=[ 8000, 192000 ], channels=2, channel-mask=0x0000000000000003
audio/x-raw, format={ (string)S32LE, (string)S24_32LE, (string)S16LE, (string)S8 }, layout=interleaved, rate=[ 8000, 192000 ], channels=3, channel-mask=0x000000000000000b
audio/x-raw, format={ (string)S32LE, (string)S24_32LE, (string)S16LE, (string)S8 }, layout=interleaved, rate=[ 8000, 192000 ], channels=4, channel-mask=0x0000000000000033
audio/x-raw, format={ (string)S32LE, (string)S24_32LE, (string)S16LE, (string)S8 }, layout=interleaved, rate=[ 8000, 192000 ], channels=6, channel-mask=0x000000000000003f
audio/x-raw, format={ (string)S32LE, (string)S24_32LE, (string)S16LE, (string)S8 }, layout=interleaved, rate=[ 8000, 192000 ], channels=8, channel-mask=0x0000000000000c3f
Data path seems like it should be: sensor -> csi2_dphy -> mipi_csi -> rkcif_mipi_lvds
Despite creating the expected devices, etc, this doesn't seem to actually produce any video (revision #2 of the dts). The only way I could get something working was to link in the ISP. This doesn't seem like it'd be required. The docs aren't particularly clear on this, but they make it appear that the ISP is optional (or maybe only optional for non-bayer data).
It may be that the VICAP block only supports YCbCr 8-bit 4:2:2). But the TC358743XBG also claims to support output of RGB, YCbCr 4:4:4 and 4:2:2 both @ 8-bit. Maybe this is where exact pixel format becomes important. Potentially one in NV16 (4:2:2) and the other is YUYV. This would explain needing to involve the ISP in conversion, I guess...
Input that the driver detects is (via media-ctl) listed as:
fmt:UYVY8_2X8/1920x1080@10000/600000 field:none colorspace:smpte170m
And the output appears to be:
fmt:YUYV8_2X8/1920x1080 field:none colorspace:smpte170m
This seems to suggest the detected pixel format from the TC358743 is 8-bit UYVY, and it's converted to 8-bit YUYV for downstream consumption (into the vicap block). The difference appears to be ordering of data, while it's the same data:
format | pixel 0 | pixel 1 | pixel 2 | pixel 3 |
---|---|---|---|---|
UYVY | Cb | Y | Cr | Y |
YUYV | Y | Cb | Y | Cr |
In order to do this, the ISP seems to be needed to do the conversion before it gets to the vicap, which makes the data available to v4l2, etc.