Hi,
Customer reference e2e.ti.com/.../tda4vm-raw16-capture-demo
It is said that gstreamer can be used to capture directly, but customer failed to try on the board,the j721e-csi2rx driver in the kernel does not have the raw16 format as well.
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
Customer reference e2e.ti.com/.../tda4vm-raw16-capture-demo
It is said that gstreamer can be used to capture directly, but customer failed to try on the board,the j721e-csi2rx driver in the kernel does not have the raw16 format as well.
Hi Nancy,
j721e-csi2rx driver in the kernel does not have the raw16 format
Yes, you are correct. But it could be easily added in the struct static const struct ti_csi2rx_fmt formats[ ] available in j721e-csi2rx driver.
The same is mentioned at the end of this struct "More formats can be supported but they are not listed for now"
Could you please ask customer to add the format and test?
Regards,
Nikhil
Hi Nikhil,
Thanks for your support and I will keep follow on this case now.
The customer has added the contents of RAW16, the macro definition for CSI_DF_RAW16 is 0x2e. While it still cannot receive.
Thanks and regards,
Cherry
Hi Cherry,
The way it is added is correct.
Could you please confirm if this change is being reflected in "media-ctl -p"?
Could I get the logs of the same media-ctl -p as well as the application logs?
Regards,
Nikhil
Hi Nikhil,
Please see the following "media ctl -p":
Media controller API version 5.10.120
Media device information
------------------------
driver j721e-csi2rx
model TI-CSI2RX
serial
bus info platform:4500000.ticsi2rx
hw revision 0x1
driver version 5.10.120
Device topology
- entity 1: 4500000.ticsi2rx (17 pads, 17 links, 1 route)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
routes:
0/0 -> 1/0 [ACTIVE]
pad0: Sink
<- "cdns_csi2rx.4504000.csi-bridge":1 [ENABLED,IMMUTABLE]
pad1: Source
-> "4500000.ticsi2rx context 0":0 [ENABLED,IMMUTABLE]
pad2: Source
-> "4500000.ticsi2rx context 1":0 [ENABLED,IMMUTABLE]
pad3: Source
-> "4500000.ticsi2rx context 2":0 [ENABLED,IMMUTABLE]
pad4: Source
-> "4500000.ticsi2rx context 3":0 [ENABLED,IMMUTABLE]
pad5: Source
-> "4500000.ticsi2rx context 4":0 [ENABLED,IMMUTABLE]
pad6: Source
-> "4500000.ticsi2rx context 5":0 [ENABLED,IMMUTABLE]
pad7: Source
-> "4500000.ticsi2rx context 6":0 [ENABLED,IMMUTABLE]
pad8: Source
-> "4500000.ticsi2rx context 7":0 [ENABLED,IMMUTABLE]
pad9: Source
-> "4500000.ticsi2rx context 8":0 [ENABLED,IMMUTABLE]
pad10: Source
-> "4500000.ticsi2rx context 9":0 [ENABLED,IMMUTABLE]
pad11: Source
-> "4500000.ticsi2rx context 10":0 [ENABLED,IMMUTABLE]
pad12: Source
-> "4500000.ticsi2rx context 11":0 [ENABLED,IMMUTABLE]
pad13: Source
-> "4500000.ticsi2rx context 12":0 [ENABLED,IMMUTABLE]
pad14: Source
-> "4500000.ticsi2rx context 13":0 [ENABLED,IMMUTABLE]
pad15: Source
-> "4500000.ticsi2rx context 14":0 [ENABLED,IMMUTABLE]
pad16: Source
-> "4500000.ticsi2rx context 15":0 [ENABLED,IMMUTABLE]
- entity 19: cdns_csi2rx.4504000.csi-bridge (5 pads, 2 links, 0 route)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Sink
<- "imx219 8-0010":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "4500000.ticsi2rx":0 [ENABLED,IMMUTABLE]
pad2: Source
pad3: Source
pad4: Source
- entity 25: imx219 8-0010 (1 pad, 1 link, 0 route)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev2
pad0: Source
[stream:0 fmt:SBGGR16_1X16/3856x2177 field:none
crop.bounds:(0,0)/0x0
crop:(0,0)/0x0
compose.bounds:(0,0)/0x0
compose:(0,0)/0x0]
-> "cdns_csi2rx.4504000.csi-bridge":0 [ENABLED,IMMUTABLE]
- entity 31: 4500000.ticsi2rx context 0 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video2
pad0: Sink
<- "4500000.ticsi2rx":1 [ENABLED,IMMUTABLE]
- entity 37: 4500000.ticsi2rx context 1 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video3
pad0: Sink
<- "4500000.ticsi2rx":2 [ENABLED,IMMUTABLE]
- entity 43: 4500000.ticsi2rx context 2 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video4
pad0: Sink
<- "4500000.ticsi2rx":3 [ENABLED,IMMUTABLE]
- entity 49: 4500000.ticsi2rx context 3 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video5
pad0: Sink
<- "4500000.ticsi2rx":4 [ENABLED,IMMUTABLE]
- entity 55: 4500000.ticsi2rx context 4 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video6
pad0: Sink
<- "4500000.ticsi2rx":5 [ENABLED,IMMUTABLE]
- entity 61: 4500000.ticsi2rx context 5 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video7
pad0: Sink
<- "4500000.ticsi2rx":6 [ENABLED,IMMUTABLE]
- entity 67: 4500000.ticsi2rx context 6 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video8
pad0: Sink
<- "4500000.ticsi2rx":7 [ENABLED,IMMUTABLE]
- entity 73: 4500000.ticsi2rx context 7 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video9
pad0: Sink
<- "4500000.ticsi2rx":8 [ENABLED,IMMUTABLE]
- entity 79: 4500000.ticsi2rx context 8 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video10
pad0: Sink
<- "4500000.ticsi2rx":9 [ENABLED,IMMUTABLE]
- entity 85: 4500000.ticsi2rx context 9 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video11
pad0: Sink
<- "4500000.ticsi2rx":10 [ENABLED,IMMUTABLE]
- entity 91: 4500000.ticsi2rx context 10 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video12
pad0: Sink
<- "4500000.ticsi2rx":11 [ENABLED,IMMUTABLE]
- entity 97: 4500000.ticsi2rx context 11 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video13
pad0: Sink
<- "4500000.ticsi2rx":12 [ENABLED,IMMUTABLE]
- entity 103: 4500000.ticsi2rx context 12 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video14
pad0: Sink
<- "4500000.ticsi2rx":13 [ENABLED,IMMUTABLE]
- entity 109: 4500000.ticsi2rx context 13 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video15
pad0: Sink
<- "4500000.ticsi2rx":14 [ENABLED,IMMUTABLE]
- entity 115: 4500000.ticsi2rx context 14 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video16
pad0: Sink
<- "4500000.ticsi2rx":15 [ENABLED,IMMUTABLE]
- entity 121: 4500000.ticsi2rx context 15 (1 pad, 1 link, 0 route)
type Node subtype V4L flags 0
device node name /dev/video17
pad0: Sink
<- "4500000.ticsi2rx":16 [ENABLED,IMMUTABLE]
Could I get the logs of the same media-ctl -p as well as the application logs?
Regarding the application log, from the sensor driver, after sending the sensor's out command, it is blocked and no error message is printed.
Customer added print to the ti_csi2rx_DMA_callback function in j721e-csi2rx.c and did not trigger properly.
The MIPI signal on the device have been measured and are transmitting the MIPI signals normally.
Thanks and Regards,
Cherry
Hi Cherry,
Thank you for sharing the media-ctl logs.
Could you also share the command which customer is running to start the stream?
Are they using yavta or v4l2 api to start the stream?
Could you get this command too?
The MIPI signal on the device have been measured and are transmitting the MIPI signals normally
This would be the data sent from the Sensor or the csi rx DPHY MIPI Lane on which the data is seen?
I believe customer is using a single cam IMX219 that is giving an output of RAW16 right?
Regards,
Nikhil
Hi Nikhil,
Could you also share the command which customer is running to start the stream?
Are they using yavta or v4l2 api to start the stream?
They are using the API for v4l2 to start the stream.
It will report an error with yavta:
I believe customer is using a single cam IMX219 that is giving an output of RAW16 right?
Cam uses the imx728, which is achieved by modifying the drive of the imx219. When the customer loads the raw12 configuration of the imx728, the picture can be captured as normal.
This would be the data sent from the Sensor or the csi rx DPHY MIPI Lane on which the data is seen?
It is taken from the sensor via an oscilloscope before it is sent into SK-TDA4VM and the transmit side looks OK.
Also, could you try raw16 reception on your side? If you can get it, the customer will go to figure out their question on transmit side.
Thanks and Regards,
Cherry
Hi Cherry,
Could you please confirm if you had made the change in the struct present in drivers/media/platform/cadence/cdns-csi2rx.c?
static const struct csi2rx_fmt formats[] = {
{
.code = MEDIA_BUS_FMT_YUYV8_2X8,
.bpp = 16,
},
{
.code = MEDIA_BUS_FMT_UYVY8_2X8,
.bpp = 16,
},
{
.code = MEDIA_BUS_FMT_YVYU8_2X8,
.bpp = 16,
},
{
.code = MEDIA_BUS_FMT_VYUY8_2X8,
.
.
.
.
.
could you try raw16 reception on your side?
This is currently not possible at our end as we currently do not have a camera that outputs RAW16. Hence the gap in the driver.
Regards,
Nikhil
Hi Nikhil,
Could you please confirm if you had made the change in the struct present in drivers/media/platform/cadence/cdns-csi2rx.c?
Yes, they've made the correspond changes.
Thanks and Regards,
Cherry
Hi Cherry,
This seems strange. The above changes should have been sufficient to stream RAW16.
Could you please also share the below?
1. Can we get all the logs v4l2-ctl/ application streaming?
2. Start streaming and in another terminal run cat /proc/interrupts. Please provide this logs too. It would give the details of all the interrupt count.
3. Could you confirm what we see in media-ctl -p is their actual setup? i.e, the raw16 sensor directly connected to the csi-rx (without any ser-des).
Regards,
Nikhil