hello,dear support team:
I have a question about CPHY,
According to the Orin-TRM_DP10508002_v1.0p.pdf
1.1 Pixel Conveyances
Brick One instantiation of NVCSI; the hardware-managing lanes and links that are used. The D-PHY/C-PHY bricks have four lanes that can
individually be configured into an x4 stream, an x2/x2 stream pair, an x2/x1 stream pair, or an x1/x1 stream pair. There are two D-PHY/C-PHY bricks that can use both streams in a pair, and two D-PHY/C-PHY bricks that have only one stream connected.
Does this mean that a CPHY can also receive only one stream by combining two bricks like a DPHY 8-lanes mode.If possible, what configuration do I need to do at the NVCSI SCIL level?
We are a CMOS design company,Due to design limitations, we can only do 2.5Gsps/trio,
target stream should be16384x10920x12bit@15fps
Due to the limitations of our chip design capabilities,I know Orin supports to 4.5Gsps/trio,However, the CMOS sensor we designed can only emit MIPI signals with 2.5Gsps/trio。
we have reference CPHY sensor, (IMX318 based CPHY sensor) that’s validate up-to 1.06 Gsps.
for evaluation… our internal verification confirms that up-to 2.5 Gsps in C-PHY can be received with default CSI settings.
hence,
please go ahead to have a try, please gather logs if you bump into issues.
thanks
hello jerry
We have verified 3-trios under 16384x10920x12bit@7fps, @2.5Gsps
If we wanted to transfer 16384x10920x12bit@15fps, we would probably need 6-trios at least , so we would need two NVCSI bricks. What additional configuration does that require?The IMX318 sensor is only available in 3-trios reference configuration.
this was supported on TX2 series, using two NVCSI bricks is done by VI drivers.
let me show the code-snippet as below. $public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c
static int tegra_channel_csi_init(struct tegra_channel *chan)
{
...
for (idx = 0; idx < TEGRA_CSI_BLOCKS && csi_port_is_valid(chan->port[idx]); idx++) {
chan->total_ports++;
/* maximum of 4 lanes are present per CSI block */
chan->csibase[idx] = vi->iomem +
TEGRA_VI_CSI_BASE(chan->port[idx]);
}
/* based on gang mode valid ports will be updated - set default to 1 */
chan->valid_ports = chan->total_ports ? 1 : 0;
TX2 supported this due to bandwidth limitation, it needs to enable 4K by gang mode.
however,
we don’t really test merge CSI bricks since Xavier (and later) series have higher capability.
Thank you very much for your reply, it seems to be exactly what I was looking for. So how do I use this gang mode? I see Orin SDK code also has a related implementation, we want to have a try，are there any relevant camera driver samples?
this is common VI driver, vi/channel.c,
Orin series use this VI operation drivers, vi/vi5_fops.c, whereas TX2 use this VI operation drivers, vi/vi4_fops.c
you may see-also TX2 codes for reference.
Sounds like good news. Could you please help with the testing of CPHY gang mode? This might be a little difficult for us, and will the use of gang mode involve some code that is not open source?
sorry, we don’t have device to test this locally.
as you can see in the Camera Architecture Stack. those code were public sources as long as you’re using v4l2 interface.
you may choose the mode depends-on your use-case,
let’s taking CAMERA_GANG_L_R as an example, that’s means left/right gang mode,
for such setting, it’s 1st CSI brick will fill the left region and 2nd CSI brick to fill the right region.