| Message ID | 20240205115721.1195336-1-quic_jingyw@quicinc.com |
|---|---|
| Headers | show |
| Series | arm64: dts: qcom: Introduce AIM500 platform device tree | expand |
On 05/02/2024 12:57, Jingyi Wang wrote: > Add SoC Info support for the SM8650P platform. > > Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> > --- > drivers/soc/qcom/socinfo.c | 1 + Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On 05/02/2024 12:57, Jingyi Wang wrote: > Introduce aim500 board dtsi. > > AIM500 Series is a highly optimized family of modules designed to > support AIoT and Generative AI applications based on sm8650p with > PMIC and bluetooth functions etc. > > Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> > Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> > Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> > --- > arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ > 1 file changed, 409 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > > diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > new file mode 100644 > index 000000000000..cb857da8653b > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > @@ -0,0 +1,409 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> > +#include "sm8650p.dtsi" > +#include "pm8550.dtsi" > +#include "pm8550b.dtsi" > +#define PMK8550VE_SID 8 > +#include "pm8550ve.dtsi" > +#include "pm8550vs.dtsi" > +#include "pmk8550.dtsi" > + > +/ { > + aliases { > + serial1 = &uart14; > + }; > + > + vph_pwr: vph-pwr-regulator { }; What is this? Why is it needed? Best regards, Krzysztof
On Mon, 5 Feb 2024 at 14:00, Jingyi Wang <quic_jingyw@quicinc.com> wrote: > > Introduce aim500 board dtsi. So, is it a board or a module? > > AIM500 Series is a highly optimized family of modules designed to > support AIoT and Generative AI applications based on sm8650p with > PMIC and bluetooth functions etc. > > Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> > Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> > Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> > --- > arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ > 1 file changed, 409 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > > diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > new file mode 100644 > index 000000000000..cb857da8653b > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > @@ -0,0 +1,409 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> > +#include "sm8650p.dtsi" > +#include "pm8550.dtsi" > +#include "pm8550b.dtsi" > +#define PMK8550VE_SID 8 > +#include "pm8550ve.dtsi" > +#include "pm8550vs.dtsi" > +#include "pmk8550.dtsi" > + > +/ { > + aliases { > + serial1 = &uart14; > + }; > + > + vph_pwr: vph-pwr-regulator { }; Is this regulator a part of the module or a part of the carrier board? If the latter is true, this must go to the carrier board DT file. > +}; > + > +&apps_rsc { > + regulators-0 { > + compatible = "qcom,pm8550-rpmh-regulators"; > + > + vdd-bob1-supply = <&vph_pwr>; > + vdd-bob2-supply = <&vph_pwr>; > + vdd-l2-l13-l14-supply = <&vreg_bob1>; > + vdd-l3-supply = <&vreg_s1c_1p2>; > + vdd-l5-l16-supply = <&vreg_bob1>; > + vdd-l6-l7-supply = <&vreg_bob1>; > + vdd-l8-l9-supply = <&vreg_bob1>; > + vdd-l11-supply = <&vreg_s1c_1p2>; > + vdd-l12-supply = <&vreg_s6c_1p8>; > + vdd-l15-supply = <&vreg_s6c_1p8>; > + vdd-l17-supply = <&vreg_bob2>; > + > + qcom,pmic-id = "b"; [skipped] > + > +&qupv3_id_1 { > + status = "okay"; > +}; No GPI node being enabled? > + > +&tlmm { > + bt_default: bt-default-state { > + bt-en-pins { > + pins = "gpio17"; > + function = "gpio"; > + drive-strength = <16>; > + bias-disable; > + }; > + > + sw-ctrl-pins { > + pins = "gpio18"; > + function = "gpio"; > + bias-pull-down; > + }; > + }; > +}; > + > +&uart14 { > + status = "okay"; > + > + bluetooth { > + compatible = "qcom,wcn7850-bt"; > + > + clocks = <&rpmhcc RPMH_RF_CLK1>; > + > + vddio-supply = <&vreg_l3c_1p2>; > + vddaon-supply = <&vreg_l15b_1p8>; > + vdddig-supply = <&vreg_s3c_0p9>; > + vddrfa0p8-supply = <&vreg_s3c_0p9>; > + vddrfa1p2-supply = <&vreg_s1c_1p2>; > + vddrfa1p9-supply = <&vreg_s6c_1p8>; > + > + max-speed = <3200000>; > + > + enable-gpios = <&tlmm 17 GPIO_ACTIVE_HIGH>; > + swctrl-gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>; > + > + pinctrl-0 = <&bt_default>; > + pinctrl-names = "default"; > + }; > +}; > -- > 2.25.1 > >
Hi Krzysztof, On 2/5/2024 8:35 PM, Krzysztof Kozlowski wrote: > On 05/02/2024 12:57, Jingyi Wang wrote: >> Introduce aim500 board dtsi. >> >> AIM500 Series is a highly optimized family of modules designed to >> support AIoT and Generative AI applications based on sm8650p with >> PMIC and bluetooth functions etc. >> >> Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >> Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> >> --- >> arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ >> 1 file changed, 409 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >> >> diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >> new file mode 100644 >> index 000000000000..cb857da8653b >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >> @@ -0,0 +1,409 @@ >> +// SPDX-License-Identifier: BSD-3-Clause >> +/* >> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. >> + */ >> + >> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> >> +#include "sm8650p.dtsi" >> +#include "pm8550.dtsi" >> +#include "pm8550b.dtsi" >> +#define PMK8550VE_SID 8 >> +#include "pm8550ve.dtsi" >> +#include "pm8550vs.dtsi" >> +#include "pmk8550.dtsi" >> + >> +/ { >> + aliases { >> + serial1 = &uart14; >> + }; >> + >> + vph_pwr: vph-pwr-regulator { }; > > What is this? Why is it needed? > > > Best regards, > Krzysztof > vph_pwr is the power supply which differs from board design, it is defined in sm8650p-aim500-aiot.dts, and it is used in the sm8650p-aim500.dts for regulator supply, so we leave the node here. Thanks, Jingyi
Hi Dmitry, On 2/5/2024 10:23 PM, Dmitry Baryshkov wrote: > On Mon, 5 Feb 2024 at 14:00, Jingyi Wang <quic_jingyw@quicinc.com> wrote: >> >> Introduce aim500 board dtsi. > > So, is it a board or a module? > aim500 is a module, will fix the descrption. >> >> AIM500 Series is a highly optimized family of modules designed to >> support AIoT and Generative AI applications based on sm8650p with >> PMIC and bluetooth functions etc. >> >> Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >> Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> >> --- >> arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ >> 1 file changed, 409 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >> >> diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >> new file mode 100644 >> index 000000000000..cb857da8653b >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >> @@ -0,0 +1,409 @@ >> +// SPDX-License-Identifier: BSD-3-Clause >> +/* >> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. >> + */ >> + >> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> >> +#include "sm8650p.dtsi" >> +#include "pm8550.dtsi" >> +#include "pm8550b.dtsi" >> +#define PMK8550VE_SID 8 >> +#include "pm8550ve.dtsi" >> +#include "pm8550vs.dtsi" >> +#include "pmk8550.dtsi" >> + >> +/ { >> + aliases { >> + serial1 = &uart14; >> + }; >> + >> + vph_pwr: vph-pwr-regulator { }; > > Is this regulator a part of the module or a part of the carrier board? > If the latter is true, this must go to the carrier board DT file. > the vph_pwr regulator is defined in the aim500-aiot carrier board and used in aim500 module. >> +}; >> + >> +&apps_rsc { >> + regulators-0 { >> + compatible = "qcom,pm8550-rpmh-regulators"; >> + >> + vdd-bob1-supply = <&vph_pwr>; >> + vdd-bob2-supply = <&vph_pwr>; >> + vdd-l2-l13-l14-supply = <&vreg_bob1>; >> + vdd-l3-supply = <&vreg_s1c_1p2>; >> + vdd-l5-l16-supply = <&vreg_bob1>; >> + vdd-l6-l7-supply = <&vreg_bob1>; >> + vdd-l8-l9-supply = <&vreg_bob1>; >> + vdd-l11-supply = <&vreg_s1c_1p2>; >> + vdd-l12-supply = <&vreg_s6c_1p8>; >> + vdd-l15-supply = <&vreg_s6c_1p8>; >> + vdd-l17-supply = <&vreg_bob2>; >> + >> + qcom,pmic-id = "b"; > > [skipped] > >> + >> +&qupv3_id_1 { >> + status = "okay"; >> +}; > > No GPI node being enabled? > will drop this node for there is no client under that. >> + >> +&tlmm { >> + bt_default: bt-default-state { >> + bt-en-pins { >> + pins = "gpio17"; >> + function = "gpio"; >> + drive-strength = <16>; >> + bias-disable; >> + }; >> + >> + sw-ctrl-pins { >> + pins = "gpio18"; >> + function = "gpio"; >> + bias-pull-down; >> + }; >> + }; >> +}; >> + >> +&uart14 { >> + status = "okay"; >> + >> + bluetooth { >> + compatible = "qcom,wcn7850-bt"; >> + >> + clocks = <&rpmhcc RPMH_RF_CLK1>; >> + >> + vddio-supply = <&vreg_l3c_1p2>; >> + vddaon-supply = <&vreg_l15b_1p8>; >> + vdddig-supply = <&vreg_s3c_0p9>; >> + vddrfa0p8-supply = <&vreg_s3c_0p9>; >> + vddrfa1p2-supply = <&vreg_s1c_1p2>; >> + vddrfa1p9-supply = <&vreg_s6c_1p8>; >> + >> + max-speed = <3200000>; >> + >> + enable-gpios = <&tlmm 17 GPIO_ACTIVE_HIGH>; >> + swctrl-gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>; >> + >> + pinctrl-0 = <&bt_default>; >> + pinctrl-names = "default"; >> + }; >> +}; >> -- >> 2.25.1 >> >> > > Thanks, Jingyi
On Tue, 20 Feb 2024 at 11:17, Jingyi Wang <quic_jingyw@quicinc.com> wrote: > > Hi Dmitry, > > On 2/5/2024 10:23 PM, Dmitry Baryshkov wrote: > > On Mon, 5 Feb 2024 at 14:00, Jingyi Wang <quic_jingyw@quicinc.com> wrote: > >> > >> Introduce aim500 board dtsi. > > > > So, is it a board or a module? > > > aim500 is a module, will fix the descrption. > > >> > >> AIM500 Series is a highly optimized family of modules designed to > >> support AIoT and Generative AI applications based on sm8650p with > >> PMIC and bluetooth functions etc. > >> > >> Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> > >> Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> > >> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> > >> --- > >> arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ > >> 1 file changed, 409 insertions(+) > >> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > >> > >> diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > >> new file mode 100644 > >> index 000000000000..cb857da8653b > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi > >> @@ -0,0 +1,409 @@ > >> +// SPDX-License-Identifier: BSD-3-Clause > >> +/* > >> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. > >> + */ > >> + > >> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> > >> +#include "sm8650p.dtsi" > >> +#include "pm8550.dtsi" > >> +#include "pm8550b.dtsi" > >> +#define PMK8550VE_SID 8 > >> +#include "pm8550ve.dtsi" > >> +#include "pm8550vs.dtsi" > >> +#include "pmk8550.dtsi" > >> + > >> +/ { > >> + aliases { > >> + serial1 = &uart14; > >> + }; > >> + > >> + vph_pwr: vph-pwr-regulator { }; > > > > Is this regulator a part of the module or a part of the carrier board? > > If the latter is true, this must go to the carrier board DT file. > > > > the vph_pwr regulator is defined in the aim500-aiot carrier board and used > in aim500 module. If it is defined in the carrier board, then please move it and corresponding supply entries to the carrier board dts. Other devices using the SoM can have different power tree. While we are at it, could you please rename the node to regulator-vph-pwr?
On 20/02/2024 10:11, Jingyi Wang wrote: > Hi Krzysztof, > > On 2/5/2024 8:35 PM, Krzysztof Kozlowski wrote: >> On 05/02/2024 12:57, Jingyi Wang wrote: >>> Introduce aim500 board dtsi. >>> >>> AIM500 Series is a highly optimized family of modules designed to >>> support AIoT and Generative AI applications based on sm8650p with >>> PMIC and bluetooth functions etc. >>> >>> Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >>> Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >>> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> >>> --- >>> arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ >>> 1 file changed, 409 insertions(+) >>> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>> >>> diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>> new file mode 100644 >>> index 000000000000..cb857da8653b >>> --- /dev/null >>> +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>> @@ -0,0 +1,409 @@ >>> +// SPDX-License-Identifier: BSD-3-Clause >>> +/* >>> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. >>> + */ >>> + >>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> >>> +#include "sm8650p.dtsi" >>> +#include "pm8550.dtsi" >>> +#include "pm8550b.dtsi" >>> +#define PMK8550VE_SID 8 >>> +#include "pm8550ve.dtsi" >>> +#include "pm8550vs.dtsi" >>> +#include "pmk8550.dtsi" >>> + >>> +/ { >>> + aliases { >>> + serial1 = &uart14; >>> + }; >>> + >>> + vph_pwr: vph-pwr-regulator { }; >> >> What is this? Why is it needed? >> >> >> Best regards, >> Krzysztof >> > vph_pwr is the power supply which differs from board design, it is defined in sm8650p-aim500-aiot.dts, > and it is used in the sm8650p-aim500.dts for regulator supply, so we leave the node here. How an empty, unused node is a power supply? Best regards, Krzysztof
Hi Dmitry, On 2/20/2024 5:19 PM, Dmitry Baryshkov wrote: > On Tue, 20 Feb 2024 at 11:17, Jingyi Wang <quic_jingyw@quicinc.com> wrote: >> >> Hi Dmitry, >> >> On 2/5/2024 10:23 PM, Dmitry Baryshkov wrote: >>> On Mon, 5 Feb 2024 at 14:00, Jingyi Wang <quic_jingyw@quicinc.com> wrote: >>>> >>>> Introduce aim500 board dtsi. >>> >>> So, is it a board or a module? >>> >> aim500 is a module, will fix the descrption. >> >>>> >>>> AIM500 Series is a highly optimized family of modules designed to >>>> support AIoT and Generative AI applications based on sm8650p with >>>> PMIC and bluetooth functions etc. >>>> >>>> Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >>>> Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >>>> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> >>>> --- >>>> arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ >>>> 1 file changed, 409 insertions(+) >>>> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>>> >>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>>> new file mode 100644 >>>> index 000000000000..cb857da8653b >>>> --- /dev/null >>>> +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>>> @@ -0,0 +1,409 @@ >>>> +// SPDX-License-Identifier: BSD-3-Clause >>>> +/* >>>> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. >>>> + */ >>>> + >>>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> >>>> +#include "sm8650p.dtsi" >>>> +#include "pm8550.dtsi" >>>> +#include "pm8550b.dtsi" >>>> +#define PMK8550VE_SID 8 >>>> +#include "pm8550ve.dtsi" >>>> +#include "pm8550vs.dtsi" >>>> +#include "pmk8550.dtsi" >>>> + >>>> +/ { >>>> + aliases { >>>> + serial1 = &uart14; >>>> + }; >>>> + >>>> + vph_pwr: vph-pwr-regulator { }; >>> >>> Is this regulator a part of the module or a part of the carrier board? >>> If the latter is true, this must go to the carrier board DT file. >>> >> >> the vph_pwr regulator is defined in the aim500-aiot carrier board and used >> in aim500 module. > > If it is defined in the carrier board, then please move it and > corresponding supply entries to the carrier board dts. Other devices > using the SoM can have different power tree. > > While we are at it, could you please rename the node to regulator-vph-pwr? > > will rename the node and move it to sm8650p-aim500-aiot.dts Thanks, Jingyi
On 2/20/2024 6:06 PM, Jingyi Wang wrote: > Hi Dmitry, > > On 2/20/2024 5:19 PM, Dmitry Baryshkov wrote: >> On Tue, 20 Feb 2024 at 11:17, Jingyi Wang <quic_jingyw@quicinc.com> wrote: >>> >>> Hi Dmitry, >>> >>> On 2/5/2024 10:23 PM, Dmitry Baryshkov wrote: >>>> On Mon, 5 Feb 2024 at 14:00, Jingyi Wang <quic_jingyw@quicinc.com> wrote: >>>>> >>>>> Introduce aim500 board dtsi. >>>> >>>> So, is it a board or a module? >>>> >>> aim500 is a module, will fix the descrption. >>> >>>>> >>>>> AIM500 Series is a highly optimized family of modules designed to >>>>> support AIoT and Generative AI applications based on sm8650p with >>>>> PMIC and bluetooth functions etc. >>>>> >>>>> Co-developed-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >>>>> Signed-off-by: Tingwei Zhang <quic_tingweiz@quicinc.com> >>>>> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> >>>>> --- >>>>> arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 +++++++++++++++++++ >>>>> 1 file changed, 409 insertions(+) >>>>> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>>>> >>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>>>> new file mode 100644 >>>>> index 000000000000..cb857da8653b >>>>> --- /dev/null >>>>> +++ b/arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi >>>>> @@ -0,0 +1,409 @@ >>>>> +// SPDX-License-Identifier: BSD-3-Clause >>>>> +/* >>>>> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. >>>>> + */ >>>>> + >>>>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> >>>>> +#include "sm8650p.dtsi" >>>>> +#include "pm8550.dtsi" >>>>> +#include "pm8550b.dtsi" >>>>> +#define PMK8550VE_SID 8 >>>>> +#include "pm8550ve.dtsi" >>>>> +#include "pm8550vs.dtsi" >>>>> +#include "pmk8550.dtsi" >>>>> + >>>>> +/ { >>>>> + aliases { >>>>> + serial1 = &uart14; >>>>> + }; >>>>> + >>>>> + vph_pwr: vph-pwr-regulator { }; >>>> >>>> Is this regulator a part of the module or a part of the carrier board? >>>> If the latter is true, this must go to the carrier board DT file. >>>> >>> >>> the vph_pwr regulator is defined in the aim500-aiot carrier board and used >>> in aim500 module. >> >> If it is defined in the carrier board, then please move it and >> corresponding supply entries to the carrier board dts. Other devices >> using the SoM can have different power tree. >> >> While we are at it, could you please rename the node to regulator-vph-pwr? >> >> > will rename the node and move it to sm8650p-aim500-aiot.dts Shall we have the VPH_PWR implementation inside the board dts file, and have the supply entries which used the VPH_PWR inside the SOM.dtsi file? The VPH_PWR is an input IO of SOM. And the corresponding supply entries is inside the SOM hardware design as well. The VPH_PWR as a fixed regulator implementation is the board design, it can be changed to other design from different boards. Here is a simple diagram to show the hardware description of the VPH_PWR related design: +------------------------------------------------------+ | Board | | | | +-----------------+ | |power----->| Fixed regulator-----------+ | | +-----------------+ | | | | | | v VPH_PWR | | +------|----------------------+ | | | | SOM | | | | | | | | | | | vVPH_PWR vVPM_PWR| | | | +------+ +------+ | | | | | pmic1| |pmic2 | | | | | +------+ +------+ | | | | | | | +-----------------------------+ | +------------------------------------------------------+ > > Thanks, > Jingyi
On 05/02/2024 12:57, Jingyi Wang wrote: > Introduce sm8650p dtsi, sm8650p has same base functions > as sm8650 with different memory regions. > > There are 3 types of reserved memory regions here: > 1. Firmware related regions. > This will be described as: reserved-region@address. Current > reserved-region may have reserved area which was not yet used, release > note of the firmware can have such kind of information. > 2. Firmware related which shared with kernel access. > Each region will have a specific node with specific label name for > later phandle reference from other driver dt node. May overlapping with > above type regions. > 3. PIL regions. > PIL regions are allocated by kernel and assigned to subsystem > firmware later. > Here is a map for this platform: > 0x100000000 +------------------+ > | | > | Firmware Related | > | | > 0xd8000000 +------------------+ > | | > | Kernel Available | > | | > 0xA7000000 +------------------+ > | | > | PIL Region | > | | > 0x8BC00000 +------------------+ > | | > | Firmware Related | > | | > 0x80000000 +------------------+ > Note that: > 1. 0xA7000000 to 0xA8000000 was used by bootloader as well, not suggest > for other usage. > 2. Kernel start address was start at 0xA8000000. > > Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> > --- > arch/arm64/boot/dts/qcom/sm8650p.dtsi | 180 ++++++++++++++++++++++++++ > 1 file changed, 180 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/sm8650p.dtsi > > diff --git a/arch/arm64/boot/dts/qcom/sm8650p.dtsi b/arch/arm64/boot/dts/qcom/sm8650p.dtsi > new file mode 100644 > index 000000000000..26dfe315b49d > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/sm8650p.dtsi > @@ -0,0 +1,180 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include "sm8650.dtsi" > + > +/delete-node/ &reserved_memory; > + > +/ { > + reserved_memory: reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + /* > + * There are 3 types of reserved memory regions here: > + * 1. Firmware related regions. > + * This will be described as: reserved-region@address. Current > + * reserved-region may have reserved area which was not yet used, > + * release note of the firmware can have such kind of information. > + * 2. Firmware related which shared with kernel access. > + * Each region will have a specific node with specific label > + * name for later phandle reference from other driver dt node. May > + * overlapping with above type regions. > + * 3. PIL regions. > + * PIL regions are allocated by kernel and assigned to subsystem > + * firmware later. > + * Here is a map for this platform: > + * 0x100000000 +------------------+ > + * | | > + * | Firmware Related | > + * | | > + * 0xd8000000 +------------------+ > + * | | > + * | Kernel Available | > + * | | > + * 0xA7000000 +------------------+ > + * | | > + * | PIL Region | > + * | | > + * 0x8BC00000 +------------------+ > + * | | > + * | Firmware Related | > + * | | > + * 0x80000000 +------------------+ > + * Note that: > + * 1. 0xA7000000 to 0xA8000000 was used by bootloader as well, not > + * suggest for other usage. > + * 2. Kernel start address was start at 0xA8000000. > + */ > + > + /* Firmware related regions */ > + reserved-region@80000000 { > + reg = <0x0 0x80000000 0x0 0xbc00000>; > + no-map; > + }; Ok this region goes up to 0x8BC00000 and so overlaps with the next regions: > + > + aop_image_mem: aop-image-region@81c00000 { > + reg = <0x0 0x81c00000 0x0 0x60000>; > + no-map; > + }; > + > + aop_cmd_db_mem: aop-cmd-db-region@81c60000 { > + compatible = "qcom,cmd-db"; > + reg = <0x0 0x81c60000 0x0 0x20000>; > + no-map; > + }; > + > + aop_config_mem: aop-config-region@81c80000 { > + no-map; > + reg = <0x0 0x81c80000 0x0 0x20000>; > + }; > + > + smem_mem: smem-region@81d00000 { > + compatible = "qcom,smem"; > + reg = <0x0 0x81d00000 0x0 0x200000>; > + hwlocks = <&tcsr_mutex 3>; > + no-map; > + }; > + > + adsp_mhi_mem: adsp-mhi-region@81f00000 { > + reg = <0x0 0x81f00000 0x0 0x20000>; > + no-map; > + }; > + > + global_sync_mem: global-sync@82600000 { > + reg = <0 0x82600000 0 0x100000>; > + no-map; > + }; > + > + mpss_dsm_mem: mpss-dsm@86b00000 { > + reg = <0 0x86b00000 0 0x4900000>; > + no-map; > + }; > + > + mpss_dsm_mem_2: mpss-dsm-2@8b400000 { > + reg = <0 0x8b400000 0 0x800000>; > + no-map; > + }; up to here Please fix this, I just checked against plain sm8650.dtsi and actually the memory adresses are the same. So what's the _real_ difference here ? Just drop the superfluous memory zones and redefine them if needed. Thanks, Neil > + > + /* PIL region */ > + mpss_mem: mpss-region@8bc00000 { > + reg = <0x0 0x8bc00000 0x0 0xf400000>; > + no-map; > + }; > + > + q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 { > + reg = <0x0 0x9b000000 0x0 0x80000>; > + no-map; > + }; > + > + ipa_fw_mem: ipa-fw-region@9b080000 { > + reg = <0x0 0x9b080000 0x0 0x10000>; > + no-map; > + }; > + > + ipa_gsi_mem: ipa-gsi-region@9b090000 { > + reg = <0x0 0x9b090000 0x0 0xa000>; > + no-map; > + }; > + > + gpu_micro_code_mem: gpu-micro-code-region@9b09a000 { > + reg = <0x0 0x9b09a000 0x0 0x2000>; > + no-map; > + }; > + > + spss_region_mem: spss-region@9b0a0000 { > + reg = <0x0 0x9b0a0000 0x0 0x1e0000>; > + no-map; > + }; > + > + spu_secure_shared_memory_mem: spu-secure-shared-memory-region@9b280000 { > + reg = <0x0 0x9b280000 0x0 0x80000>; > + no-map; > + }; > + > + camera_mem: camera-region@9b300000 { > + reg = <0x0 0x9b300000 0x0 0x800000>; > + no-map; > + }; > + > + video_mem: video-region@9bb00000 { > + reg = <0x0 0x9bb00000 0x0 0x800000>; > + no-map; > + }; > + > + cvp_mem: cvp-region@9c300000 { > + reg = <0x0 0x9c300000 0x0 0x700000>; > + no-map; > + }; > + > + cdsp_mem: cdsp-region@9ca00000 { > + reg = <0x0 0x9ca00000 0x0 0x1400000>; > + no-map; > + }; > + > + q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9de00000 { > + reg = <0x0 0x9de00000 0x0 0x80000>; > + no-map; > + }; > + > + q6_adsp_dtb_mem: q6-adsp-dtb-region@9de80000 { > + reg = <0x0 0x9de80000 0x0 0x80000>; > + no-map; > + }; > + > + adspslpi_mem: adspslpi-region@9df00000 { > + reg = <0x0 0x9df00000 0x0 0x4080000>; > + no-map; > + }; > + > + /* Firmware related regions */ > + reserved-region@d8000000 { > + reg = <0x0 0xd8000000 0x0 0x28000000>; > + no-map; > + }; > + > + }; > +};
On 2/22/2024 9:21 PM, neil.armstrong@linaro.org wrote: > On 05/02/2024 12:57, Jingyi Wang wrote: >> Introduce sm8650p dtsi, sm8650p has same base functions >> as sm8650 with different memory regions. >> >> There are 3 types of reserved memory regions here: >> 1. Firmware related regions. >> This will be described as: reserved-region@address. Current >> reserved-region may have reserved area which was not yet used, release >> note of the firmware can have such kind of information. >> 2. Firmware related which shared with kernel access. >> Each region will have a specific node with specific label name for >> later phandle reference from other driver dt node. May overlapping with >> above type regions. >> 3. PIL regions. >> PIL regions are allocated by kernel and assigned to subsystem >> firmware later. >> Here is a map for this platform: >> 0x100000000 +------------------+ >> | | >> | Firmware Related | >> | | >> 0xd8000000 +------------------+ >> | | >> | Kernel Available | >> | | >> 0xA7000000 +------------------+ >> | | >> | PIL Region | >> | | >> 0x8BC00000 +------------------+ >> | | >> | Firmware Related | >> | | >> 0x80000000 +------------------+ >> Note that: >> 1. 0xA7000000 to 0xA8000000 was used by bootloader as well, not suggest >> for other usage. >> 2. Kernel start address was start at 0xA8000000. >> >> Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> >> --- >> arch/arm64/boot/dts/qcom/sm8650p.dtsi | 180 ++++++++++++++++++++++++++ >> 1 file changed, 180 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/sm8650p.dtsi >> >> diff --git a/arch/arm64/boot/dts/qcom/sm8650p.dtsi >> b/arch/arm64/boot/dts/qcom/sm8650p.dtsi >> new file mode 100644 >> index 000000000000..26dfe315b49d >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sm8650p.dtsi >> @@ -0,0 +1,180 @@ >> +// SPDX-License-Identifier: BSD-3-Clause >> +/* >> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights >> reserved. >> + */ >> + >> +#include "sm8650.dtsi" >> + >> +/delete-node/ &reserved_memory; >> + >> +/ { >> + reserved_memory: reserved-memory { >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; >> + >> + /* >> + * There are 3 types of reserved memory regions here: >> + * 1. Firmware related regions. >> + * This will be described as: reserved-region@address. >> Current >> + * reserved-region may have reserved area which was not yet >> used, >> + * release note of the firmware can have such kind of >> information. >> + * 2. Firmware related which shared with kernel access. >> + * Each region will have a specific node with specific label >> + * name for later phandle reference from other driver dt >> node. May >> + * overlapping with above type regions. >> + * 3. PIL regions. >> + * PIL regions are allocated by kernel and assigned to >> subsystem >> + * firmware later. >> + * Here is a map for this platform: >> + * 0x100000000 +------------------+ >> + * | | >> + * | Firmware Related | >> + * | | >> + * 0xd8000000 +------------------+ >> + * | | >> + * | Kernel Available | >> + * | | >> + * 0xA7000000 +------------------+ >> + * | | >> + * | PIL Region | >> + * | | >> + * 0x8BC00000 +------------------+ >> + * | | >> + * | Firmware Related | >> + * | | >> + * 0x80000000 +------------------+ >> + * Note that: >> + * 1. 0xA7000000 to 0xA8000000 was used by bootloader as >> well, not >> + * suggest for other usage. >> + * 2. Kernel start address was start at 0xA8000000. >> + */ >> + >> + /* Firmware related regions */ >> + reserved-region@80000000 { >> + reg = <0x0 0x80000000 0x0 0xbc00000>; >> + no-map; >> + }; > > Ok this region goes up to 0x8BC00000 and so overlaps with the next regions: The idea here is to reserve more needed ddr regions for different version of firmware compatibility. While inside this region which shared device memory from firmware to kernel, it is still needed to have node information in the device tree. More clear reference here for the firmware needed no-map reserved region diagram, take the smem_mem here to be exposed shared read to kernel: * 0x8BC00000 +------------------+ * | | * | reserved_region2 | * 0x81c60000 +------------------+ * | smem_mem | * 0x81c00000 +------------------+ * | reserved_region1| * 0x80000000 +------------------+ what's the suggestion here for this requirement?: option 1: have a big region_reserved, and then have smem_mem overlap reserved region node information inside the dt. option 2: Have each separate "reserved_region1 node + smem_mem node + reserved_region2 node". other options? > >> + >> + aop_image_mem: aop-image-region@81c00000 { >> + reg = <0x0 0x81c00000 0x0 0x60000>; >> + no-map; >> + }; >> + >> + aop_cmd_db_mem: aop-cmd-db-region@81c60000 { >> + compatible = "qcom,cmd-db"; >> + reg = <0x0 0x81c60000 0x0 0x20000>; >> + no-map; >> + }; >> + >> + aop_config_mem: aop-config-region@81c80000 { >> + no-map; >> + reg = <0x0 0x81c80000 0x0 0x20000>; >> + }; >> + >> + smem_mem: smem-region@81d00000 { >> + compatible = "qcom,smem"; >> + reg = <0x0 0x81d00000 0x0 0x200000>; >> + hwlocks = <&tcsr_mutex 3>; >> + no-map; >> + }; >> + >> + adsp_mhi_mem: adsp-mhi-region@81f00000 { >> + reg = <0x0 0x81f00000 0x0 0x20000>; >> + no-map; >> + }; >> + >> + global_sync_mem: global-sync@82600000 { >> + reg = <0 0x82600000 0 0x100000>; >> + no-map; >> + }; >> + >> + mpss_dsm_mem: mpss-dsm@86b00000 { >> + reg = <0 0x86b00000 0 0x4900000>; >> + no-map; >> + }; >> + >> + mpss_dsm_mem_2: mpss-dsm-2@8b400000 { >> + reg = <0 0x8b400000 0 0x800000>; >> + no-map; >> + }; > > up to here > > Please fix this, > > I just checked against plain sm8650.dtsi and actually the memory > adresses are the same. > > So what's the _real_ difference here ? Just drop the superfluous memory > zones and redefine them if needed. With big reserved regions agreed, I think the memory map can be modified directly in sm8650.dtsi. It will be a memory map support different derived soc firmware release as well. > > Thanks, > Neil > >> + >> + /* PIL region */ >> + mpss_mem: mpss-region@8bc00000 { >> + reg = <0x0 0x8bc00000 0x0 0xf400000>; >> + no-map; >> + }; >> + >> + q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 { >> + reg = <0x0 0x9b000000 0x0 0x80000>; >> + no-map; >> + }; >> + >> + ipa_fw_mem: ipa-fw-region@9b080000 { >> + reg = <0x0 0x9b080000 0x0 0x10000>; >> + no-map; >> + }; >> + >> + ipa_gsi_mem: ipa-gsi-region@9b090000 { >> + reg = <0x0 0x9b090000 0x0 0xa000>; >> + no-map; >> + }; >> + >> + gpu_micro_code_mem: gpu-micro-code-region@9b09a000 { >> + reg = <0x0 0x9b09a000 0x0 0x2000>; >> + no-map; >> + }; >> + >> + spss_region_mem: spss-region@9b0a0000 { >> + reg = <0x0 0x9b0a0000 0x0 0x1e0000>; >> + no-map; >> + }; >> + >> + spu_secure_shared_memory_mem: >> spu-secure-shared-memory-region@9b280000 { >> + reg = <0x0 0x9b280000 0x0 0x80000>; >> + no-map; >> + }; >> + >> + camera_mem: camera-region@9b300000 { >> + reg = <0x0 0x9b300000 0x0 0x800000>; >> + no-map; >> + }; >> + >> + video_mem: video-region@9bb00000 { >> + reg = <0x0 0x9bb00000 0x0 0x800000>; >> + no-map; >> + }; >> + >> + cvp_mem: cvp-region@9c300000 { >> + reg = <0x0 0x9c300000 0x0 0x700000>; >> + no-map; >> + }; >> + >> + cdsp_mem: cdsp-region@9ca00000 { >> + reg = <0x0 0x9ca00000 0x0 0x1400000>; >> + no-map; >> + }; >> + >> + q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9de00000 { >> + reg = <0x0 0x9de00000 0x0 0x80000>; >> + no-map; >> + }; >> + >> + q6_adsp_dtb_mem: q6-adsp-dtb-region@9de80000 { >> + reg = <0x0 0x9de80000 0x0 0x80000>; >> + no-map; >> + }; >> + >> + adspslpi_mem: adspslpi-region@9df00000 { >> + reg = <0x0 0x9df00000 0x0 0x4080000>; >> + no-map; >> + }; >> + >> + /* Firmware related regions */ >> + reserved-region@d8000000 { >> + reg = <0x0 0xd8000000 0x0 0x28000000>; >> + no-map; >> + }; >> + >> + }; >> +}; >
Add the device tree for the AIM500 AIoT board along with usb, regulators, serial and PCIe found in this board. AIM500 Series is a highly optimized family of modules designed to support AIoT and Generative AI applications which is based on SM8650P soc with addtional functions like PMIC and bluetooth. And AIM500 AIoT is mounted onto Qualcomm AIoT carrier board to support verification, evaluation and development. Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> --- This patch series has some open discussion topics depend on [1], including: 1. memory map will have a large reserved region for firmware related, since currently firmware features are still in developing and easily to be changed. 2. vph_pwr was open whether it should be put in som.dtsi, or board.dts. we can see vph_pwr may have different design and implementation from different boards design, while vph_pwr needed to be one of the som input, and then the vph_pwr is used inside som to different pmics input. So we proposed have the definition in som.dtsi, and have it's own implementation in board.dts. 3. board compatible like aim300-aiot was open whether can be added or not. We added currently since it will fail dt binding check if not. [1] https://lore.kernel.org/linux-arm-msm/20240119100621.11788-1-quic_tengfan@quicinc.com/#t And we got following error while doing dtb check: sm8650p-aim500-aiot.dtb: usb@a6f8800: interrupt-names: ['hs_phy_irq', 'ss_phy_irq', 'dm_hs_phy_irq', 'dp_hs_phy_irq'] is too short Which should be caused by missing intertupt name "pwr_event" in sm8650.dtsi Jingyi Wang (6): dt-bindings: arm: qcom: Document sm8650p soc and AIM500 AIoT board dt-bindings: arm: qcom,ids: Add SoC ID for SM8650P soc: qcom: socinfo: Add SM8650P SoC ID table entry arm64: dts: qcom: sm8650p: introduce sm8650p dtsi arm64: dts: qcom: add base AIM500 dtsi arm64: dts: qcom: add AIM500 AIoT .../devicetree/bindings/arm/qcom.yaml | 9 + arch/arm64/boot/dts/qcom/Makefile | 1 + .../boot/dts/qcom/sm8650p-aim500-aiot.dts | 314 ++++++++++++++ arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi | 409 ++++++++++++++++++ arch/arm64/boot/dts/qcom/sm8650p.dtsi | 180 ++++++++ drivers/soc/qcom/socinfo.c | 1 + include/dt-bindings/arm/qcom,ids.h | 1 + 7 files changed, 915 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500-aiot.dts create mode 100644 arch/arm64/boot/dts/qcom/sm8650p-aim500.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sm8650p.dtsi -- base-commit: 076d56d74f17e625b3d63cf4743b3d7d02180379 2.25.1