On Tue Oct 1, 2024 at 2:49 PM CEST, Bryan O'Donoghue wrote:
On 01/10/2024 12:39, Luca Weiss wrote:
And v4l-subdev5 is msm_csid0 on my device.
<snip>
- entity 16: msm_csid0 (5 pads, 22 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: Sink [stream:0 fmt:SRGGB10_1X10/4056x3040 field:none colorspace:srgb] <- "msm_csiphy0":1 [] <- "msm_csiphy1":1 [] <- "msm_csiphy2":1 [] <- "msm_csiphy3":1 [] <- "msm_csiphy4":1 [] pad1: Source [stream:0 fmt:SRGGB10_1X10/4056x3040 field:none colorspace:srgb] -> "msm_vfe0_rdi0":0 [ENABLED] -> "msm_vfe1_rdi0":0 [] -> "msm_vfe2_rdi0":0 [] -> "msm_vfe3_rdi0":0 [] -> "msm_vfe4_rdi0":0 []
<snip>
media-ctl --reset yavta --no-query -w '0x009f0903 2' /dev/v4l-subdev5 yavta --list /dev/v4l-subdev5 media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' media-ctl -d /dev/media0 -p
That command list and this
yavta -B capture-mplane -c -I -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video0
should work.
Yeah, unfortunately this is still hanging... Let's also see what Vikram sees on their board.
fairphone-fp5:~$ 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.camss' (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: 3442938648 timestamp type/source: mono/EoF Buffer 0/0 mapped at address 0xffff85e00000. length: 1 offset: 3442938648 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xffff84e08000. length: 1 offset: 3442938648 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xffff83e10000. length: 1 offset: 3442938648 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xffff82e18000. length: 1 offset: 3442938648 timestamp type/source: mono/EoF Buffer 4/0 mapped at address 0xffff81e20000.
I have to test Vladimir's two patches. I'll verify rb5 TPG while I'm at it, perhaps the error is not sdm670 specific.
FWIW this is not sdm670 but sc7280/qcm6490 here :) But I didn't follow the sdm670 thread so maybe you mean something there.
That said last time I tested it, it worked and no changes have gone in, in the meantime.
I also had the test pattern working on a 6.8-based kernel on this device with camss patches from Matti Lehtimäki.
Regards Luca
bod