[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH=2Ntw5uZOLmc8b3oB5CizYQQ_Oxie3Hk_Z68WwHb=u2Xx05w@mail.gmail.com>
Date: Fri, 18 Jun 2021 15:42:39 +0530
From: Bhupesh Sharma <bhupesh.sharma@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...ainline.org>
Cc: linux-arm-msm@...r.kernel.org, bhupesh.linux@...il.com,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Andy Gross <agross@...nel.org>,
Mark Brown <broonie@...nel.org>, Vinod Koul <vkoul@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH v3 4/5] arm64: dts: qcom: pmm8155au_2: Add base dts file
Hi Konrad,
Thanks for your review.
On Fri, 18 Jun 2021 at 04:02, Konrad Dybcio
<konrad.dybcio@...ainline.org> wrote:
>
>
> > Add base DTS file for pmm8155au_2 along with GPIOs, power-on, rtc and vadc
> > nodes.
> >
> > Cc: Mark Brown <broonie@...nel.org>
> > Cc: Vinod Koul <vkoul@...nel.org>
> > Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@...aro.org>
> > ---
> > arch/arm64/boot/dts/qcom/pmm8155au_2.dtsi | 107 ++++++++++++++++++++++
> > 1 file changed, 107 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/pmm8155au_2.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/qcom/pmm8155au_2.dtsi b/arch/arm64/boot/dts/qcom/pmm8155au_2.dtsi
> > new file mode 100644
> > index 000000000000..0c7d7a66c0b5
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/pmm8155au_2.dtsi
> > @@ -0,0 +1,107 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2021, Linaro Limited
> > + */
> > +
> > +#include <dt-bindings/input/input.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +#include <dt-bindings/spmi/spmi.h>
> > +
> > +/ {
> > + thermal-zones {
> > + pmm8155au-2-thermal {
> > + polling-delay-passive = <100>;
> > + polling-delay = <0>;
> > +
> > + thermal-sensors = <&pmm8155au_2_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 {
> > + pmic@4 {
> > + compatible = "qcom,pmm8155au", "qcom,spmi-pmic";
> > + reg = <0x4 SPMI_USID>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + power-on@800 {
> > + compatible = "qcom,pm8916-pon";
> > + reg = <0x0800>;
>
> No common debounce, interrupts, bias- property or pwrkey key code?
>
> Besides, (as a question to Bjorn and others) do we pad reg to 4 digits in PMIC DTs now?
Maybe Bjorn can pitch in with his thoughts here.
> > +
> > + status = "disabled";
> > + };
> > +
> > + pmm8155au_2_temp: temp-alarm@...0 {
> > + compatible = "qcom,spmi-temp-alarm";
> > + reg = <0x2400>;
> > + interrupts = <0x4 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
> > + io-channels = <&pmm8155au_2_adc ADC5_DIE_TEMP>;
> > + io-channel-names = "thermal";
> > + #thermal-sensor-cells = <0>;
> > + };
> > +
> > + pmm8155au_2_adc: adc@...0 {
> > + compatible = "qcom,spmi-adc5";
> > + reg = <0x3100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #io-channel-cells = <1>;
> > + interrupts = <0x4 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> > +
> > + ref-gnd@0 {
> > + reg = <ADC5_REF_GND>;
> > + qcom,pre-scaling = <1 1>;
> > + label = "ref_gnd";
> > + };
> > +
> > + vref-1p25@1 {
> > + reg = <ADC5_1P25VREF>;
> > + qcom,pre-scaling = <1 1>;
> > + label = "vref_1p25";
> > + };
> > +
> > + die-temp@6 {
> > + reg = <ADC5_DIE_TEMP>;
> > + qcom,pre-scaling = <1 1>;
> > + label = "die_temp";
> > + };
> > + };
> > +
> > + pmm8155au_2_gpios: gpio@...0 {
> > + compatible = "qcom,pmm8155au-gpio";
> > + reg = <0xc000>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
>
> Don't we do gpio-ranges anymore?
Maybe Bjorn can pitch in with his thoughts here as he may have more
historical context, but I personally think that since the mapping
between the pin controller local number space and the pins in the
GPIO controller local number space is 1:1 (same) here, adding
gpio-ranges property here is optional (as it provides little
additional information).
But I might have missed something here, so I will wait for more
thoughts from Bjorn.
Thanks,
Bhupesh
>
>
> > + };
> > +
> > + pmic@5 {
> > + compatible = "qcom,pmm8155au", "qcom,spmi-pmic";
> > + reg = <0x5 SPMI_USID>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +};
>
>
> Konrad
>
Powered by blists - more mailing lists