linux-kernel - Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-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: <97e4f888-1ed7-4d82-b972-3e0b95610198@linaro.org>
Date: Thu, 12 Sep 2024 16:11:58 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Depeng Shao <quic_depengs@...cinc.com>, rfoss@...nel.org,
 todor.too@...il.com, mchehab@...nel.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org,
 Neil Armstrong <neil.armstrong@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel@...cinc.com, Yongsheng Li <quic_yon@...cinc.com>
Subject: Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss
 binding

On 12/09/2024 13:44, Vladimir Zapolskiy wrote:
>> csiphy0
>>
>> vdda-phy-supply = <&vreg_l2c_0p9>;
>> vdda-pll-supply = <&vreg_l1c_1p2>;
>>
>> This is also the case for csiphy 1/2/4
>>
>> So, I _don't_ believe this is work we need to do, since its the same
>> regulator for each PHY.
> 
> This is board specific, and even if the separation is not needed on the 
> boards
> you have just checked, still it may be needed on some boards, which are 
> not yet
> checked/not yet known.

There is a Power Grid Analysis document which specifies these rails @ 
the SoC level and assumes you've used the Qcom PMIC to power, moreover 
the PGA re-uses the same regulator over and over again.

You _could_ provide that power from your own PMIC which provides the 
same voltage range as the Qcom PMIC you haven't used. Even if you did 
provide that from your own PMIC you'd have to provide _separate_ rails 
for the various CSIPHYs before it would be required to have a per PHY 
rail requirement on this SoC.

Are people really powering these SoCs with their own PMICs ?
No probably not.

Should we add the support for it anyway ?
Maybe.

So to reiterate:

1. csiphyX-vdda-phy-supply
    csiphyX-vdda-pll-supply

    In the dts and yaml

    => The names should be generic from the perspective of the driver

2. camss.c::csiphy_res_sm8550
    [0].regulators = { "csiphy0-vdda-phy-supply",
                       "csiphy0-vdda-pll-supply" }
    ...

    [N].regulators = { "csiphyN-vdda-phy-supply",
                       "csiphyN-vdda-pll-supply" }

    => The regulators for the PHY should be defined in the
       PHY resources description

3. Required not optional in the yaml

    => You can't use the PHY without its regulators

---
bod