[PATCH 00/10] (no cover subject)

[Luca Weiss]

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