| Message ID | 20250314-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v6-2-edcb2cfc3122@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Add dt-bindings and dtsi changes for CAMSS on x1e80100 silicon | expand |
On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >> + vdd-csiphy-0p8-supply: > Same comment as other series on the lists - this is wrong name. There > are no pins named like this and all existing bindings use different name. The existing bindings are unfortunately not granular enough. I'll post s series to capture pin-names per the SoC pinout shortly. --- bod
On 24/04/2025 11:07, Krzysztof Kozlowski wrote: > On 24/04/2025 11:34, Bryan O'Donoghue wrote: >> On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >>>> + vdd-csiphy-0p8-supply: >>> Same comment as other series on the lists - this is wrong name. There >>> are no pins named like this and all existing bindings use different name. >> >> The existing bindings are unfortunately not granular enough. >> >> I'll post s series to capture pin-names per the SoC pinout shortly. > How are the pins/supplies actually called? > > Best regards, > Krzysztof I don't think strictly algning to pin-names is what we want. Here are the input pins VDD_A_CSI_0_1_1P2 VDD_A_CSI_2_4_1P2 VDD_A_CSI_0_1_0P9 VDD_A_CSI_2_4_0P9 I think the right way to represent this yaml: csiphy0-1p2-supply csiphy1-1p2-supply csiphy2-1p2-supply csiphy3-1p2-supply dts: vdd-csiphy0-0p9-supply = <&vreg_l2c_0p8>; vdd-csiphy1-0p9-supply = <&vreg_l2c_0p8>; etc vdda-csiphy0-1p2-supply = <&vreg_l1c_1p2>; because that captures the fact we could have separate lines for each phy, names it generically and then leaves it up to the dts implementation to represent what actually happened on the PCB. That would also work for qcm2290 and sm8650. https://lore.kernel.org/linux-arm-msm/20250423221954.1926453-2-vladimir.zapolskiy@linaro.org/ So for sm8650 instead of + vdda-csi01-0p9-supply: + + vdda-csi24-0p9-supply: + + vdda-csi35-0p9-supply: + + vdda-csi01-1p2-supply: + + vdda-csi24-1p2-supply: + + vdda-csi35-1p2-supply: you would have + vdda-csiphy0-0p9-supply: + + vdda-csiphy1-0p9-supply: + vdda-csiphy0-1p2-supply: + + vdda-csiphy1-1p2-supply: Which would then be consistent across SoCs for as long as 0p9 and 1p2 are the power-domains used by these PHYs. --- bod
On Thu, Apr 24, 2025 at 11:17:13AM +0100, Bryan O'Donoghue wrote: > On 24/04/2025 11:07, Krzysztof Kozlowski wrote: > > On 24/04/2025 11:34, Bryan O'Donoghue wrote: > > > On 24/04/2025 07:40, Krzysztof Kozlowski wrote: > > > > > + vdd-csiphy-0p8-supply: > > > > Same comment as other series on the lists - this is wrong name. There > > > > are no pins named like this and all existing bindings use different name. > > > > > > The existing bindings are unfortunately not granular enough. > > > > > > I'll post s series to capture pin-names per the SoC pinout shortly. > > How are the pins/supplies actually called? > > > > Best regards, > > Krzysztof > > I don't think strictly algning to pin-names is what we want. > > Here are the input pins > > VDD_A_CSI_0_1_1P2 > VDD_A_CSI_2_4_1P2 > VDD_A_CSI_0_1_0P9 > VDD_A_CSI_2_4_0P9 > > I think the right way to represent this > > yaml: > csiphy0-1p2-supply > csiphy1-1p2-supply > csiphy2-1p2-supply > csiphy3-1p2-supply > > dts: > > vdd-csiphy0-0p9-supply = <&vreg_l2c_0p8>; > vdd-csiphy1-0p9-supply = <&vreg_l2c_0p8>; > > etc > > vdda-csiphy0-1p2-supply = <&vreg_l1c_1p2>; > > because that captures the fact we could have separate lines for each phy, > names it generically and then leaves it up to the dts implementation to > represent what actually happened on the PCB. > > That would also work for qcm2290 and sm8650. > > https://lore.kernel.org/linux-arm-msm/20250423221954.1926453-2-vladimir.zapolskiy@linaro.org/ > > So for sm8650 instead of > > + vdda-csi01-0p9-supply: > + > + vdda-csi24-0p9-supply: > + > + vdda-csi35-0p9-supply: > + > + vdda-csi01-1p2-supply: > + > + vdda-csi24-1p2-supply: > + > + vdda-csi35-1p2-supply: > > you would have > > + vdda-csiphy0-0p9-supply: > + > + vdda-csiphy1-0p9-supply: > > + vdda-csiphy0-1p2-supply: > + > + vdda-csiphy1-1p2-supply: > > Which would then be consistent across SoCs for as long as 0p9 and 1p2 are > the power-domains used by these PHYs. This won't be consistent with other cases where we have a shared power pin. For example, for PMICs we provide supply names which match pin names rather than one-supply-per-LDO.
Krzysztof, On 4/24/25 13:07, Krzysztof Kozlowski wrote: > On 24/04/2025 11:34, Bryan O'Donoghue wrote: >> On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >>>> + vdd-csiphy-0p8-supply: >>> Same comment as other series on the lists - this is wrong name. There >>> are no pins named like this and all existing bindings use different name. >> >> The existing bindings are unfortunately not granular enough. >> >> I'll post s series to capture pin-names per the SoC pinout shortly. > How are the pins/supplies actually called? > concerning it I would appreciate if you can review/comment the v2 of SM8650 CAMSS dt bindings I've just sent recently [1], the equivalent property names on that platform were named "vdda-csiXY-0p9-supply" for VDD_A_CSI_X_Y_0P9 pin. I believe both these platforms and likely the following ones should provide similar properties, thus it makes sense to discuss it at the same time. [1] https://lore.kernel.org/linux-arm-msm/20250423221954.1926453-2-vladimir.zapolskiy@linaro.org/ -- Best wishes, Vladimir
On 4/24/25 13:17, Bryan O'Donoghue wrote: > On 24/04/2025 11:07, Krzysztof Kozlowski wrote: >> On 24/04/2025 11:34, Bryan O'Donoghue wrote: >>> On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >>>>> + vdd-csiphy-0p8-supply: >>>> Same comment as other series on the lists - this is wrong name. There >>>> are no pins named like this and all existing bindings use different name. >>> >>> The existing bindings are unfortunately not granular enough. >>> >>> I'll post s series to capture pin-names per the SoC pinout shortly. >> How are the pins/supplies actually called? >> >> Best regards, >> Krzysztof > > I don't think strictly algning to pin-names is what we want. > > Here are the input pins > > VDD_A_CSI_0_1_1P2 > VDD_A_CSI_2_4_1P2 > VDD_A_CSI_0_1_0P9 > VDD_A_CSI_2_4_0P9 > > I think the right way to represent this > > yaml: > csiphy0-1p2-supply > csiphy1-1p2-supply > csiphy2-1p2-supply > csiphy3-1p2-supply > > dts: > > vdd-csiphy0-0p9-supply = <&vreg_l2c_0p8>; > vdd-csiphy1-0p9-supply = <&vreg_l2c_0p8>; > > etc > > vdda-csiphy0-1p2-supply = <&vreg_l1c_1p2>; > > because that captures the fact we could have separate lines for each > phy, names it generically and then leaves it up to the dts > implementation to represent what actually happened on the PCB. > > That would also work for qcm2290 and sm8650. > > https://lore.kernel.org/linux-arm-msm/20250423221954.1926453-2-vladimir.zapolskiy@linaro.org/ > > So for sm8650 instead of > > + vdda-csi01-0p9-supply: > + > + vdda-csi24-0p9-supply: > + > + vdda-csi35-0p9-supply: > + > + vdda-csi01-1p2-supply: > + > + vdda-csi24-1p2-supply: > + > + vdda-csi35-1p2-supply: > > you would have > > + vdda-csiphy0-0p9-supply: > + > + vdda-csiphy1-0p9-supply: > > + vdda-csiphy0-1p2-supply: > + > + vdda-csiphy1-1p2-supply: > This option will work for SM8650, if the list of the given 6 supplies, where one supply property represens a pad to power up two CSIPHYs, is extended to the list of 12 supplies, one for each individual CSIPHY. Both options will be technically equivalent/correct, an alternative one is just two times longer. I would appreciate to get a maintainer's decision here. -- Best wishes, Vladimir
On 24/04/2025 11:45, Dmitry Baryshkov wrote: >> Which would then be consistent across SoCs for as long as 0p9 and 1p2 are >> the power-domains used by these PHYs. > This won't be consistent with other cases where we have a shared power > pin. For example, for PMICs we provide supply names which match pin > names rather than one-supply-per-LDO. Yes but taking a random example from a PMIC vdd-l2-l13-l14-supply is specific to a given PMIC, so you need to name it specifically wrt its PMIC pin-name whereas csiphyX-1p2 is there for every CSIPHY we have. For example on qcom2290 there's a shared power-pin for VDD_A_CAMSS_PLL_1P8 but then individual power-pins for VDD_A_CSI_0_1P2 and VDD_A_CSI_1_1P2. If we follow the general proposal of vdd-csiphyX-1p2-supply vdd-csiphyX-0p9-supply in the yaml, then whether SoCs like qcm2290 share 1p8 or SoCs like sm8650, sm8450, x1e have individual 1p8 pins is up to the dtsi to decide. --- bod
On Thu, Apr 24, 2025 at 12:29:39PM +0100, Bryan O'Donoghue wrote: > On 24/04/2025 11:45, Dmitry Baryshkov wrote: > > > Which would then be consistent across SoCs for as long as 0p9 and 1p2 are > > > the power-domains used by these PHYs. > > This won't be consistent with other cases where we have a shared power > > pin. For example, for PMICs we provide supply names which match pin > > names rather than one-supply-per-LDO. > > Yes but taking a random example from a PMIC vdd-l2-l13-l14-supply is > specific to a given PMIC, so you need to name it specifically wrt its PMIC > pin-name whereas csiphyX-1p2 is there for every CSIPHY we have. This is fine from my POV. > For example on qcom2290 there's a shared power-pin for VDD_A_CAMSS_PLL_1P8 > but then individual power-pins for VDD_A_CSI_0_1P2 and VDD_A_CSI_1_1P2. So far so good. > > If we follow the general proposal of > > vdd-csiphyX-1p2-supply > vdd-csiphyX-0p9-supply > > in the yaml, then whether SoCs like qcm2290 share 1p8 or SoCs like sm8650, > sm8450, x1e have individual 1p8 pins is up to the dtsi to decide. So, what should be the behaviour if the DT defines different supplies for csiphy0 and csiphy1? Would you express that constraint in DT?
On 24/04/2025 12:32, Dmitry Baryshkov wrote: > On Thu, Apr 24, 2025 at 12:29:39PM +0100, Bryan O'Donoghue wrote: >> On 24/04/2025 11:45, Dmitry Baryshkov wrote: >>>> Which would then be consistent across SoCs for as long as 0p9 and 1p2 are >>>> the power-domains used by these PHYs. >>> This won't be consistent with other cases where we have a shared power >>> pin. For example, for PMICs we provide supply names which match pin >>> names rather than one-supply-per-LDO. >> >> Yes but taking a random example from a PMIC vdd-l2-l13-l14-supply is >> specific to a given PMIC, so you need to name it specifically wrt its PMIC >> pin-name whereas csiphyX-1p2 is there for every CSIPHY we have. > > This is fine from my POV. > >> For example on qcom2290 there's a shared power-pin for VDD_A_CAMSS_PLL_1P8 >> but then individual power-pins for VDD_A_CSI_0_1P2 and VDD_A_CSI_1_1P2. > > So far so good. > >> >> If we follow the general proposal of >> >> vdd-csiphyX-1p2-supply >> vdd-csiphyX-0p9-supply >> >> in the yaml, then whether SoCs like qcm2290 share 1p8 or SoCs like sm8650, >> sm8450, x1e have individual 1p8 pins is up to the dtsi to decide. > > So, what should be the behaviour if the DT defines different supplies > for csiphy0 and csiphy1? Would you express that constraint in DT? > You'd have that for qcm2290 yaml: vdd-csiphy0-1p2-supply vdd-csiphy1-1p2-supply vdd-csiphy0-0p8-supply vdd-csiphy1-0p8-supply qcm2290-example0.dtsi vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- individual supply in PCB vdd-csiphy1-1p2-supply = <&vreg_1p2_ex1>; <- individual supply in PCB vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC vdd-csiphy1-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC qcm2290-example1.dtsi vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- shared supply in this PCB vdd-csiphy1-1p2-supply = <&vreg_1p2_ex0>; <- shared supply in this PCB vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC vdd-csiphy1-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC Then sm8650: yaml: vdd-csiphy0-1p2-supply vdd-csiphy1-1p2-supply vdd-csiphy0-0p8-supply vdd-csiphy1-0p8-supply sm8650-example0.dtsi vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- individual pin & pcb supply vdd-csiphy1-1p2-supply = <&vreg_1p2_ex1>; <- individual pin & pcb supply vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- individual pin & pcb supply vdd-csiphy1-0p8-supply = <&vreg_0p9_ex1>; <- individual pin & pcb supply sm8650-example1.dtsi vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- shared supply in this PCB vdd-csiphy1-1p2-supply = <&vreg_1p2_ex0>; <- shared supply in this PCB vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared supply in this PCB vdd-csiphy1-0p8-supply = <&vreg_0p9_ex0>; <- shared supply in this PCB That way we have a consistent naming across SoCs and PCBs and its up to the DT to get the pointer to the regulator right. --- bod
On 24/04/2025 12:17, Bryan O'Donoghue wrote: > On 24/04/2025 11:07, Krzysztof Kozlowski wrote: >> On 24/04/2025 11:34, Bryan O'Donoghue wrote: >>> On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >>>>> + vdd-csiphy-0p8-supply: >>>> Same comment as other series on the lists - this is wrong name. There >>>> are no pins named like this and all existing bindings use different name. >>> >>> The existing bindings are unfortunately not granular enough. >>> >>> I'll post s series to capture pin-names per the SoC pinout shortly. >> How are the pins/supplies actually called? >> >> Best regards, >> Krzysztof > > I don't think strictly algning to pin-names is what we want. > > Here are the input pins > > VDD_A_CSI_0_1_1P2 > VDD_A_CSI_2_4_1P2 > VDD_A_CSI_0_1_0P9 > VDD_A_CSI_2_4_0P9 > > I think the right way to represent this > > yaml: > csiphy0-1p2-supply > csiphy1-1p2-supply But there is no separate supply for csiphy0 and csiphy1. Such split feels fine if you have separate CSI phy device nodes, which now I wonder - where are they? Best regards, Krzysztof
On 24/04/2025 16:54, Krzysztof Kozlowski wrote: > On 24/04/2025 12:17, Bryan O'Donoghue wrote: >> On 24/04/2025 11:07, Krzysztof Kozlowski wrote: >>> On 24/04/2025 11:34, Bryan O'Donoghue wrote: >>>> On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >>>>>> + vdd-csiphy-0p8-supply: >>>>> Same comment as other series on the lists - this is wrong name. There >>>>> are no pins named like this and all existing bindings use different name. >>>> >>>> The existing bindings are unfortunately not granular enough. >>>> >>>> I'll post s series to capture pin-names per the SoC pinout shortly. >>> How are the pins/supplies actually called? >>> >>> Best regards, >>> Krzysztof >> >> I don't think strictly algning to pin-names is what we want. >> >> Here are the input pins >> >> VDD_A_CSI_0_1_1P2 >> VDD_A_CSI_2_4_1P2 >> VDD_A_CSI_0_1_0P9 >> VDD_A_CSI_2_4_0P9 >> >> I think the right way to represent this >> >> yaml: >> csiphy0-1p2-supply >> csiphy1-1p2-supply > > But there is no separate supply for csiphy0 and csiphy1. Such split > feels fine if you have separate CSI phy device nodes, which now I wonder > - where are they? > > Best regards, > Krzysztof The main hardware argument for it is probably these PHYs do live inside of the TITAN_TOP_GDSC power-domain, which is the same collapsible power-domain that all of the other CAMSS components live inside of. As I recall we had a four way - albeit long discussion on this in Dublin, you, me, Vlad and Neil and my memory was we would implement multiple rails in the existing CAMSS PHY structure and then look at how to model the PHYs differently in DTS. The Test Pattern Generators - TPGs would then also fit into this new model for the PHYs. --- bod
On 4/24/25 6:13 PM, Bryan O'Donoghue wrote: > On 24/04/2025 16:54, Krzysztof Kozlowski wrote: >> On 24/04/2025 12:17, Bryan O'Donoghue wrote: >>> On 24/04/2025 11:07, Krzysztof Kozlowski wrote: >>>> On 24/04/2025 11:34, Bryan O'Donoghue wrote: >>>>> On 24/04/2025 07:40, Krzysztof Kozlowski wrote: >>>>>>> + vdd-csiphy-0p8-supply: >>>>>> Same comment as other series on the lists - this is wrong name. There >>>>>> are no pins named like this and all existing bindings use different name. >>>>> >>>>> The existing bindings are unfortunately not granular enough. >>>>> >>>>> I'll post s series to capture pin-names per the SoC pinout shortly. >>>> How are the pins/supplies actually called? >>>> >>>> Best regards, >>>> Krzysztof >>> >>> I don't think strictly algning to pin-names is what we want. >>> >>> Here are the input pins >>> >>> VDD_A_CSI_0_1_1P2 >>> VDD_A_CSI_2_4_1P2 >>> VDD_A_CSI_0_1_0P9 >>> VDD_A_CSI_2_4_0P9 >>> >>> I think the right way to represent this >>> >>> yaml: >>> csiphy0-1p2-supply >>> csiphy1-1p2-supply >> >> But there is no separate supply for csiphy0 and csiphy1. Such split >> feels fine if you have separate CSI phy device nodes, which now I wonder >> - where are they? >> >> Best regards, >> Krzysztof > > The main hardware argument for it is probably these PHYs do live inside of the TITAN_TOP_GDSC power-domain, which is the same collapsible power-domain that all of the other CAMSS components live inside of. > > As I recall we had a four way - albeit long discussion on this in Dublin, you, me, Vlad and Neil and my memory was we would implement multiple rails in the existing CAMSS PHY structure and then look at how to model the PHYs differently in DTS. > > The Test Pattern Generators - TPGs would then also fit into this new model for the PHYs. Maybe we could consider modeling various camss subdevices as separate DT nodes, perhaps on some sort of a `camss` simple-pm-bus or something alike Konrad
On 24/04/2025 21:08, Konrad Dybcio wrote: >> The Test Pattern Generators - TPGs would then also fit into this new model for the PHYs. > Maybe we could consider modeling various camss subdevices as separate DT nodes, > perhaps on some sort of a `camss` simple-pm-bus or something alike I hadn't though of that specifically, call it option 0. I had been thinking of 1. Doing like venus with a subdevice based on a compat 2. Doing it like DPU PHYs and just moving everything into drivers/phy The fact that the CSIPHYs are technically inside of the CAMSS collapsible power-domain seem to mitigate against option 2. --- bod
On 4/24/25 11:10 PM, Bryan O'Donoghue wrote: > On 24/04/2025 21:08, Konrad Dybcio wrote: >>> The Test Pattern Generators - TPGs would then also fit into this new model for the PHYs. >> Maybe we could consider modeling various camss subdevices as separate DT nodes, >> perhaps on some sort of a `camss` simple-pm-bus or something alike > > I hadn't though of that specifically, call it option 0. > > I had been thinking of > > 1. Doing like venus with a subdevice based on a compat > 2. Doing it like DPU PHYs and just moving everything into drivers/phy > > The fact that the CSIPHYs are technically inside of the CAMSS collapsible power-domain seem to mitigate against option 2. Option 1 sounds just a little horrid, I'd be interested in something that combines 0 and 2.. We may either repeat the power domain everywhere (meh), or model camss as a bus, (see e.g. agnoc@0 in msm8996.dtsi) and focus on other resources required by specific blocks (e.g. CSIPHY clocks for the CSIPHY) Konrad
On Thu, Apr 24, 2025 at 12:51:31PM +0100, Bryan O'Donoghue wrote: > On 24/04/2025 12:32, Dmitry Baryshkov wrote: > > On Thu, Apr 24, 2025 at 12:29:39PM +0100, Bryan O'Donoghue wrote: > > > On 24/04/2025 11:45, Dmitry Baryshkov wrote: > > > > > Which would then be consistent across SoCs for as long as 0p9 and 1p2 are > > > > > the power-domains used by these PHYs. > > > > This won't be consistent with other cases where we have a shared power > > > > pin. For example, for PMICs we provide supply names which match pin > > > > names rather than one-supply-per-LDO. > > > > > > Yes but taking a random example from a PMIC vdd-l2-l13-l14-supply is > > > specific to a given PMIC, so you need to name it specifically wrt its PMIC > > > pin-name whereas csiphyX-1p2 is there for every CSIPHY we have. > > > > This is fine from my POV. > > > > > For example on qcom2290 there's a shared power-pin for VDD_A_CAMSS_PLL_1P8 > > > but then individual power-pins for VDD_A_CSI_0_1P2 and VDD_A_CSI_1_1P2. > > > > So far so good. > > > > > > > > If we follow the general proposal of > > > > > > vdd-csiphyX-1p2-supply > > > vdd-csiphyX-0p9-supply > > > > > > in the yaml, then whether SoCs like qcm2290 share 1p8 or SoCs like sm8650, > > > sm8450, x1e have individual 1p8 pins is up to the dtsi to decide. > > > > So, what should be the behaviour if the DT defines different supplies > > for csiphy0 and csiphy1? Would you express that constraint in DT? > > > > You'd have that for qcm2290 > > yaml: > > vdd-csiphy0-1p2-supply > vdd-csiphy1-1p2-supply > > vdd-csiphy0-0p8-supply > vdd-csiphy1-0p8-supply > > qcm2290-example0.dtsi > > vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- individual supply in PCB > vdd-csiphy1-1p2-supply = <&vreg_1p2_ex1>; <- individual supply in PCB > > vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC > vdd-csiphy1-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC What should driver do if: vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- individual supply in PCB vdd-csiphy1-1p2-supply = <&vreg_1p2_ex1>; <- individual supply in PCB vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC vdd-csiphy1-0p8-supply = <&vreg_0p9_ex1>; <- should be shared pin I don't want to allow DT authors to make this kind of mistake.
On 25/04/2025 09:26, Dmitry Baryshkov wrote: > What should driver do if: > > vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- individual supply in PCB > vdd-csiphy1-1p2-supply = <&vreg_1p2_ex1>; <- individual supply in PCB > > vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC > vdd-csiphy1-0p8-supply = <&vreg_0p9_ex1>; <- should be shared pin > > I don't want to allow DT authors to make this kind of mistake. I require anybody submitting patches to show how they tested this. So you'd have to lie about testing it for a mistake like that to get through. --- bod
On Fri, Apr 25, 2025 at 09:35:05AM +0100, Bryan O'Donoghue wrote: > On 25/04/2025 09:26, Dmitry Baryshkov wrote: > > What should driver do if: > > > > vdd-csiphy0-1p2-supply = <&vreg_1p2_ex0>; <- individual supply in PCB > > vdd-csiphy1-1p2-supply = <&vreg_1p2_ex1>; <- individual supply in PCB > > > > vdd-csiphy0-0p8-supply = <&vreg_0p9_ex0>; <- shared pin in the SoC > > vdd-csiphy1-0p8-supply = <&vreg_0p9_ex1>; <- should be shared pin > > > > I don't want to allow DT authors to make this kind of mistake. > > I require anybody submitting patches to show how they tested this. > > So you'd have to lie about testing it for a mistake like that to get > through. It's easy to miss it. I think, the supplies should be reflecting actual pins on the SoC.
diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml new file mode 100644 index 0000000000000000000000000000000000000000..113565cf2a991a8dcbc20889090e177e8bcadaac --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml @@ -0,0 +1,367 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,x1e80100-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm X1E80100 Camera Subsystem (CAMSS) + +maintainers: + - Bryan O'Donoghue <bryan.odonoghue@linaro.org> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,x1e80100-camss + + reg: + maxItems: 17 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csid_wrapper + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy4 + - const: csitpg0 + - const: csitpg1 + - const: csitpg2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite0 + - const: vfe_lite1 + + clocks: + maxItems: 29 + + clock-names: + items: + - const: camnoc_nrt_axi + - const: camnoc_rt_axi + - const: core_ahb + - const: cpas_ahb + - const: cpas_fast_ahb + - const: cpas_vfe0 + - const: cpas_vfe1 + - const: cpas_vfe_lite + - 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 + - const: vfe0_fast_ahb + - const: vfe1 + - const: vfe1_fast_ahb + - const: vfe_lite + - const: vfe_lite_ahb + - const: vfe_lite_cphy_rx + - const: vfe_lite_csid + + interrupts: + maxItems: 13 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - 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 + + interconnects: + maxItems: 4 + + interconnect-names: + items: + - const: ahb + - const: hf_mnoc + - const: sf_mnoc + - const: sf_icp_mnoc + + iommus: + maxItems: 8 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: top + + vdd-csiphy-0p8-supply: + description: + Phandle to a 0.8V regulator supply to a PHY. + + vdd-csiphy-1p2-supply: + description: + Phandle to 1.8V regulator supply to a PHY. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + patternProperties: + "^port@[0-3]+$": + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + description: + Input port for receiving CSI data from a CSIPHY. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - interrupt-names + - interconnects + - interconnect-names + - iommus + - power-domains + - power-domain-names + - vdd-csiphy-0p8-supply + - vdd-csiphy-1p2-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + camss: isp@acb6000 { + compatible = "qcom,x1e80100-camss"; + + reg = <0 0x0acb7000 0 0x2000>, + <0 0x0acb9000 0 0x2000>, + <0 0x0acbb000 0 0x2000>, + <0 0x0acc6000 0 0x1000>, + <0 0x0acca000 0 0x1000>, + <0 0x0acb6000 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>, + <0 0x0ac62000 0 0x4000>, + <0 0x0ac71000 0 0x4000>, + <0 0x0acc7000 0 0x2000>, + <0 0x0accb000 0 0x2000>; + + reg-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csid_wrapper", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy4", + "csitpg0", + "csitpg1", + "csitpg2", + "vfe0", + "vfe1", + "vfe_lite0", + "vfe_lite1"; + + clocks = <&camcc CAM_CC_CAMNOC_AXI_NRT_CLK>, + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>, + <&camcc CAM_CC_CORE_AHB_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>, + <&camcc CAM_CC_CPAS_IFE_0_CLK>, + <&camcc CAM_CC_CPAS_IFE_1_CLK>, + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>, + <&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>, + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>; + + clock-names = "camnoc_nrt_axi", + "camnoc_rt_axi", + "core_ahb", + "cpas_ahb", + "cpas_fast_ahb", + "cpas_vfe0", + "cpas_vfe1", + "cpas_vfe_lite", + "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", + "vfe0_fast_ahb", + "vfe1", + "vfe1_fast_ahb", + "vfe_lite", + "vfe_lite_ahb", + "vfe_lite_cphy_rx", + "vfe_lite_csid"; + + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <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>, + <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy4", + "vfe0", + "vfe1", + "vfe_lite0", + "vfe_lite1"; + + 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 + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, + <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, + <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; + + interconnect-names = "ahb", + "hf_mnoc", + "sf_mnoc", + "sf_icp_mnoc"; + + iommus = <&apps_smmu 0x800 0x60>, + <&apps_smmu 0x860 0x60>, + <&apps_smmu 0x1800 0x60>, + <&apps_smmu 0x1860 0x60>, + <&apps_smmu 0x18e0 0x00>, + <&apps_smmu 0x1980 0x20>, + <&apps_smmu 0x1900 0x00>, + <&apps_smmu 0x19a0 0x20>; + + power-domains = <&camcc CAM_CC_IFE_0_GDSC>, + <&camcc CAM_CC_IFE_1_GDSC>, + <&camcc CAM_CC_TITAN_TOP_GDSC>; + + power-domain-names = "ife0", + "ife1", + "top"; + + vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>; + vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + csiphy_ep0: endpoint { + clock-lanes = <7>; + data-lanes = <0 1>; + remote-endpoint = <&sensor_ep>; + }; + }; + }; + }; + };