linux-kernel - Re: [PATCH 00/10] (no cover subject)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D4KJCLCDGQ96.251XO3OG6DVB6@fairphone.com>
Date: Tue, 01 Oct 2024 16:22:50 +0200
From: "Luca Weiss" <luca.weiss@...rphone.com>
To: "Bryan O'Donoghue" <bryan.odonoghue@...aro.org>, "Vikram Sharma"
 <quic_vikramsa@...cinc.com>, "Robert Foss" <rfoss@...nel.org>, "Todor
 Tomov" <todor.too@...il.com>, "Mauro Carvalho Chehab" <mchehab@...nel.org>,
 "Rob Herring" <robh@...nel.org>, "Krzysztof Kozlowski"
 <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>, "Kapatrala
 Syed" <akapatra@...cinc.com>, "Hariram Purushothaman"
 <hariramp@...cinc.com>, "Bjorn Andersson" <andersson@...nel.org>, "Konrad
 Dybcio" <konradybcio@...nel.org>, "Hans Verkuil"
 <hverkuil-cisco@...all.nl>, <cros-qcom-dts-watchers@...omium.org>, "Catalin
 Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 Matti Lehtimäki <matti.lehtimaki@...il.com>
Cc: <linux-arm-msm@...r.kernel.org>, <linux-media@...r.kernel.org>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-arm-kernel@...ts.infradead.org>, "Suresh Vankadara"
 <quic_svankada@...cinc.com>, "Trishansh Bhardwaj"
 <quic_tbhardwa@...cinc.com>, <stable@...r.kernel.org>, "Hariram
 Purushothaman" <quic_hariramp@...cinc.com>
Subject: Re: [PATCH 00/10] (no cover subject)

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