| Message ID | 20221201171931.1919961-1-bmasney@redhat.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] arm64: dts: qcom: sa8540p-ride: enable PCIe support | expand |
On Thu, Dec 01, 2022 at 12:19:31PM -0500, Brian Masney wrote: > Add the vreg_l11a, pcie3a, pcie3a_phy, and tlmm nodes that are necessary > in order to get PCIe working on the QDrive3. > > This patch also increases the width of the ranges property for the PCIe > switch that's found on this platform. Note that this change requires > the latest trustzone (TZ) firmware that's available from Qualcomm as > of November 2022. If this is used against a board with the older > firmware, then the board will go into ramdump mode when PCIe is probed > on startup. > > The ranges property is overridden in this sa8540p-ride.dts file since > this is what's used to describe the QDrive3 variant with dual SoCs. > There's another variant of this board that only has a single SoC where > this change is not applicable, and hence why this specific change was > not done in sa8540p.dtsi. > > These changes were derived from various patches that Qualcomm > delivered to Red Hat in a downstream kernel. > > Signed-off-by: Brian Masney <bmasney@redhat.com> > --- > Changes since v1: > - Add -state and -pins suffixes to tlmm (Krzysztof) > > This patch depends on the following series that hasn't made it's way > into linux-next yet: > > [PATCH v10 0/2] arm64: dts: qcom: add dts for sa8540p-ride board > https://lore.kernel.org/lkml/20221118025158.16902-1-quic_ppareek@quicinc.com/ > > I can't find the specific TZ firmware version that we have so that's why > I included the date instead. > > arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 54 +++++++++++++++++++++++ > 1 file changed, 54 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts > index a5f87a8629d6..e953165f3b73 100644 > --- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts > +++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts > @@ -51,6 +51,14 @@ vreg_l7a: ldo7 { > regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > }; > > + vreg_l11a: ldo11 { > + regulator-name = "vreg_l11a"; > + regulator-min-microvolt = <880000>; > + regulator-max-microvolt = <880000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + regulator-allow-set-load; In order to specify regulator-allow-set-load you also need regulator-allowed-modes. But if I read the implementation correction, we don't actually alter the load, so perhaps best to just omit this for now? Regards, Bjorn > + }; > + > vreg_l13a: ldo13 { > regulator-name = "vreg_l13a"; > regulator-min-microvolt = <3072000>; > @@ -139,6 +147,27 @@ vreg_l8g: ldo8 { > }; > }; > > +&pcie3a { > + ranges = <0x01000000 0x0 0x32200000 0x0 0x32200000 0x0 0x100000>, > + <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x20000000>, > + <0x03000000 0x6 0x00000000 0x6 0x00000000 0x2 0x00000000>; > + > + perst-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>; > + wake-gpios = <&tlmm 56 GPIO_ACTIVE_HIGH>; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&pcie3a_default>; > + > + status = "okay"; > +}; > + > +&pcie3a_phy { > + vdda-phy-supply = <&vreg_l11a>; > + vdda-pll-supply = <&vreg_l3a>; > + > + status = "okay"; > +}; > + > &qup2 { > status = "okay"; > }; > @@ -158,6 +187,31 @@ &remoteproc_nsp1 { > status = "okay"; > }; > > +&tlmm { > + pcie3a_default: pcie3a-default-state { > + perst-pins { > + pins = "gpio151"; > + function = "gpio"; > + drive-strength = <2>; > + bias-pull-down; > + }; > + > + clkreq-pins { > + pins = "gpio150"; > + function = "pcie3a_clkreq"; > + drive-strength = <2>; > + bias-pull-up; > + }; > + > + wake-pins { > + pins = "gpio56"; > + function = "gpio"; > + drive-strength = <2>; > + bias-pull-up; > + }; > + }; > +}; > + > &ufs_mem_hc { > reset-gpios = <&tlmm 228 GPIO_ACTIVE_LOW>; > > -- > 2.38.1 >
On Thu, Dec 01, 2022 at 04:30:12PM -0600, Bjorn Andersson wrote: > On Thu, Dec 01, 2022 at 12:19:31PM -0500, Brian Masney wrote: > > + vreg_l11a: ldo11 { > > + regulator-name = "vreg_l11a"; > > + regulator-min-microvolt = <880000>; > > + regulator-max-microvolt = <880000>; > > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > > + regulator-allow-set-load; > > In order to specify regulator-allow-set-load you also need > regulator-allowed-modes. > > But if I read the implementation correction, we don't actually alter the > load, so perhaps best to just omit this for now? I can drop regulator-allow-set-load in v3. I almost left it off and verified the other day that PCIe still works without it. Brian
diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts index a5f87a8629d6..e953165f3b73 100644 --- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts +++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts @@ -51,6 +51,14 @@ vreg_l7a: ldo7 { regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; }; + vreg_l11a: ldo11 { + regulator-name = "vreg_l11a"; + regulator-min-microvolt = <880000>; + regulator-max-microvolt = <880000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-allow-set-load; + }; + vreg_l13a: ldo13 { regulator-name = "vreg_l13a"; regulator-min-microvolt = <3072000>; @@ -139,6 +147,27 @@ vreg_l8g: ldo8 { }; }; +&pcie3a { + ranges = <0x01000000 0x0 0x32200000 0x0 0x32200000 0x0 0x100000>, + <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x20000000>, + <0x03000000 0x6 0x00000000 0x6 0x00000000 0x2 0x00000000>; + + perst-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>; + wake-gpios = <&tlmm 56 GPIO_ACTIVE_HIGH>; + + pinctrl-names = "default"; + pinctrl-0 = <&pcie3a_default>; + + status = "okay"; +}; + +&pcie3a_phy { + vdda-phy-supply = <&vreg_l11a>; + vdda-pll-supply = <&vreg_l3a>; + + status = "okay"; +}; + &qup2 { status = "okay"; }; @@ -158,6 +187,31 @@ &remoteproc_nsp1 { status = "okay"; }; +&tlmm { + pcie3a_default: pcie3a-default-state { + perst-pins { + pins = "gpio151"; + function = "gpio"; + drive-strength = <2>; + bias-pull-down; + }; + + clkreq-pins { + pins = "gpio150"; + function = "pcie3a_clkreq"; + drive-strength = <2>; + bias-pull-up; + }; + + wake-pins { + pins = "gpio56"; + function = "gpio"; + drive-strength = <2>; + bias-pull-up; + }; + }; +}; + &ufs_mem_hc { reset-gpios = <&tlmm 228 GPIO_ACTIVE_LOW>;
Add the vreg_l11a, pcie3a, pcie3a_phy, and tlmm nodes that are necessary in order to get PCIe working on the QDrive3. This patch also increases the width of the ranges property for the PCIe switch that's found on this platform. Note that this change requires the latest trustzone (TZ) firmware that's available from Qualcomm as of November 2022. If this is used against a board with the older firmware, then the board will go into ramdump mode when PCIe is probed on startup. The ranges property is overridden in this sa8540p-ride.dts file since this is what's used to describe the QDrive3 variant with dual SoCs. There's another variant of this board that only has a single SoC where this change is not applicable, and hence why this specific change was not done in sa8540p.dtsi. These changes were derived from various patches that Qualcomm delivered to Red Hat in a downstream kernel. Signed-off-by: Brian Masney <bmasney@redhat.com> --- Changes since v1: - Add -state and -pins suffixes to tlmm (Krzysztof) This patch depends on the following series that hasn't made it's way into linux-next yet: [PATCH v10 0/2] arm64: dts: qcom: add dts for sa8540p-ride board https://lore.kernel.org/lkml/20221118025158.16902-1-quic_ppareek@quicinc.com/ I can't find the specific TZ firmware version that we have so that's why I included the date instead. arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 54 +++++++++++++++++++++++ 1 file changed, 54 insertions(+)