linux-kernel - Re: [PATCH v14 2/2] arm64: dts: qcom: qcs6490-rb3gen2-vision-mezzanine: Add vision mezzanine

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] [day] [month] [year] [list]

Message-ID: <b3203de4-e888-41e2-80bd-0d60fb8c520e@quicinc.com>
Date: Wed, 5 Mar 2025 18:15:11 +0530
From: Vikram Sharma <quic_vikramsa@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Jorge Ramirez
	<jorge.ramirez@....qualcomm.com>,
        Krzysztof Kozlowski <krzk@...nel.org>
CC: <rfoss@...nel.org>, <todor.too@...il.com>, <mchehab@...nel.org>,
        <robh@...nel.org>, <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
        <andersson@...nel.org>, <konradybcio@...nel.org>,
        <hverkuil-cisco@...all.nl>, <cros-qcom-dts-watchers@...omium.org>,
        <catalin.marinas@....com>, <will@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-media@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Konrad Dybcio
	<konrad.dybcio@...aro.org>
Subject: Re: [PATCH v14 2/2] arm64: dts: qcom:
 qcs6490-rb3gen2-vision-mezzanine: Add vision mezzanine


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