[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ddea072c-c495-4414-a497-a2851211934e@kernel.org>
Date: Sun, 13 Jul 2025 10:28:29 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Bjorn Andersson <andersson@...nel.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Robert Foss <rfoss@...nel.org>,
Todor Tomov <todor.too@...il.com>, Mauro Carvalho Chehab
<mchehab@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org
Subject: Re: [PATCH v7 08/15] arm64: dts: qcom: x1e80100: Add MIPI CSI PHY
nodes
On 11/07/2025 14:58, Bryan O'Donoghue wrote:
> Add csiphy nodes for
>
> - csiphy0
> - csiphy1
> - csiphy2
> - csiphy4
>
> The irregular naming of the PHYs comes directly from the hardware which for
> whatever reason skipped csiphy3.
>
> Separating the nodes from CAMSS as we have done with the sensor I2C bus aka
> the CCI interface is justified since the CSIPHYs have their own pinouts and
> voltage rails.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> ---
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 88 ++++++++++++++++++++++++++++++++++
> 1 file changed, 88 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> index 41245e8592f78edf141141f2f5b7c5b841318f46..e385d6f329616360e089ba352be450c9eca6aab6 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> @@ -5244,6 +5244,94 @@ cci1_i2c1: i2c-bus@1 {
> };
> };
>
> + csiphy0: csiphy@...4000 {
phy@
git grep csi.*phy@
git grep phy@
> + compatible = "qcom,x1e80100-mipi-csi2-combo-phy";
You should clearly express where the bindings are. I see only short
remark about some driver in v7 changelog, but you have here a weak
dependency, because this should not be accepted before the bindings
reach their maintainer and qcom maintainers need to be able to check on
that.
Best regards,
Krzysztof
Powered by blists - more mailing lists