[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aaa361f7-6ada-4347-8bc6-3820cfc9feb4@linaro.org>
Date: Tue, 28 Oct 2025 12:08:09 +0000
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Luca Weiss <luca.weiss@...rphone.com>,
Krzysztof Kozlowski <krzk@...nel.org>
Cc: Bryan O'Donoghue <bod@...nel.org>, Robert Foss <rfoss@...nel.org>,
Todor Tomov <todor.too@...il.com>,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: media: camss: Add qcom,sm6350-camss
On 28/10/2025 10:28, Luca Weiss wrote:
>> So that's vdda-pll-supply
> Just noticed, this S5A regulator is the MX power-domain, so we cannot
> add it as vdda-pll-supply.
>
> From what I can see, so far no other camss bindings take in an rpmhpd
> power domain, and given it's not referenced in downstream kernel, it
> doesn't look like it's necessary to control it, from camss.
>
> Maybe it should be added to camcc though? Still not quite sure how
> downstream vdd_class should translate to upstream...
>
> Thanks for helping with the other points, those are clear.
>
> Regards
> Luca
Standard practice here is for MX and MMXC in newer parts. MX certain
pertains to the clock-controller in this case.
---
bod
Powered by blists - more mailing lists