| Message ID | 20240512082858.1806694-1-quic_devipriy@quicinc.com |
|---|---|
| Headers | show |
| Series | Add PCIe support for IPQ9574 | expand |
On Sun, May 12, 2024 at 01:58:56PM +0530, devi priya wrote: > Add PCIe0, PCIe1, PCIe2, PCIe3 (and corresponding PHY) devices > found on IPQ9574 platform. The PCIe0 & PCIe1 are 1-lane Gen3 > host whereas PCIe2 & PCIe3 are 2-lane Gen3 host. > > Signed-off-by: devi priya <quic_devipriy@quicinc.com> > --- > Changes in V5: > - Dropped anoc and snoc lane clocks from Phy nodes and enabled them > via interconnect. > - Dropped msi-parent as it is handled via msi IRQ > > arch/arm64/boot/dts/qcom/ipq9574.dtsi | 365 +++++++++++++++++++++++++- > 1 file changed, 361 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi > index 5b3e69379b1f..da6418c9d52b 100644 > --- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi > +++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi [...] > + pcie1: pci@10000000 { 'pcie@' since this is a PCIe controller. > + compatible = "qcom,pcie-ipq9574"; > + reg = <0x10000000 0xf1d>, > + <0x10000F20 0xa8>, Please use lower case for hex everywhere. > + <0x10001000 0x1000>, > + <0x000F8000 0x4000>, > + <0x10100000 0x1000>; > + reg-names = "dbi", "elbi", "atu", "parf", "config"; > + device_type = "pci"; > + linux,pci-domain = <2>; > + bus-range = <0x00 0xff>; > + num-lanes = <1>; > + #address-cells = <3>; > + #size-cells = <2>; > + > + ranges = <0x01000000 0x0 0x00000000 0x10200000 0x0 0x100000>, /* I/O */ > + <0x02000000 0x0 0x10300000 0x10300000 0x0 0x7d00000>; /* MEM */ > + > + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "msi"; Are you sure that this platform only has single MSI SPI IRQ? > + #interrupt-cells = <1>; > + interrupt-map-mask = <0 0 0 0x7>; > + interrupt-map = <0 0 0 1 &intc 0 0 35 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ > + <0 0 0 2 &intc 0 0 49 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ > + <0 0 0 3 &intc 0 0 84 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ > + <0 0 0 4 &intc 0 0 85 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ > + > + /* clocks and clock-names are used to enable the clock in CBCR */ This comment is redundant. > + clocks = <&gcc GCC_PCIE1_AHB_CLK>, > + <&gcc GCC_PCIE1_AUX_CLK>, > + <&gcc GCC_PCIE1_AXI_M_CLK>, > + <&gcc GCC_PCIE1_AXI_S_CLK>, > + <&gcc GCC_PCIE1_AXI_S_BRIDGE_CLK>, > + <&gcc GCC_PCIE1_RCHNG_CLK>; > + clock-names = "ahb", > + "aux", > + "axi_m", > + "axi_s", > + "axi_bridge", > + "rchng"; > + > + resets = <&gcc GCC_PCIE1_PIPE_ARES>, > + <&gcc GCC_PCIE1_CORE_STICKY_ARES>, > + <&gcc GCC_PCIE1_AXI_S_STICKY_ARES>, > + <&gcc GCC_PCIE1_AXI_S_ARES>, > + <&gcc GCC_PCIE1_AXI_M_STICKY_ARES>, > + <&gcc GCC_PCIE1_AXI_M_ARES>, > + <&gcc GCC_PCIE1_AUX_ARES>, > + <&gcc GCC_PCIE1_AHB_ARES>; > + reset-names = "pipe", > + "sticky", > + "axi_s_sticky", > + "axi_s", > + "axi_m_sticky", > + "axi_m", > + "aux", > + "ahb"; > + > + phys = <&pcie1_phy>; > + phy-names = "pciephy"; > + interconnects = <&gcc MASTER_ANOC_PCIE1 &gcc SLAVE_ANOC_PCIE1>, > + <&gcc MASTER_SNOC_PCIE1 &gcc SLAVE_SNOC_PCIE1>; Is this really the interconnect paths between PCIe-DDR and PCIe-CPU? I doubt... - Mani
On 5/14/2024 1:09 PM, Manivannan Sadhasivam wrote: > On Sun, May 12, 2024 at 01:58:56PM +0530, devi priya wrote: >> Add PCIe0, PCIe1, PCIe2, PCIe3 (and corresponding PHY) devices >> found on IPQ9574 platform. The PCIe0 & PCIe1 are 1-lane Gen3 >> host whereas PCIe2 & PCIe3 are 2-lane Gen3 host. >> >> Signed-off-by: devi priya <quic_devipriy@quicinc.com> >> --- >> Changes in V5: >> - Dropped anoc and snoc lane clocks from Phy nodes and enabled them >> via interconnect. >> - Dropped msi-parent as it is handled via msi IRQ >> >> arch/arm64/boot/dts/qcom/ipq9574.dtsi | 365 +++++++++++++++++++++++++- >> 1 file changed, 361 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi >> index 5b3e69379b1f..da6418c9d52b 100644 >> --- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi >> +++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi > > [...] > >> + pcie1: pci@10000000 { > > 'pcie@' since this is a PCIe controller. okay > >> + compatible = "qcom,pcie-ipq9574"; >> + reg = <0x10000000 0xf1d>, >> + <0x10000F20 0xa8>, > > Please use lower case for hex everywhere. okay > >> + <0x10001000 0x1000>, >> + <0x000F8000 0x4000>, >> + <0x10100000 0x1000>; >> + reg-names = "dbi", "elbi", "atu", "parf", "config"; >> + device_type = "pci"; >> + linux,pci-domain = <2>; >> + bus-range = <0x00 0xff>; >> + num-lanes = <1>; >> + #address-cells = <3>; >> + #size-cells = <2>; >> + >> + ranges = <0x01000000 0x0 0x00000000 0x10200000 0x0 0x100000>, /* I/O */ >> + <0x02000000 0x0 0x10300000 0x10300000 0x0 0x7d00000>; /* MEM */ >> + >> + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; >> + interrupt-names = "msi"; > > Are you sure that this platform only has single MSI SPI IRQ? It has 8 MSI SPI IRQs, will define all of them > >> + #interrupt-cells = <1>; >> + interrupt-map-mask = <0 0 0 0x7>; >> + interrupt-map = <0 0 0 1 &intc 0 0 35 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ >> + <0 0 0 2 &intc 0 0 49 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ >> + <0 0 0 3 &intc 0 0 84 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ >> + <0 0 0 4 &intc 0 0 85 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ >> + >> + /* clocks and clock-names are used to enable the clock in CBCR */ > > This comment is redundant. okay > >> + clocks = <&gcc GCC_PCIE1_AHB_CLK>, >> + <&gcc GCC_PCIE1_AUX_CLK>, >> + <&gcc GCC_PCIE1_AXI_M_CLK>, >> + <&gcc GCC_PCIE1_AXI_S_CLK>, >> + <&gcc GCC_PCIE1_AXI_S_BRIDGE_CLK>, >> + <&gcc GCC_PCIE1_RCHNG_CLK>; >> + clock-names = "ahb", >> + "aux", >> + "axi_m", >> + "axi_s", >> + "axi_bridge", >> + "rchng"; >> + >> + resets = <&gcc GCC_PCIE1_PIPE_ARES>, >> + <&gcc GCC_PCIE1_CORE_STICKY_ARES>, >> + <&gcc GCC_PCIE1_AXI_S_STICKY_ARES>, >> + <&gcc GCC_PCIE1_AXI_S_ARES>, >> + <&gcc GCC_PCIE1_AXI_M_STICKY_ARES>, >> + <&gcc GCC_PCIE1_AXI_M_ARES>, >> + <&gcc GCC_PCIE1_AUX_ARES>, >> + <&gcc GCC_PCIE1_AHB_ARES>; >> + reset-names = "pipe", >> + "sticky", >> + "axi_s_sticky", >> + "axi_s", >> + "axi_m_sticky", >> + "axi_m", >> + "aux", >> + "ahb"; >> + >> + phys = <&pcie1_phy>; >> + phy-names = "pciephy"; >> + interconnects = <&gcc MASTER_ANOC_PCIE1 &gcc SLAVE_ANOC_PCIE1>, >> + <&gcc MASTER_SNOC_PCIE1 &gcc SLAVE_SNOC_PCIE1>; > > Is this really the interconnect paths between PCIe-DDR and PCIe-CPU? I doubt... We actually designed a minimalistic ICC driver for enabling the NoC clocks based on the suggestions received from the community. Please find the link to the discussions that went in for introducing the ICC driver for NoC clock enablement https://lore.kernel.org/linux-arm-msm/abd29b47-a8ab-4e2a-8147-d5d8ded98065@linaro.org/ Thanks, Devi Priya > > - Mani >
On Sun, May 12, 2024 at 01:58:58PM +0530, devi priya wrote: > The IPQ9574 platform has 4 Gen3 PCIe controllers: > two single-lane and two dual-lane based on SNPS core 5.70a > > The Qcom IP rev is 1.27.0 and Synopsys IP rev is 5.80a > Added a new compatible 'qcom,pcie-ipq9574' and 'ops_1_27_0' > which reuses all the members of 'ops_2_9_0' except for the post_init > as the SLV_ADDR_SPACE_SIZE configuration differs between 2_9_0 > and 1_27_0. > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > Co-developed-by: Anusha Rao <quic_anusha@quicinc.com> > Signed-off-by: Anusha Rao <quic_anusha@quicinc.com> > Signed-off-by: devi priya <quic_devipriy@quicinc.com> > --- > Changes in V5: > - Rebased on top of the below series which adds support for fetching > clocks from the device tree > https://lore.kernel.org/linux-pci/20240417-pci-qcom-clk-bulk-v1-1-52ca19b3d6b2@linaro.org/ > > drivers/pci/controller/dwc/pcie-qcom.c | 36 +++++++++++++++++++++++--- > 1 file changed, 32 insertions(+), 4 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index 3d2eeff9a876..af36a29c092e 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > @@ -106,6 +106,7 @@ > > /* PARF_SLV_ADDR_SPACE_SIZE register value */ > #define SLV_ADDR_SPACE_SZ 0x10000000 > +#define SLV_ADDR_SPACE_SZ_1_27_0 0x08000000 Can you please explain what this value corresponds to? Even though there is an old value, I didn't get much info earlier on what it is. - Mani > > /* PARF_MHI_CLOCK_RESET_CTRL register fields */ > #define AHB_CLK_EN BIT(0) > @@ -1095,16 +1096,13 @@ static int qcom_pcie_init_2_9_0(struct qcom_pcie *pcie) > return clk_bulk_prepare_enable(res->num_clks, res->clks); > } > > -static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie) > +static int qcom_pcie_post_init(struct qcom_pcie *pcie) > { > struct dw_pcie *pci = pcie->pci; > u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); > u32 val; > int i; > > - writel(SLV_ADDR_SPACE_SZ, > - pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); > - > val = readl(pcie->parf + PARF_PHY_CTRL); > val &= ~PHY_TEST_PWR_DOWN; > writel(val, pcie->parf + PARF_PHY_CTRL); > @@ -1144,6 +1142,22 @@ static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie) > return 0; > } > > +static int qcom_pcie_post_init_1_27_0(struct qcom_pcie *pcie) > +{ > + writel(SLV_ADDR_SPACE_SZ_1_27_0, > + pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); > + > + return qcom_pcie_post_init(pcie); > +} > + > +static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie) > +{ > + writel(SLV_ADDR_SPACE_SZ, > + pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); > + > + return qcom_pcie_post_init(pcie); > +} > + > static int qcom_pcie_link_up(struct dw_pcie *pci) > { > u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); > @@ -1297,6 +1311,15 @@ static const struct qcom_pcie_ops ops_2_9_0 = { > .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable, > }; > > +/* Qcom IP rev.: 1.27.0 Synopsys IP rev.: 5.80a */ > +static const struct qcom_pcie_ops ops_1_27_0 = { > + .get_resources = qcom_pcie_get_resources_2_9_0, > + .init = qcom_pcie_init_2_9_0, > + .post_init = qcom_pcie_post_init_1_27_0, > + .deinit = qcom_pcie_deinit_2_9_0, > + .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable, > +}; > + > static const struct qcom_pcie_cfg cfg_1_0_0 = { > .ops = &ops_1_0_0, > }; > @@ -1334,6 +1357,10 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = { > .no_l0s = true, > }; > > +static const struct qcom_pcie_cfg cfg_1_27_0 = { > + .ops = &ops_1_27_0, > +}; > + > static const struct dw_pcie_ops dw_pcie_ops = { > .link_up = qcom_pcie_link_up, > .start_link = qcom_pcie_start_link, > @@ -1603,6 +1630,7 @@ static const struct of_device_id qcom_pcie_match[] = { > { .compatible = "qcom,pcie-ipq8064-v2", .data = &cfg_2_1_0 }, > { .compatible = "qcom,pcie-ipq8074", .data = &cfg_2_3_3 }, > { .compatible = "qcom,pcie-ipq8074-gen3", .data = &cfg_2_9_0 }, > + { .compatible = "qcom,pcie-ipq9574", .data = &cfg_1_27_0 }, > { .compatible = "qcom,pcie-msm8996", .data = &cfg_2_3_2 }, > { .compatible = "qcom,pcie-qcs404", .data = &cfg_2_4_0 }, > { .compatible = "qcom,pcie-sa8540p", .data = &cfg_sc8280xp }, > -- > 2.34.1 >
On 5/30/2024 8:17 PM, Manivannan Sadhasivam wrote: > On Sun, May 12, 2024 at 01:58:58PM +0530, devi priya wrote: >> The IPQ9574 platform has 4 Gen3 PCIe controllers: >> two single-lane and two dual-lane based on SNPS core 5.70a >> >> The Qcom IP rev is 1.27.0 and Synopsys IP rev is 5.80a >> Added a new compatible 'qcom,pcie-ipq9574' and 'ops_1_27_0' >> which reuses all the members of 'ops_2_9_0' except for the post_init >> as the SLV_ADDR_SPACE_SIZE configuration differs between 2_9_0 >> and 1_27_0. >> >> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> >> Co-developed-by: Anusha Rao <quic_anusha@quicinc.com> >> Signed-off-by: Anusha Rao <quic_anusha@quicinc.com> >> Signed-off-by: devi priya <quic_devipriy@quicinc.com> >> --- >> Changes in V5: >> - Rebased on top of the below series which adds support for fetching >> clocks from the device tree >> https://lore.kernel.org/linux-pci/20240417-pci-qcom-clk-bulk-v1-1-52ca19b3d6b2@linaro.org/ >> >> drivers/pci/controller/dwc/pcie-qcom.c | 36 +++++++++++++++++++++++--- >> 1 file changed, 32 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c >> index 3d2eeff9a876..af36a29c092e 100644 >> --- a/drivers/pci/controller/dwc/pcie-qcom.c >> +++ b/drivers/pci/controller/dwc/pcie-qcom.c >> @@ -106,6 +106,7 @@ >> >> /* PARF_SLV_ADDR_SPACE_SIZE register value */ >> #define SLV_ADDR_SPACE_SZ 0x10000000 >> +#define SLV_ADDR_SPACE_SZ_1_27_0 0x08000000 > > Can you please explain what this value corresponds to? Even though there is an > old value, I didn't get much info earlier on what it is. The PARF_SLV_ADDR_SPACE_SIZE register indicates the range of RC accesses to the EP's memory space. Default PoR value is 16MB, which seems to be sufficient for IPQ9574 SoC. As per the memory map, the memory space corresponding to each PCIe region is 128Mb. As the older value corresponds to 256Mb we see PCIe enumeration failures. This register should either be updated to 128Mb(0x8000000) or left at the PoR value 16Mb (0x1000000). Thanks, Devi Priya > > - Mani > >> >> /* PARF_MHI_CLOCK_RESET_CTRL register fields */ >> #define AHB_CLK_EN BIT(0) >> @@ -1095,16 +1096,13 @@ static int qcom_pcie_init_2_9_0(struct qcom_pcie *pcie) >> return clk_bulk_prepare_enable(res->num_clks, res->clks); >> } >> >> -static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie) >> +static int qcom_pcie_post_init(struct qcom_pcie *pcie) >> { >> struct dw_pcie *pci = pcie->pci; >> u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); >> u32 val; >> int i; >> >> - writel(SLV_ADDR_SPACE_SZ, >> - pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); >> - >> val = readl(pcie->parf + PARF_PHY_CTRL); >> val &= ~PHY_TEST_PWR_DOWN; >> writel(val, pcie->parf + PARF_PHY_CTRL); >> @@ -1144,6 +1142,22 @@ static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie) >> return 0; >> } >> >> +static int qcom_pcie_post_init_1_27_0(struct qcom_pcie *pcie) >> +{ >> + writel(SLV_ADDR_SPACE_SZ_1_27_0, >> + pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); >> + >> + return qcom_pcie_post_init(pcie); >> +} >> + >> +static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie) >> +{ >> + writel(SLV_ADDR_SPACE_SZ, >> + pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); >> + >> + return qcom_pcie_post_init(pcie); >> +} >> + >> static int qcom_pcie_link_up(struct dw_pcie *pci) >> { >> u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); >> @@ -1297,6 +1311,15 @@ static const struct qcom_pcie_ops ops_2_9_0 = { >> .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable, >> }; >> >> +/* Qcom IP rev.: 1.27.0 Synopsys IP rev.: 5.80a */ >> +static const struct qcom_pcie_ops ops_1_27_0 = { >> + .get_resources = qcom_pcie_get_resources_2_9_0, >> + .init = qcom_pcie_init_2_9_0, >> + .post_init = qcom_pcie_post_init_1_27_0, >> + .deinit = qcom_pcie_deinit_2_9_0, >> + .ltssm_enable = qcom_pcie_2_3_2_ltssm_enable, >> +}; >> + >> static const struct qcom_pcie_cfg cfg_1_0_0 = { >> .ops = &ops_1_0_0, >> }; >> @@ -1334,6 +1357,10 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = { >> .no_l0s = true, >> }; >> >> +static const struct qcom_pcie_cfg cfg_1_27_0 = { >> + .ops = &ops_1_27_0, >> +}; >> + >> static const struct dw_pcie_ops dw_pcie_ops = { >> .link_up = qcom_pcie_link_up, >> .start_link = qcom_pcie_start_link, >> @@ -1603,6 +1630,7 @@ static const struct of_device_id qcom_pcie_match[] = { >> { .compatible = "qcom,pcie-ipq8064-v2", .data = &cfg_2_1_0 }, >> { .compatible = "qcom,pcie-ipq8074", .data = &cfg_2_3_3 }, >> { .compatible = "qcom,pcie-ipq8074-gen3", .data = &cfg_2_9_0 }, >> + { .compatible = "qcom,pcie-ipq9574", .data = &cfg_1_27_0 }, >> { .compatible = "qcom,pcie-msm8996", .data = &cfg_2_3_2 }, >> { .compatible = "qcom,pcie-qcs404", .data = &cfg_2_4_0 }, >> { .compatible = "qcom,pcie-sa8540p", .data = &cfg_sc8280xp }, >> -- >> 2.34.1 >> >
On Mon, Jun 10, 2024 at 11:15:55AM +0530, Devi Priya wrote: > > > On 5/30/2024 8:17 PM, Manivannan Sadhasivam wrote: > > On Sun, May 12, 2024 at 01:58:58PM +0530, devi priya wrote: > > > The IPQ9574 platform has 4 Gen3 PCIe controllers: > > > two single-lane and two dual-lane based on SNPS core 5.70a > > > > > > The Qcom IP rev is 1.27.0 and Synopsys IP rev is 5.80a > > > Added a new compatible 'qcom,pcie-ipq9574' and 'ops_1_27_0' > > > which reuses all the members of 'ops_2_9_0' except for the post_init > > > as the SLV_ADDR_SPACE_SIZE configuration differs between 2_9_0 > > > and 1_27_0. > > > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > Co-developed-by: Anusha Rao <quic_anusha@quicinc.com> > > > Signed-off-by: Anusha Rao <quic_anusha@quicinc.com> > > > Signed-off-by: devi priya <quic_devipriy@quicinc.com> > > > --- > > > Changes in V5: > > > - Rebased on top of the below series which adds support for fetching > > > clocks from the device tree > > > https://lore.kernel.org/linux-pci/20240417-pci-qcom-clk-bulk-v1-1-52ca19b3d6b2@linaro.org/ > > > > > > drivers/pci/controller/dwc/pcie-qcom.c | 36 +++++++++++++++++++++++--- > > > 1 file changed, 32 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > > > index 3d2eeff9a876..af36a29c092e 100644 > > > --- a/drivers/pci/controller/dwc/pcie-qcom.c > > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > > > @@ -106,6 +106,7 @@ > > > /* PARF_SLV_ADDR_SPACE_SIZE register value */ > > > #define SLV_ADDR_SPACE_SZ 0x10000000 > > > +#define SLV_ADDR_SPACE_SZ_1_27_0 0x08000000 > > > > Can you please explain what this value corresponds to? Even though there is an > > old value, I didn't get much info earlier on what it is. > > The PARF_SLV_ADDR_SPACE_SIZE register indicates the range of RC accesses > to the EP's memory space. Default PoR value is 16MB, which seems to be > sufficient for IPQ9574 SoC. > As per the memory map, the memory space corresponding to each PCIe region is > 128Mb. As the older value corresponds to 256Mb we see PCIe enumeration > failures. What kind of failure? Is it because kernel is trying to allocate memory region > 128MB range? > This register should either be updated to 128Mb(0x8000000) or left at the > PoR value 16Mb (0x1000000). > Ok, so this is essentially the same as the PCI MEM region defined in DT? In that case, this value should be extracted from DT instead of being hardcoded. But PCI MEM region range in DT is low on many platforms. Maybe that's due to all PCIe instances sharing the 256MB range? - Mani