| Message ID | 1690970366-30982-4-git-send-email-quic_rohiagar@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add pmics supported in Qualcomm's SDX75 platform | expand |
On 2.08.2023 11:59, Rohit Agarwal wrote: > Add dtsi for PMIC pm7550ba found in Qualcomm platforms. > > Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > --- Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" [...] > + > + pm7550ba_eusb2_repeater: phy@fd00 { > + compatible = "qcom,pm8550b-eusb2-repeater"; A new compatible should be introduced, so that it goes like this: compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; Konrad
On 8/2/2023 6:12 PM, Konrad Dybcio wrote: > On 2.08.2023 11:59, Rohit Agarwal wrote: >> Add dtsi for PMIC pm7550ba found in Qualcomm platforms. >> >> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >> --- > Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" > > [...] > >> + >> + pm7550ba_eusb2_repeater: phy@fd00 { >> + compatible = "qcom,pm8550b-eusb2-repeater"; > A new compatible should be introduced, so that it goes like this: > > compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; Just a doubt, Since the compatible can be same why we need to introduce a new compatible. Should every soc have a compatible string? Thanks, Rohit. > > Konrad
On 2.08.2023 15:13, Rohit Agarwal wrote: > > On 8/2/2023 6:12 PM, Konrad Dybcio wrote: >> On 2.08.2023 11:59, Rohit Agarwal wrote: >>> Add dtsi for PMIC pm7550ba found in Qualcomm platforms. >>> >>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>> --- >> Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" >> >> [...] >> >>> + >>> + pm7550ba_eusb2_repeater: phy@fd00 { >>> + compatible = "qcom,pm8550b-eusb2-repeater"; >> A new compatible should be introduced, so that it goes like this: >> >> compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; > Just a doubt, Since the compatible can be same why we need to introduce a new compatible. > Should every soc have a compatible string? If it turns out that we need to add a quirk for PM7550BA 3 years down the line, this approach lets us fix it for users that never updated their device trees. Konrad
On 8/2/2023 6:44 PM, Konrad Dybcio wrote: > On 2.08.2023 15:13, Rohit Agarwal wrote: >> On 8/2/2023 6:12 PM, Konrad Dybcio wrote: >>> On 2.08.2023 11:59, Rohit Agarwal wrote: >>>> Add dtsi for PMIC pm7550ba found in Qualcomm platforms. >>>> >>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>>> --- >>> Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" >>> >>> [...] >>> >>>> + >>>> + pm7550ba_eusb2_repeater: phy@fd00 { >>>> + compatible = "qcom,pm8550b-eusb2-repeater"; >>> A new compatible should be introduced, so that it goes like this: >>> >>> compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; >> Just a doubt, Since the compatible can be same why we need to introduce a new compatible. >> Should every soc have a compatible string? > If it turns out that we need to add a quirk for PM7550BA 3 years down > the line, this approach lets us fix it for users that never updated > their device trees. Yes. Got it. Thanks, Rohit > > Konrad
On Wed, Aug 02, 2023 at 03:14:19PM +0200, Konrad Dybcio wrote: > On 2.08.2023 15:13, Rohit Agarwal wrote: > > > > On 8/2/2023 6:12 PM, Konrad Dybcio wrote: > >> On 2.08.2023 11:59, Rohit Agarwal wrote: > >>> Add dtsi for PMIC pm7550ba found in Qualcomm platforms. > >>> > >>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > >>> --- > >> Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" > >> > >> [...] > >> > >>> + > >>> + pm7550ba_eusb2_repeater: phy@fd00 { > >>> + compatible = "qcom,pm8550b-eusb2-repeater"; > >> A new compatible should be introduced, so that it goes like this: > >> > >> compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; > > Just a doubt, Since the compatible can be same why we need to introduce a new compatible. > > Should every soc have a compatible string? > If it turns out that we need to add a quirk for PM7550BA 3 years down > the line, this approach lets us fix it for users that never updated > their device trees. > Trying to make my understanding clear. eUSB repeater is a peripheral in the PMIC. Do we need a separate compatible even if the peripheral is same in two different PMIC chips? I believe eUSB peripheral has some identification registers to apply any quirks in future. Adding Jack who would know more about any deltas between the PMICs in sdx75 and sm8550. Thanks, Pavan
On 3.08.2023 07:06, Pavan Kondeti wrote: > > On Wed, Aug 02, 2023 at 03:14:19PM +0200, Konrad Dybcio wrote: >> On 2.08.2023 15:13, Rohit Agarwal wrote: >>> >>> On 8/2/2023 6:12 PM, Konrad Dybcio wrote: >>>> On 2.08.2023 11:59, Rohit Agarwal wrote: >>>>> Add dtsi for PMIC pm7550ba found in Qualcomm platforms. >>>>> >>>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>>>> --- >>>> Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" >>>> >>>> [...] >>>> >>>>> + >>>>> + pm7550ba_eusb2_repeater: phy@fd00 { >>>>> + compatible = "qcom,pm8550b-eusb2-repeater"; >>>> A new compatible should be introduced, so that it goes like this: >>>> >>>> compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; >>> Just a doubt, Since the compatible can be same why we need to introduce a new compatible. >>> Should every soc have a compatible string? >> If it turns out that we need to add a quirk for PM7550BA 3 years down >> the line, this approach lets us fix it for users that never updated >> their device trees. >> > > Trying to make my understanding clear. > > eUSB repeater is a peripheral in the PMIC. Do we need a separate > compatible even if the peripheral is same in two different PMIC chips? > I believe eUSB peripheral has some identification registers to apply any > quirks in future. Perhaps, but keeping the compatible tied to the specific hardware is the way to go with the device tree. Most components don't have such information avaiable, and since at introduction time there wasn't any better name for it, "pm8550b-eusb2-repeater" was chosen. Konrad
On Fri, Aug 04, 2023 at 06:58:34PM +0200, Konrad Dybcio wrote: > On 3.08.2023 07:06, Pavan Kondeti wrote: > > > > On Wed, Aug 02, 2023 at 03:14:19PM +0200, Konrad Dybcio wrote: > >> On 2.08.2023 15:13, Rohit Agarwal wrote: > >>> > >>> On 8/2/2023 6:12 PM, Konrad Dybcio wrote: > >>>> On 2.08.2023 11:59, Rohit Agarwal wrote: > >>>>> Add dtsi for PMIC pm7550ba found in Qualcomm platforms. > >>>>> > >>>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > >>>>> --- > >>>> Subject: "PMIC pm7550ba" -> "pm7550ba PMIC" > >>>> > >>>> [...] > >>>> > >>>>> + > >>>>> + pm7550ba_eusb2_repeater: phy@fd00 { > >>>>> + compatible = "qcom,pm8550b-eusb2-repeater"; > >>>> A new compatible should be introduced, so that it goes like this: > >>>> > >>>> compatible = "qcom,pm7550ba-eusb2-repeater", "qcom,pm8550b-eusb2-repeater"; > >>> Just a doubt, Since the compatible can be same why we need to introduce a new compatible. > >>> Should every soc have a compatible string? > >> If it turns out that we need to add a quirk for PM7550BA 3 years down > >> the line, this approach lets us fix it for users that never updated > >> their device trees. > >> > > > > Trying to make my understanding clear. > > > > eUSB repeater is a peripheral in the PMIC. Do we need a separate > > compatible even if the peripheral is same in two different PMIC chips? > > I believe eUSB peripheral has some identification registers to apply any > > quirks in future. > Perhaps, but keeping the compatible tied to the specific hardware is > the way to go with the device tree. Most components don't have such > information avaiable, and since at introduction time there wasn't > any better name for it, "pm8550b-eusb2-repeater" was chosen. > Thanks for the clarification and guidance. We can introduce a new compatible and use qcom,pm8550b-eusb2-repeater as generic binding. Thanks, Pavan
diff --git a/arch/arm64/boot/dts/qcom/pm7550ba.dtsi b/arch/arm64/boot/dts/qcom/pm7550ba.dtsi new file mode 100644 index 0000000..97b28bb --- /dev/null +++ b/arch/arm64/boot/dts/qcom/pm7550ba.dtsi @@ -0,0 +1,70 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/spmi/spmi.h> + +/ { + thermal-zones { + pm7550ba-thermal { + polling-delay-passive = <100>; + polling-delay = <0>; + + thermal-sensors = <&pm7550ba_temp>; + + trips { + trip0 { + temperature = <95000>; + hysteresis = <0>; + type = "passive"; + }; + + trip1 { + temperature = <115000>; + hysteresis = <0>; + type = "hot"; + }; + + trip2 { + temperature = <145000>; + hysteresis = <0>; + type = "critical"; + }; + }; + }; + }; +}; + +&spmi_bus { + pm7550ba: pmic@7 { + compatible = "qcom,pm7550ba", "qcom,spmi-pmic"; + reg = <7 SPMI_USID>; + #address-cells = <1>; + #size-cells = <0>; + + pm7550ba_temp: temp-alarm@a00 { + compatible = "qcom,spmi-temp-alarm"; + reg = <0xa00>; + interrupts = <0x7 0xa 0x0 IRQ_TYPE_EDGE_BOTH>; + #thermal-sensor-cells = <0>; + }; + + pm7550ba_gpios: gpio@8800 { + compatible = "qcom,pm7550ba-gpio", "qcom,spmi-gpio"; + reg = <0x8800>; + gpio-controller; + gpio-ranges = <&pm7550ba_gpios 0 0 8>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + pm7550ba_eusb2_repeater: phy@fd00 { + compatible = "qcom,pm8550b-eusb2-repeater"; + reg = <0xfd00>; + #phy-cells = <0>; + }; + }; +};
Add dtsi for PMIC pm7550ba found in Qualcomm platforms. Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> --- arch/arm64/boot/dts/qcom/pm7550ba.dtsi | 70 ++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/pm7550ba.dtsi