On 3/4/2025 3:17 PM, Bryan O'Donoghue wrote:
On 04/03/2025 08:51, Jorge Ramirez wrote:
On 04/03/25 09:40:21, Krzysztof Kozlowski wrote:
On 04/03/2025 09:36, Jorge Ramirez wrote:
On 03/03/25 18:13:20, Krzysztof Kozlowski wrote:
On 08/02/2025 23:51, Vikram Sharma wrote:
The Vision Mezzanine for the Qualcomm RB3 Gen 2 ships with an imx577
camera sensor. Enable IMX577 on the vision mezzanine.
An example media-ctl pipeline for the imx577 is:
media-ctl --reset
media-ctl -V '"imx577 '17-001a'":0[fmt:SRGGB10/4056x3040
field:none]'
AFAIU, camss does not support SRGGB10, but only SRGGB10P.
Based on tests reported on IRC I think this might not have been
tested
correctly.
Hi everyone,
Thank you for your comments and discussion on this thread.
I can confirm that I have verified this implementation using the same
steps mentioned in the commit text.
Here is the sample output.
yavta -B capture-mplane -c -I -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video0
Device /dev/video0 opened.
Device `Qualcomm Camera Subsystem' on `platform:acb3000.isp' (driver
'qcom-camss') supports video, capture, with mplanes.
Video format set: SRGGB10P (41415270) 4056x3040 field none, 1 planes:
* Stride 5072, buffer size 15418880
Video format: SRGGB10P (41415270) 4056x3040 field none, 1 planes:
* Stride 5072, buffer size 15418880
5 buffers requested.
length: 1 offset: 3791353960 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xffff7eb7b000.
length: 1 offset: 3791353960 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0xffff7dcc6000.
length: 1 offset: 3791353960 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0xffff7ce11000.
length: 1 offset: 3791353960 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0xffff7bf5c000.
length: 1 offset: 3791353960 timestamp type/source: mono/EoF
Buffer 4/0 mapped at address 0xffff7b0a7000.
0 (0) [-] none 0 15418880 B 114.742722 114.744108 20.839 fps ts mono/EoF
1 (1) [-] none 1 15418880 B 114.775069 114.775932 30.915 fps ts mono/EoF
2 (2) [-] none 2 15418880 B 114.808401 114.886861 30.001 fps ts mono/EoF
3 (3) [-] none 3 15418880 B 114.841923 114.899629 29.831 fps ts mono/EoF
4 (4) [-] none 4 15418880 B 114.875247 114.949205 30.008 fps ts mono/EoF
5 (0) [-] none 5 15418880 B 114.908511 114.963073 30.063 fps ts mono/EoF
6 (1) [-] none 6 15418880 B 114.941727 114.997570 30.106 fps ts mono/EoF
7 (2) [-] none 7 15418880 B 114.975066 115.011758 29.995 fps ts mono/EoF
8 (3) [-] none 8 15418880 B 115.008486 115.047468 29.922 fps ts mono/EoF
9 (4) [-] none 9 15418880 B 115.041750 115.060305 30.063 fps ts mono/EoF
10 (0) [-] none 10 15418880 B 115.075060 115.106941 30.021 fps ts mono/EoF
...
Best Regards,
Vikram
I acquired SRGGB10P (10 bit packed) frames from the camera despite the
pipeline being set to SRGGB10 (16 bit) samples.
so something does not add up.
Then the commands are actually correct, just the camss or media behave
here a bit unexpected?
setting the pipeline (CSI) as SRGGB10 (16 bit samples) as per below
media-ctl --reset
media-ctl -v -V '"imx577 '19-001a'":0[fmt:SRGGB10/4056x3040 field:none]'
media-ctl -V '"msm_csiphy3":0[fmt:SRGGB10/4056x3040]'
media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]'
media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]'
media-ctl -l '"msm_csiphy3":1->"msm_csid0":0[1]'
media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
allows to capture SRGGB10P samples (frames-xxxx.bin files contain 10
bit samples for the size)
==> yavta -B capture-mplane -c -I -n 5 -f SRGGB10P -s 4056x3040 -F
/dev/video0
shouldnt the CSI need to be set to SRGGB10P instead?
Best regards,
Krzysztof
No an internal media bus format MEDIA_BUS_FMT_THING is used
See
87889f1b7ea40d2544b49c62092e6ef2792dced7
5480b0c67f120a6c293cc5eff72fa1d6a74de504
3c1dfb5a69cf836f513a2a49113ee946a4b9d95d
Yavta is specifying a v4l2 pixel format SRGGB10P which then gets
translated into a media bus format MEDIA_BUS_FMT_SRGGB10_1X10.
I'm not sure what the historical reasons for that are, probably good
ones.
---
bod
