[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c962760-d81c-af52-bce2-49090f66f4ee@quicinc.com>
Date: Mon, 8 May 2023 16:25:10 +0530
From: Devi Priya <quic_devipriy@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: <agross@...nel.org>, <andersson@...nel.org>,
<konrad.dybcio@...aro.org>, <lpieralisi@...nel.org>,
<kw@...ux.com>, <robh@...nel.org>, <bhelgaas@...gle.com>,
<krzysztof.kozlowski+dt@...aro.org>, <mturquette@...libre.com>,
<sboyd@...nel.org>, <mani@...nel.org>,
<linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
<linux-clk@...r.kernel.org>, <quic_srichara@...cinc.com>,
<quic_sjaganat@...cinc.com>, <quic_kathirav@...cinc.com>,
<quic_arajkuma@...cinc.com>, <quic_anusha@...cinc.com>,
<quic_ipkumar@...cinc.com>
Subject: Re: [PATCH V3 5/6] arm64: dts: qcom: ipq9574: Enable PCIe PHYs and
controllers
On 4/22/2023 5:43 AM, Dmitry Baryshkov wrote:
> On Fri, 21 Apr 2023 at 15:51, Devi Priya <quic_devipriy@...cinc.com> wrote:
>>
>> Enable the PCIe controller and PHY nodes corresponding to
>> RDP 433.
>>
>> Signed-off-by: Devi Priya <quic_devipriy@...cinc.com>
>> ---
>> Changes in V3:
>> - No change
>>
>> arch/arm64/boot/dts/qcom/ipq9574-rdp433.dts | 62 +++++++++++++++++++++
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq9574-rdp433.dts b/arch/arm64/boot/dts/qcom/ipq9574-rdp433.dts
>> index 7be578017bf7..3ae38cf327ea 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq9574-rdp433.dts
>> +++ b/arch/arm64/boot/dts/qcom/ipq9574-rdp433.dts
>> @@ -8,6 +8,7 @@
>>
>> /dts-v1/;
>>
>> +#include <dt-bindings/gpio/gpio.h>
>> #include "ipq9574.dtsi"
>>
>> / {
>> @@ -43,6 +44,42 @@
>> };
>> };
>>
>> +&pcie1_phy {
>> + status = "okay";
>> +};
>> +
>> +&pcie1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie_1_pin>;
>> +
>> + perst-gpios = <&tlmm 26 GPIO_ACTIVE_LOW>;
>
> Usually qcom PCIe hosts also define wake-gpios.
In IPQ9574, we do not have hot plug support and host always starts the
enumeration for the device. Hence no wake pin is required.
>
>> + status = "okay";
>> +};
>> +
>> +&pcie2_phy {
>> + status = "okay";
>> +};
>> +
>> +&pcie2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie_2_pin>;
>> +
>> + perst-gpios = <&tlmm 29 GPIO_ACTIVE_LOW>;
>> + status = "okay";
>> +};
>> +
>> +&pcie3_phy {
>> + status = "okay";
>> +};
>> +
>> +&pcie3 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie_3_pin>;
>> +
>> + perst-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
>> + status = "okay";
>> +};
>> +
>> &sdhc_1 {
>> pinctrl-0 = <&sdc_default_state>;
>> pinctrl-names = "default";
>> @@ -60,6 +97,31 @@
>> };
>>
>> &tlmm {
>> +
>> + pcie_1_pin: pcie-1-state {
>> + pins = "gpio26";
>> + function = "gpio";
>> + drive-strength = <8>;
>> + bias-pull-down;
>> + output-low;
>
> No clkreq and no wake gpios?
We do not use any PCIe low power states and link is always in L0.
Thanks,
Devi Priya
>
>> + };
>> +
>> + pcie_2_pin: pcie-2-state {
>> + pins = "gpio29";
>> + function = "gpio";
>> + drive-strength = <8>;
>> + bias-pull-down;
>> + output-low;
>> + };
>> +
>> + pcie_3_pin: pcie-3-state {
>> + pins = "gpio32";
>> + function = "gpio";
>> + drive-strength = <8>;
>> + bias-pull-up;
>> + output-low;
>> + };
>> +
>> sdc_default_state: sdc-default-state {
>> clk-pins {
>> pins = "gpio5";
>> --
>> 2.17.1
>>
>
>
Powered by blists - more mailing lists