We currently do not have an upstream user of the x1e CAMSS schema which
allows us to make this the first platform to treat the CSI PHYs as separate
devices in much the same way as we treat the CCI block as separate devices.
Convert the embedded CSIPHY node data to simple phys = <> removing all of
the PHY specific stuff previously embedded.
I gave some serious thought to making the Test Pattern Generators TPGs into
PHY nodes also but, unlike the CSIPHYs the TPGs have no dedicated external
pins nor regulators.
The CSIPHYs OTOH have dedicated in-fact generally unmuxed pins on Qualcomm
SoCs and each CSIPHY has its own set of input power rails usually 0p8 and
1p2.
Instead of defining the CSIPHYs as children of the CAMSS block, we take the
same approach as the CCI/I2C bus dedicated to CAMSS and define the CSIPHYs
as their own nodes.
Remove the embedded CSIPHY specific data and give CAMSS regular,
bog-standard phys = <>;
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
.../bindings/media/qcom,x1e80100-camss.yaml | 84 ++++++----------------
1 file changed, 20 insertions(+), 64 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
index 9aaed897f7e0e..ff14a8248321e 100644
--- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
@@ -17,7 +17,7 @@ properties:
const: qcom,x1e80100-camss
reg:
- maxItems: 17
+ maxItems: 13
reg-names:
items:
@@ -27,10 +27,6 @@ properties:
- const: csid2
- const: csid_lite0
- const: csid_lite1
- - const: csiphy0
- - const: csiphy1
- - const: csiphy2
- - const: csiphy4
- const: csitpg0
- const: csitpg1
- const: csitpg2
@@ -40,7 +36,7 @@ properties:
- const: vfe_lite1
clocks:
- maxItems: 29
+ maxItems: 21
clock-names:
items:
@@ -55,14 +51,6 @@ properties:
- const: cphy_rx_clk_src
- const: csid
- const: csid_csiphy_rx
- - const: csiphy0
- - const: csiphy0_timer
- - const: csiphy1
- - const: csiphy1_timer
- - const: csiphy2
- - const: csiphy2_timer
- - const: csiphy4
- - const: csiphy4_timer
- const: gcc_axi_hf
- const: gcc_axi_sf
- const: vfe0
@@ -75,7 +63,7 @@ properties:
- const: vfe_lite_csid
interrupts:
- maxItems: 13
+ maxItems: 9
interrupt-names:
items:
@@ -84,15 +72,21 @@ properties:
- const: csid2
- const: csid_lite0
- const: csid_lite1
- - const: csiphy0
- - const: csiphy1
- - const: csiphy2
- - const: csiphy4
- const: vfe0
- const: vfe1
- const: vfe_lite0
- const: vfe_lite1
+ phys:
+ maxItems: 4
+
+ phy-names:
+ items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy4
+
interconnects:
maxItems: 4
@@ -118,14 +112,6 @@ properties:
- const: ife1
- const: top
- vdd-csiphy-0p8-supply:
- description:
- 0.8V supply to a PHY.
-
- vdd-csiphy-1p2-supply:
- description:
- 1.2V supply to a PHY.
-
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -166,13 +152,13 @@ required:
- clock-names
- interrupts
- interrupt-names
+ - phys
+ - phy-names
- interconnects
- interconnect-names
- iommus
- power-domains
- power-domain-names
- - vdd-csiphy-0p8-supply
- - vdd-csiphy-1p2-supply
- ports
additionalProperties: false
@@ -199,10 +185,6 @@ examples:
<0 0x0acbb000 0 0x2000>,
<0 0x0acc6000 0 0x1000>,
<0 0x0acca000 0 0x1000>,
- <0 0x0ace4000 0 0x1000>,
- <0 0x0ace6000 0 0x1000>,
- <0 0x0ace8000 0 0x1000>,
- <0 0x0acec000 0 0x4000>,
<0 0x0acf6000 0 0x1000>,
<0 0x0acf7000 0 0x1000>,
<0 0x0acf8000 0 0x1000>,
@@ -217,10 +199,6 @@ examples:
"csid2",
"csid_lite0",
"csid_lite1",
- "csiphy0",
- "csiphy1",
- "csiphy2",
- "csiphy4",
"csitpg0",
"csitpg1",
"csitpg2",
@@ -240,14 +218,6 @@ examples:
<&camcc CAM_CC_CPHY_RX_CLK_SRC>,
<&camcc CAM_CC_CSID_CLK>,
<&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
- <&camcc CAM_CC_CSIPHY0_CLK>,
- <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
- <&camcc CAM_CC_CSIPHY1_CLK>,
- <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
- <&camcc CAM_CC_CSIPHY2_CLK>,
- <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
- <&camcc CAM_CC_CSIPHY4_CLK>,
- <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
<&gcc GCC_CAMERA_HF_AXI_CLK>,
<&gcc GCC_CAMERA_SF_AXI_CLK>,
<&camcc CAM_CC_IFE_0_CLK>,
@@ -270,14 +240,6 @@ examples:
"cphy_rx_clk_src",
"csid",
"csid_csiphy_rx",
- "csiphy0",
- "csiphy0_timer",
- "csiphy1",
- "csiphy1_timer",
- "csiphy2",
- "csiphy2_timer",
- "csiphy4",
- "csiphy4_timer",
"gcc_axi_hf",
"gcc_axi_sf",
"vfe0",
@@ -294,10 +256,6 @@ examples:
<GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
@@ -308,15 +266,16 @@ examples:
"csid2",
"csid_lite0",
"csid_lite1",
- "csiphy0",
- "csiphy1",
- "csiphy2",
- "csiphy4",
"vfe0",
"vfe1",
"vfe_lite0",
"vfe_lite1";
+ phys = <&csiphy0>, <&csiphy1>,
+ <&csiphy2>, <&csiphy4>;
+ phy-names = "csiphy0", "csiphy1",
+ "csiphy2", "csiphy4";
+
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
<&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
@@ -348,9 +307,6 @@ examples:
"ife1",
"top";
- vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
- vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.52.0Hi Bryan,
On Wed, 2026-02-25 at 15:11 +0000, Bryan O'Donoghue wrote:
> We currently do not have an upstream user of the x1e CAMSS schema which
> allows us to make this the first platform to treat the CSI PHYs as separate
> devices in much the same way as we treat the CCI block as separate devices.
>
> Convert the embedded CSIPHY node data to simple phys = <> removing all of
> the PHY specific stuff previously embedded.
>
> I gave some serious thought to making the Test Pattern Generators TPGs into
> PHY nodes also but, unlike the CSIPHYs the TPGs have no dedicated external
> pins nor regulators.
>
> The CSIPHYs OTOH have dedicated in-fact generally unmuxed pins on Qualcomm
> SoCs and each CSIPHY has its own set of input power rails usually 0p8 and
> 1p2.
>
> Instead of defining the CSIPHYs as children of the CAMSS block, we take the
> same approach as the CCI/I2C bus dedicated to CAMSS and define the CSIPHYs
> as their own nodes.
>
> Remove the embedded CSIPHY specific data and give CAMSS regular,
> bog-standard phys = <>;
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
> ---
> .../bindings/media/qcom,x1e80100-camss.yaml | 84 ++++++----------------
> 1 file changed, 20 insertions(+), 64 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> index 9aaed897f7e0e..ff14a8248321e 100644
> --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> @@ -17,7 +17,7 @@ properties:
> const: qcom,x1e80100-camss
>
> reg:
> - maxItems: 17
> + maxItems: 13
>
> reg-names:
> items:
> @@ -27,10 +27,6 @@ properties:
> - const: csid2
> - const: csid_lite0
> - const: csid_lite1
> - - const: csiphy0
> - - const: csiphy1
> - - const: csiphy2
> - - const: csiphy4
> - const: csitpg0
> - const: csitpg1
> - const: csitpg2
> @@ -40,7 +36,7 @@ properties:
> - const: vfe_lite1
>
> clocks:
> - maxItems: 29
> + maxItems: 21
>
> clock-names:
> items:
> @@ -55,14 +51,6 @@ properties:
> - const: cphy_rx_clk_src
> - const: csid
> - const: csid_csiphy_rx
> - - const: csiphy0
> - - const: csiphy0_timer
> - - const: csiphy1
> - - const: csiphy1_timer
> - - const: csiphy2
> - - const: csiphy2_timer
> - - const: csiphy4
> - - const: csiphy4_timer
> - const: gcc_axi_hf
> - const: gcc_axi_sf
> - const: vfe0
> @@ -75,7 +63,7 @@ properties:
> - const: vfe_lite_csid
>
> interrupts:
> - maxItems: 13
> + maxItems: 9
>
> interrupt-names:
> items:
> @@ -84,15 +72,21 @@ properties:
> - const: csid2
> - const: csid_lite0
> - const: csid_lite1
> - - const: csiphy0
> - - const: csiphy1
> - - const: csiphy2
> - - const: csiphy4
> - const: vfe0
> - const: vfe1
> - const: vfe_lite0
> - const: vfe_lite1
>
> + phys:
> + maxItems: 4
> +
> + phy-names:
> + items:
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy4
> +
> interconnects:
> maxItems: 4
>
> @@ -118,14 +112,6 @@ properties:
> - const: ife1
> - const: top
>
> - vdd-csiphy-0p8-supply:
> - description:
> - 0.8V supply to a PHY.
> -
> - vdd-csiphy-1p2-supply:
> - description:
> - 1.2V supply to a PHY.
> -
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> @@ -166,13 +152,13 @@ required:
> - clock-names
> - interrupts
> - interrupt-names
> + - phys
> + - phy-names
> - interconnects
> - interconnect-names
> - iommus
> - power-domains
> - power-domain-names
> - - vdd-csiphy-0p8-supply
> - - vdd-csiphy-1p2-supply
> - ports
>
> additionalProperties: false
> @@ -199,10 +185,6 @@ examples:
> <0 0x0acbb000 0 0x2000>,
> <0 0x0acc6000 0 0x1000>,
> <0 0x0acca000 0 0x1000>,
> - <0 0x0ace4000 0 0x1000>,
> - <0 0x0ace6000 0 0x1000>,
> - <0 0x0ace8000 0 0x1000>,
> - <0 0x0acec000 0 0x4000>,
> <0 0x0acf6000 0 0x1000>,
> <0 0x0acf7000 0 0x1000>,
> <0 0x0acf8000 0 0x1000>,
> @@ -217,10 +199,6 @@ examples:
> "csid2",
> "csid_lite0",
> "csid_lite1",
> - "csiphy0",
> - "csiphy1",
> - "csiphy2",
> - "csiphy4",
> "csitpg0",
> "csitpg1",
> "csitpg2",
> @@ -240,14 +218,6 @@ examples:
> <&camcc CAM_CC_CPHY_RX_CLK_SRC>,
> <&camcc CAM_CC_CSID_CLK>,
> <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
> - <&camcc CAM_CC_CSIPHY0_CLK>,
> - <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> - <&camcc CAM_CC_CSIPHY1_CLK>,
> - <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
> - <&camcc CAM_CC_CSIPHY2_CLK>,
> - <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
> - <&camcc CAM_CC_CSIPHY4_CLK>,
> - <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
> <&gcc GCC_CAMERA_HF_AXI_CLK>,
> <&gcc GCC_CAMERA_SF_AXI_CLK>,
> <&camcc CAM_CC_IFE_0_CLK>,
> @@ -270,14 +240,6 @@ examples:
> "cphy_rx_clk_src",
> "csid",
> "csid_csiphy_rx",
> - "csiphy0",
> - "csiphy0_timer",
> - "csiphy1",
> - "csiphy1_timer",
> - "csiphy2",
> - "csiphy2_timer",
> - "csiphy4",
> - "csiphy4_timer",
> "gcc_axi_hf",
> "gcc_axi_sf",
> "vfe0",
> @@ -294,10 +256,6 @@ examples:
> <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
> <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
> <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
> - <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
> - <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
> - <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
> - <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
> <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
> <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
> <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
> @@ -308,15 +266,16 @@ examples:
> "csid2",
> "csid_lite0",
> "csid_lite1",
> - "csiphy0",
> - "csiphy1",
> - "csiphy2",
> - "csiphy4",
> "vfe0",
> "vfe1",
> "vfe_lite0",
> "vfe_lite1";
>
> + phys = <&csiphy0>, <&csiphy1>,
> + <&csiphy2>, <&csiphy4>;
> + phy-names = "csiphy0", "csiphy1",
> + "csiphy2", "csiphy4";
> +
> interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
> @@ -348,9 +307,6 @@ examples:
> "ife1",
> "top";
>
> - vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
> - vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
> -
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
On 27/02/2026 23:01, Christopher Obbard wrote: > Hi Bryan, > > On Wed, 2026-02-25 at 15:11 +0000, Bryan O'Donoghue wrote: >> We currently do not have an upstream user of the x1e CAMSS schema which >> allows us to make this the first platform to treat the CSI PHYs as separate >> devices in much the same way as we treat the CCI block as separate devices. >> >> Convert the embedded CSIPHY node data to simple phys = <> removing all of >> the PHY specific stuff previously embedded. >> >> I gave some serious thought to making the Test Pattern Generators TPGs into >> PHY nodes also but, unlike the CSIPHYs the TPGs have no dedicated external >> pins nor regulators. >> >> The CSIPHYs OTOH have dedicated in-fact generally unmuxed pins on Qualcomm >> SoCs and each CSIPHY has its own set of input power rails usually 0p8 and >> 1p2. >> >> Instead of defining the CSIPHYs as children of the CAMSS block, we take the >> same approach as the CCI/I2C bus dedicated to CAMSS and define the CSIPHYs >> as their own nodes. >> >> Remove the embedded CSIPHY specific data and give CAMSS regular, >> bog-standard phys = <>; >> >> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > > Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> This is surprising since I clearly object to these patches and pointed out issues. This is also obsolete version, thus your review will not apply to new one (it's different). Best regards, Krzysztof
On Wed, Feb 25, 2026 at 03:11:19PM +0000, Bryan O'Donoghue wrote: > We currently do not have an upstream user of the x1e CAMSS schema which We have. It is in released kernel v6.16, so almost a year. > allows us to make this the first platform to treat the CSI PHYs as separate No, it does not allow that. You cannto change the ABI. That's why I reminded multiple times before reviewing new CAMSS bindings for Milos and something more. Because once it gets accepted, you cannot change it anymore without valid reason. And there is no valid reason here provided. I kept these patches in staging/waiting for long enough... Best regards, Krzysztof
On 26/02/2026 07:07, Krzysztof Kozlowski wrote: > No, it does not allow that. You cannto change the ABI. > > That's why I reminded multiple times before reviewing new CAMSS bindings > for Milos and something more. Because once it gets accepted, you cannot > change it anymore without valid reason. And there is no valid reason > here provided. I kept these patches in staging/waiting for long > enough... I thought your policy was - a dtsi had to have it, which we don't yet have. --- bod
On 26/02/2026 10:27, Bryan O'Donoghue wrote: > On 26/02/2026 07:07, Krzysztof Kozlowski wrote: >> No, it does not allow that. You cannto change the ABI. >> >> That's why I reminded multiple times before reviewing new CAMSS bindings >> for Milos and something more. Because once it gets accepted, you cannot >> change it anymore without valid reason. And there is no valid reason >> here provided. I kept these patches in staging/waiting for long >> enough... > > I thought your policy was - a dtsi had to have it, which we don't yet have. And from where did you take that policy? I am pretty sure my each comment is about ABI. Heh, I even commented few times about implied ABI purely based on kernel, without DTS. Best regards, Krzysztof
On 26/02/2026 09:33, Krzysztof Kozlowski wrote: > On 26/02/2026 10:27, Bryan O'Donoghue wrote: >> On 26/02/2026 07:07, Krzysztof Kozlowski wrote: >>> No, it does not allow that. You cannto change the ABI. >>> >>> That's why I reminded multiple times before reviewing new CAMSS bindings >>> for Milos and something more. Because once it gets accepted, you cannot >>> change it anymore without valid reason. And there is no valid reason >>> here provided. I kept these patches in staging/waiting for long >>> enough... >> >> I thought your policy was - a dtsi had to have it, which we don't yet have. > > And from where did you take that policy? I am pretty sure my each > comment is about ABI. Heh, I even commented few times about implied ABI > purely based on kernel, without DTS. Correct me if I'm wrong. I thought we had discussed either @ the Linaro Dublin meet or the Linaro Amsterdam meet that changing upstream YAML would be feasible _if_ you could show there was no dependency on it - say u-boot, FreeBSD etc. I completely understand why you'd say for a UART definition its an ABI since quite likely another OS might consume the YAML but, I also think nobody but upstream Linux cares about this binding at all and our only actual user is upstream dtsi in Linux, which doesn't exist yet. --- bod
On 26/02/2026 10:40, Bryan O'Donoghue wrote: > On 26/02/2026 09:33, Krzysztof Kozlowski wrote: >> On 26/02/2026 10:27, Bryan O'Donoghue wrote: >>> On 26/02/2026 07:07, Krzysztof Kozlowski wrote: >>>> No, it does not allow that. You cannto change the ABI. >>>> >>>> That's why I reminded multiple times before reviewing new CAMSS bindings >>>> for Milos and something more. Because once it gets accepted, you cannot >>>> change it anymore without valid reason. And there is no valid reason >>>> here provided. I kept these patches in staging/waiting for long >>>> enough... >>> >>> I thought your policy was - a dtsi had to have it, which we don't yet have. >> >> And from where did you take that policy? I am pretty sure my each >> comment is about ABI. Heh, I even commented few times about implied ABI >> purely based on kernel, without DTS. > > Correct me if I'm wrong. I thought we had discussed either @ the Linaro > Dublin meet or the Linaro Amsterdam meet that changing upstream YAML > would be feasible _if_ you could show there was no dependency on it - > say u-boot, FreeBSD etc. And I mentioned multiple caveats and restrictions. Do you quote them here or just took the first part of sentence before ", but only ..."? Anyway, whatever spoken is improvable and I am sure I did not give such permissions, maybe except that Dublin meeting was in 2024 thus before the release of previous user, so before v6.16, so of course you can still reshape unreleased ABI. And then you released it closing the discussion. > > I completely understand why you'd say for a UART definition its an ABI > since quite likely another OS might consume the YAML but, I also think > nobody but upstream Linux cares about this binding at all and our only > actual user is upstream dtsi in Linux, which doesn't exist yet. Half of the comments responding to DT maintainers are "but no one cares". Well, I do care, so that's it. If I start analyzing each case for possible exceptions I would spend too much time on it. So follow documented and expressed in written rules. Best regards, Krzysztof
On 26/02/2026 09:50, Krzysztof Kozlowski wrote:
> On 26/02/2026 10:40, Bryan O'Donoghue wrote:
>> On 26/02/2026 09:33, Krzysztof Kozlowski wrote:
>>> On 26/02/2026 10:27, Bryan O'Donoghue wrote:
>>>> On 26/02/2026 07:07, Krzysztof Kozlowski wrote:
>>>>> No, it does not allow that. You cannto change the ABI.
>>>>>
>>>>> That's why I reminded multiple times before reviewing new CAMSS bindings
>>>>> for Milos and something more. Because once it gets accepted, you cannot
>>>>> change it anymore without valid reason. And there is no valid reason
>>>>> here provided. I kept these patches in staging/waiting for long
>>>>> enough...
>>>>
>>>> I thought your policy was - a dtsi had to have it, which we don't yet have.
>>>
>>> And from where did you take that policy? I am pretty sure my each
>>> comment is about ABI. Heh, I even commented few times about implied ABI
>>> purely based on kernel, without DTS.
>>
>> Correct me if I'm wrong. I thought we had discussed either @ the Linaro
>> Dublin meet or the Linaro Amsterdam meet that changing upstream YAML
>> would be feasible _if_ you could show there was no dependency on it -
>> say u-boot, FreeBSD etc.
>
> And I mentioned multiple caveats and restrictions. Do you quote them
> here or just took the first part of sentence before ", but only ..."?
>
> Anyway, whatever spoken is improvable and I am sure I did not give such
> permissions, maybe except that Dublin meeting was in 2024 thus before
> the release of previous user, so before v6.16, so of course you can
> still reshape unreleased ABI. And then you released it closing the
> discussion.
Well, is there a way to support both then ?
Right now I have csiphy and their registers listed in the camss block.
I could add phys = <> as optional in the schema. Is there any reason to
stop adding adjacent csiphy nodes ?
isp@addr {
regs = 0xCSID0,
0xCSIPH1;
reg-names = "csidX",
"csiphy0";
};
csiphy@CSIPHY1 {}
I'm not sure if this is against DT rules.
The iommu items _should_ be fine as its maxItems so I can just set that
to five instead of eight in the dtsi.
---
bod
On 26/02/2026 11:06, Bryan O'Donoghue wrote:
> On 26/02/2026 09:50, Krzysztof Kozlowski wrote:
>> On 26/02/2026 10:40, Bryan O'Donoghue wrote:
>>> On 26/02/2026 09:33, Krzysztof Kozlowski wrote:
>>>> On 26/02/2026 10:27, Bryan O'Donoghue wrote:
>>>>> On 26/02/2026 07:07, Krzysztof Kozlowski wrote:
>>>>>> No, it does not allow that. You cannto change the ABI.
>>>>>>
>>>>>> That's why I reminded multiple times before reviewing new CAMSS bindings
>>>>>> for Milos and something more. Because once it gets accepted, you cannot
>>>>>> change it anymore without valid reason. And there is no valid reason
>>>>>> here provided. I kept these patches in staging/waiting for long
>>>>>> enough...
>>>>>
>>>>> I thought your policy was - a dtsi had to have it, which we don't yet have.
>>>>
>>>> And from where did you take that policy? I am pretty sure my each
>>>> comment is about ABI. Heh, I even commented few times about implied ABI
>>>> purely based on kernel, without DTS.
>>>
>>> Correct me if I'm wrong. I thought we had discussed either @ the Linaro
>>> Dublin meet or the Linaro Amsterdam meet that changing upstream YAML
>>> would be feasible _if_ you could show there was no dependency on it -
>>> say u-boot, FreeBSD etc.
>>
>> And I mentioned multiple caveats and restrictions. Do you quote them
>> here or just took the first part of sentence before ", but only ..."?
>>
>> Anyway, whatever spoken is improvable and I am sure I did not give such
>> permissions, maybe except that Dublin meeting was in 2024 thus before
>> the release of previous user, so before v6.16, so of course you can
>> still reshape unreleased ABI. And then you released it closing the
>> discussion.
> Well, is there a way to support both then ?
I would just not touch x1e80100, but if you want then probably binding
should stay backwards compatible, where you keep all properties intact
and only add csiphy nodes.
>
> Right now I have csiphy and their registers listed in the camss block.
>
> I could add phys = <> as optional in the schema. Is there any reason to
> stop adding adjacent csiphy nodes ?
I think no.
>
> isp@addr {
> regs = 0xCSID0,
> 0xCSIPH1;
> reg-names = "csidX",
> "csiphy0";
> };
>
> csiphy@CSIPHY1 {}
>
> I'm not sure if this is against DT rules.
>
> The iommu items _should_ be fine as its maxItems so I can just set that
> to five instead of eight in the dtsi.
>
> ---
> bod
Best regards,
Krzysztof
On 27/02/2026 07:24, Krzysztof Kozlowski wrote: >> Well, is there a way to support both then ? > I would just not touch x1e80100, but if you want then probably binding > should stay backwards compatible, where you keep all properties intact > and only add csiphy nodes. > I really want to stop adding new stuff with the legacy way that has broken power-rails, even if that means x1e has a bit Frankenstein binding. >> Right now I have csiphy and their registers listed in the camss block. >> >> I could add phys = <> as optional in the schema. Is there any reason to >> stop adding adjacent csiphy nodes ? > I think no. Great so, that's what I'll do. --- bod
On Fri, Feb 27, 2026 at 08:48:45AM +0000, Bryan O'Donoghue wrote: > On 27/02/2026 07:24, Krzysztof Kozlowski wrote: > > > Well, is there a way to support both then ? > > I would just not touch x1e80100, but if you want then probably binding > > should stay backwards compatible, where you keep all properties intact > > and only add csiphy nodes. > > > > I really want to stop adding new stuff with the legacy way that has broken > power-rails, even if that means x1e has a bit Frankenstein binding. X1 is fine. Please thing of a migration path for the older platforms too. > > > > Right now I have csiphy and their registers listed in the camss block. > > > > > > I could add phys = <> as optional in the schema. Is there any reason to > > > stop adding adjacent csiphy nodes ? > > I think no. > > Great so, that's what I'll do. > > --- > bod -- With best wishes Dmitry
On 27/02/2026 20:10, Dmitry Baryshkov wrote: > On Fri, Feb 27, 2026 at 08:48:45AM +0000, Bryan O'Donoghue wrote: >> On 27/02/2026 07:24, Krzysztof Kozlowski wrote: >>>> Well, is there a way to support both then ? >>> I would just not touch x1e80100, but if you want then probably binding >>> should stay backwards compatible, where you keep all properties intact >>> and only add csiphy nodes. >>> >> >> I really want to stop adding new stuff with the legacy way that has broken >> power-rails, even if that means x1e has a bit Frankenstein binding. > > X1 is fine. Please thing of a migration path for the older platforms > too. Yeah no we're very much singing from the same hymn sheet here. As I told you elsewhere but its worth stating for the internet machine, I thought "put the CSIPHY at the same scope as the CCI" and am not wedded to the choice between sub-nodes of CAMSS or peer nodes to CAMSS aside from the above statement. Being able to move older platforms with already fixed schema to the new CSIPHY driver hadn't really occured to me but, since you raise it, I think its worth trying to support. I will alloc(cycles); --- bod
© 2016 - 2026 Red Hat, Inc.