linux-kernel - Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding

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: <62a3f09b-50d6-4ace-8229-d71585378ae1@oss.qualcomm.com>
Date: Wed, 15 Oct 2025 20:46:42 -0700
From: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
        Loic Poulain <loic.poulain@....qualcomm.com>,
        Robert Foss
 <rfoss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, Todor Tomov <todor.too@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: linux-i2c@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, aiqun.yu@....qualcomm.com,
        tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com,
        yijie.yang@....qualcomm.com,
        Jingyi Wang <jingyi.wang@....qualcomm.com>,
        Atiya Kailany <atiya.kailany@....qualcomm.com>
Subject: Re: [PATCH v2 2/6] dt-bindings: media: camss: Add
 qcom,kaanapali-camss binding


On 10/15/2025 4:32 PM, Vladimir Zapolskiy wrote:
> On 10/16/25 00:43, Bryan O'Donoghue wrote:
>> On 15/10/2025 20:45, Vladimir Zapolskiy wrote:
>>>> +  power-domains:
>>>> +    items:
>>>> +      - description:
>>>> +          TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> +      - description:
>>>> +          TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> +      - description:
>>>> +          TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> +      - description:
>>>> +          Titan GDSC - Titan ISP Block Global Distributed Switch
>>>> Controller.
>>>> +
>>>> +  power-domain-names:
>>>> +    items:
>>>> +      - const: tfe0
>>>> +      - const: tfe1
>>>> +      - const: tfe2
>>>
>>> Please remove all 'tfeX' power domains, they are not going to be 
>>> utilized
>>> any time soon.
>>>
>>> When 'power-domains' list is just a single Titan GDSC, 
>>> 'power-domain-names'
>>> property is not needed.
>>
>> Each one of these TFEs powers an individually power-collapsible TFEs.
>>
>> This is also so with the other xFE power-domains on previous SoC
>> generations.
>
> This is false, for instance there is no management of SFEx power domains
> in SM8550 or X1E80100 CAMSS in the upstrem, neither there is no 
> management
> of SBI, IPE, BPS, CPP and so on GDSC power domans given by CAMCCs.
>
> TFEx is no more special, if it's unused, then it should not be added.
I agree with Bryan, if I understood the original comment correctly. This 
is no different to the IFE0/1/2 GDSCs on SM8550. All the other modules 
listed above (SFE, IPE, BPS etc.) are not supported by the CAMSS driver 
and hence there is no management. However, we need to manage the TOP and 
TFE0/1/2 GDSCs for the real time RDI paths.
>
>
>>
>> You'll need the TFEx power-domain to process any data on TFEx with the
>> 'lite' versions being tied to the TOP GDSC.
>
> When it is needed, the documentation will be updated accordingly, 
> right now
> it is unknown what a data processing on TFEx looks like, it might happen
> that there will be separate device tree nodes for TFEx.
>
> TFEx power domains shall be removed right now, unti; a usecase in the 
> upstream
> CAMSS appears to use them, I haven't seen such code at the moment.
>
We attach these power power domains by name in the corresponding driver. 
For instance, the VFE driver attaches the TFE power domains mentioned 
here and are exercised from vfe_set_power() -> vfe_get() 
->vfe_pm_domain_on(). You can also see the related codes with '.has_pd' 
and '.pd_name' properties in the CAMSS subdev resource structures. Hope 
this clarifies.