linux-kernel - Re: [PATCH v5 4/6] media: qcom: camss: Add sc8280xp resource details

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: <9a13471b-fc39-4081-8905-9d0d7c28b501@linaro.org>
Date:   Mon, 13 Nov 2023 12:17:34 +0000
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>, hverkuil-cisco@...all.nl,
        laurent.pinchart@...asonboard.com, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Robert Foss <rfoss@...nel.org>,
        Todor Tomov <todor.too@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, vincent.knecht@...loo.org,
        matti.lehtimaki@...il.com, quic_grosikop@...cinc.com
Cc:     linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 4/6] media: qcom: camss: Add sc8280xp resource details

On 13/11/2023 11:57, Konrad Dybcio wrote:
> On 10.11.2023 02:04, Bryan O'Donoghue wrote:
>> This commit describes the hardware layout for the sc8280xp for the
>> following hardware blocks:
>>
>> - 4 x VFE, 4 RDI per VFE
>> - 4 x VFE Lite, 4 RDI per VFE
>> - 4 x CSID
>> - 4 x CSID Lite
>> - 4 x CSI PHY
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
>> ---
> [...]
> 
>> +static const struct camss_subdev_resources vfe_res_sc8280xp[] = {
>> +	/* IFE0 */
>> +	{
>> +		.regulators = {},
>> +		.clock = { "gcc_axi_hf", "gcc_axi_sf", "cpas_ahb", "camnoc_axi", "vfe0", "vfe0_axi" },
>> +		.clock_rate = { { 0 },
>> +				{ 0 },
>> +				{ 19200000, 80000000},
>> +				{ 19200000, 150000000, 266666667, 320000000, 400000000, 480000000 },
>> +				{ 400000000, 558000000, 637000000, 760000000 },
>> +				{ 0 }, },
>> +		.reg = { "vfe0" },
>> +		.interrupt = { "vfe0" },
>> +		.pd_name = "ife0",
> So, the comments before each array member, the reg/intr and pd names
> are all over the place between IFE and VFE.. Is there a reason to this?

So what we have is older VFE - video front end, IFE - image front end 
and SFE - Sensor Front End, which do different things -> VFE raw, IFE 
pixel processing i.e. hw accel processing and SFE - sensor specific 
stuff I'm not across the detail of.

For our purposes in CAMSS => delivering simple bayer to user-space at 
the moment VFE = IFE = SFE.

We could rename vfe -> xfe but then again the presupposes the next 
iteration of this hardware block's name != xfe.

I do not believe there is a namespace deliniation for power-domains 
between 'stock' VFE and IFE.

The PD name in qcom namespace is 'IFE' the existing upstream code VFE 
but the capabilities we support are basically VFE, for now anyway.

> On top of that, another ideas to add onto your cleanup stack:
> 
> - Are VFEs within a CAMSS block actually different? Can we just do "vfe
>    data" and "vfe number" + "vfe_lite data" & "vfe_lite number"?

Yes.

The last VFE in sm8250 is "pix" capable. VFE Lite is not individually 
power collapsible and I'm quite sure if you start trying to "push" more 
advanced features Lite unsurprisingly has fewer..

> - Should we move these platform structs into separate files?

Yes. I'm aware of a group working on this and anticipate their patches soon.

> - Reminder about the clk_bulk_enable for clk_rate=0 clocks suggestion
> 
> - OPP

There's a Jira ticket in Linaro's system for this if you look..

> - Use _num instead of sentinels and magic scary while (not null)

---
bod