| Message ID | 20220429123832.2376381-1-pgwipeout@gmail.com |
|---|---|
| Headers | show |
| Series | Enable rk356x PCIe controller | expand |
On Fri, 29 Apr 2022 13:38:29 +0100, Peter Geis <pgwipeout@gmail.com> wrote: > > The legacy interrupts on the rk356x PCIe controller are handled by a > single muxed interrupt. Add IRQ domain support to the pcie-dw-rockchip > driver to support the virtual domain. > > Signed-off-by: Peter Geis <pgwipeout@gmail.com> Reviewed-by: Marc Zyngier <maz@kernel.org> M.
On Fri, Apr 29, 2022 at 8:38 AM Peter Geis <pgwipeout@gmail.com> wrote: > > This series enables the DesignWare based PCIe controller on the rk356x > series of chips. We drop the fallback to the core driver due to > compatibility issues. We reset the PCIe controller at driver probe to > prevent issues in the future when firmware / kexec leaves the controller > in an unknown state. We add support for legacy interrupts for cards that > lack MSI support (which is partially broken currently). We then add the > device tree nodes to enable PCIe on the Quartz64 Model A. Good Evening, Just a gentle ping to see if there's anything outstanding here. Very Respectfully, Peter Geis > > Patch 1 drops the snps,dw,pcie fallback from the dt-binding > Patch 2 resets the PCIe controller to prevent configuration bugs > Patch 3 adds legacy interrupt support to the driver > Patch 4 adds the device tree binding to the rk356x.dtsi > Patch 5 enables the PCIe controller on the Quartz64-A > > Changelog: > v9: > - move reset_control_assert out of rockchip_pcie_resource_get > - fix various formatting mistakes > - fix a checkpatch warning > > v8: > - add core reset patch > - simplify IRQ enable/disable functions > - drop spinlock > - only enable/disable IRQ requested > - only pass the IRQ register bits used to irq functions > > v7: > - drop assigned-clocks > > v6: > - fix a ranges issue > - point to GIC instead of ITS > > v5: > - fix incorrect series (apologies for the v4 spam) > > v4: > - drop the ITS modification, poor compatibility is better than > completely broken > > v3: > - drop select node from dt-binding > - convert to for_each_set_bit > - convert to generic_handle_domain_irq > - drop unncessary dev_err > - reorder irq_chip items > - change to level_irq > - install the handler after initializing the domain > > v2: > - Define PCIE_CLIENT_INTR_STATUS_LEGACY > - Fix PCIE_LEGACY_INT_ENABLE to only enable the RC interrupts > - Add legacy interrupt enable/disable support > > > Peter Geis (5): > dt-bindings: PCI: Remove fallback from Rockchip DesignWare binding > PCI: rockchip-dwc: Reset core at driver probe > PCI: rockchip-dwc: Add legacy interrupt support > arm64: dts: rockchip: Add rk3568 PCIe2x1 controller > arm64: dts: rockchip: Enable PCIe controller on quartz64-a > > .../bindings/pci/rockchip-dw-pcie.yaml | 12 +- > .../boot/dts/rockchip/rk3566-quartz64-a.dts | 34 +++++ > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52 ++++++++ > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 119 +++++++++++++++--- > 4 files changed, 191 insertions(+), 26 deletions(-) > > -- > 2.25.1 >
Am Dienstag, 10. Mai 2022, 23:11:18 CEST schrieb Peter Geis: > On Fri, Apr 29, 2022 at 8:38 AM Peter Geis <pgwipeout@gmail.com> wrote: > > > > This series enables the DesignWare based PCIe controller on the rk356x > > series of chips. We drop the fallback to the core driver due to > > compatibility issues. We reset the PCIe controller at driver probe to > > prevent issues in the future when firmware / kexec leaves the controller > > in an unknown state. We add support for legacy interrupts for cards that > > lack MSI support (which is partially broken currently). We then add the > > device tree nodes to enable PCIe on the Quartz64 Model A. > > Good Evening, > > Just a gentle ping to see if there's anything outstanding here. From my side it looks good. I'll take patches 4+5 once the binding-change from patch1 has been applied to some tree. Heiko > > > > Patch 1 drops the snps,dw,pcie fallback from the dt-binding > > Patch 2 resets the PCIe controller to prevent configuration bugs > > Patch 3 adds legacy interrupt support to the driver > > Patch 4 adds the device tree binding to the rk356x.dtsi > > Patch 5 enables the PCIe controller on the Quartz64-A > > > > Changelog: > > v9: > > - move reset_control_assert out of rockchip_pcie_resource_get > > - fix various formatting mistakes > > - fix a checkpatch warning > > > > v8: > > - add core reset patch > > - simplify IRQ enable/disable functions > > - drop spinlock > > - only enable/disable IRQ requested > > - only pass the IRQ register bits used to irq functions > > > > v7: > > - drop assigned-clocks > > > > v6: > > - fix a ranges issue > > - point to GIC instead of ITS > > > > v5: > > - fix incorrect series (apologies for the v4 spam) > > > > v4: > > - drop the ITS modification, poor compatibility is better than > > completely broken > > > > v3: > > - drop select node from dt-binding > > - convert to for_each_set_bit > > - convert to generic_handle_domain_irq > > - drop unncessary dev_err > > - reorder irq_chip items > > - change to level_irq > > - install the handler after initializing the domain > > > > v2: > > - Define PCIE_CLIENT_INTR_STATUS_LEGACY > > - Fix PCIE_LEGACY_INT_ENABLE to only enable the RC interrupts > > - Add legacy interrupt enable/disable support > > > > > > Peter Geis (5): > > dt-bindings: PCI: Remove fallback from Rockchip DesignWare binding > > PCI: rockchip-dwc: Reset core at driver probe > > PCI: rockchip-dwc: Add legacy interrupt support > > arm64: dts: rockchip: Add rk3568 PCIe2x1 controller > > arm64: dts: rockchip: Enable PCIe controller on quartz64-a > > > > .../bindings/pci/rockchip-dw-pcie.yaml | 12 +- > > .../boot/dts/rockchip/rk3566-quartz64-a.dts | 34 +++++ > > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52 ++++++++ > > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 119 +++++++++++++++--- > > 4 files changed, 191 insertions(+), 26 deletions(-) > > > > -- > > 2.25.1 > > >
On Fri, Apr 29, 2022 at 08:38:28AM -0400, Peter Geis wrote: > The PCIe controller is in an unknown state at driver probe. This can > lead to undesireable effects when the driver attempts to configure the > controller. > > Prevent issues in the future by resetting the core during probe. > > Signed-off-by: Peter Geis <pgwipeout@gmail.com> > Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > --- > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 23 ++++++++----------- > 1 file changed, 10 insertions(+), 13 deletions(-) I fear that the controller reset behaviour is bootloader/firmware dependent. Are we sure we are not triggering any regressions by resetting the controller in the middle of probe (aka is the driver implicitly relying on existing behaviour on systems that are not the ones you are testing on) ? Just asking, the rockchip maintainers should be able to answer this question. Thanks, Lorenzo > diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > index c9b341e55cbb..faedbd6ebc20 100644 > --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > @@ -152,6 +152,11 @@ static int rockchip_pcie_resource_get(struct platform_device *pdev, > if (IS_ERR(rockchip->rst_gpio)) > return PTR_ERR(rockchip->rst_gpio); > > + rockchip->rst = devm_reset_control_array_get_exclusive(&pdev->dev); > + if (IS_ERR(rockchip->rst)) > + return dev_err_probe(&pdev->dev, PTR_ERR(rockchip->rst), > + "failed to get reset lines\n"); > + > return 0; > } > > @@ -182,18 +187,6 @@ static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip) > phy_power_off(rockchip->phy); > } > > -static int rockchip_pcie_reset_control_release(struct rockchip_pcie *rockchip) > -{ > - struct device *dev = rockchip->pci.dev; > - > - rockchip->rst = devm_reset_control_array_get_exclusive(dev); > - if (IS_ERR(rockchip->rst)) > - return dev_err_probe(dev, PTR_ERR(rockchip->rst), > - "failed to get reset lines\n"); > - > - return reset_control_deassert(rockchip->rst); > -} > - > static const struct dw_pcie_ops dw_pcie_ops = { > .link_up = rockchip_pcie_link_up, > .start_link = rockchip_pcie_start_link, > @@ -222,6 +215,10 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > if (ret) > return ret; > > + ret = reset_control_assert(rockchip->rst); > + if (ret) > + return ret; > + > /* DON'T MOVE ME: must be enable before PHY init */ > rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3"); > if (IS_ERR(rockchip->vpcie3v3)) { > @@ -241,7 +238,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > if (ret) > goto disable_regulator; > > - ret = rockchip_pcie_reset_control_release(rockchip); > + ret = reset_control_deassert(rockchip->rst); > if (ret) > goto deinit_phy; > > -- > 2.25.1 >
On Wed, May 11, 2022 at 9:50 AM Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > > On Fri, Apr 29, 2022 at 08:38:28AM -0400, Peter Geis wrote: > > The PCIe controller is in an unknown state at driver probe. This can > > lead to undesireable effects when the driver attempts to configure the > > controller. > > > > Prevent issues in the future by resetting the core during probe. > > > > Signed-off-by: Peter Geis <pgwipeout@gmail.com> > > Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > > --- > > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 23 ++++++++----------- > > 1 file changed, 10 insertions(+), 13 deletions(-) > > I fear that the controller reset behaviour is bootloader/firmware > dependent. > > Are we sure we are not triggering any regressions by resetting the > controller in the middle of probe (aka is the driver implicitly > relying on existing behaviour on systems that are not the ones > you are testing on) ? > > Just asking, the rockchip maintainers should be able to answer this > question. This is a new driver with no current users, this series enables the first user. It does not support ACPI nor any sort of handoff at this time. > > Thanks, > Lorenzo > > > diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > index c9b341e55cbb..faedbd6ebc20 100644 > > --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > @@ -152,6 +152,11 @@ static int rockchip_pcie_resource_get(struct platform_device *pdev, > > if (IS_ERR(rockchip->rst_gpio)) > > return PTR_ERR(rockchip->rst_gpio); > > > > + rockchip->rst = devm_reset_control_array_get_exclusive(&pdev->dev); > > + if (IS_ERR(rockchip->rst)) > > + return dev_err_probe(&pdev->dev, PTR_ERR(rockchip->rst), > > + "failed to get reset lines\n"); > > + > > return 0; > > } > > > > @@ -182,18 +187,6 @@ static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip) > > phy_power_off(rockchip->phy); > > } > > > > -static int rockchip_pcie_reset_control_release(struct rockchip_pcie *rockchip) > > -{ > > - struct device *dev = rockchip->pci.dev; > > - > > - rockchip->rst = devm_reset_control_array_get_exclusive(dev); > > - if (IS_ERR(rockchip->rst)) > > - return dev_err_probe(dev, PTR_ERR(rockchip->rst), > > - "failed to get reset lines\n"); > > - > > - return reset_control_deassert(rockchip->rst); > > -} > > - > > static const struct dw_pcie_ops dw_pcie_ops = { > > .link_up = rockchip_pcie_link_up, > > .start_link = rockchip_pcie_start_link, > > @@ -222,6 +215,10 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > > if (ret) > > return ret; > > > > + ret = reset_control_assert(rockchip->rst); > > + if (ret) > > + return ret; > > + > > /* DON'T MOVE ME: must be enable before PHY init */ > > rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3"); > > if (IS_ERR(rockchip->vpcie3v3)) { > > @@ -241,7 +238,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > > if (ret) > > goto disable_regulator; > > > > - ret = rockchip_pcie_reset_control_release(rockchip); > > + ret = reset_control_deassert(rockchip->rst); > > if (ret) > > goto deinit_phy; > > > > -- > > 2.25.1 > >
On Wed, May 11, 2022 at 10:26:20AM -0400, Peter Geis wrote: > On Wed, May 11, 2022 at 9:50 AM Lorenzo Pieralisi > <lorenzo.pieralisi@arm.com> wrote: > > > > On Fri, Apr 29, 2022 at 08:38:28AM -0400, Peter Geis wrote: > > > The PCIe controller is in an unknown state at driver probe. This can > > > lead to undesireable effects when the driver attempts to configure the > > > controller. > > > > > > Prevent issues in the future by resetting the core during probe. > > > > > > Signed-off-by: Peter Geis <pgwipeout@gmail.com> > > > Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > > > --- > > > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 23 ++++++++----------- > > > 1 file changed, 10 insertions(+), 13 deletions(-) > > > > I fear that the controller reset behaviour is bootloader/firmware > > dependent. > > > > Are we sure we are not triggering any regressions by resetting the > > controller in the middle of probe (aka is the driver implicitly > > relying on existing behaviour on systems that are not the ones > > you are testing on) ? > > > > Just asking, the rockchip maintainers should be able to answer this > > question. > > This is a new driver with no current users, this series enables the > first user. It does not support ACPI nor any sort of handoff at this > time. Ok. I will take patches [1-3], dts changes will have to go via platform trees, I hope that's fine. Thanks, Lorenzo > > Thanks, > > Lorenzo > > > > > diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > > index c9b341e55cbb..faedbd6ebc20 100644 > > > --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > > @@ -152,6 +152,11 @@ static int rockchip_pcie_resource_get(struct platform_device *pdev, > > > if (IS_ERR(rockchip->rst_gpio)) > > > return PTR_ERR(rockchip->rst_gpio); > > > > > > + rockchip->rst = devm_reset_control_array_get_exclusive(&pdev->dev); > > > + if (IS_ERR(rockchip->rst)) > > > + return dev_err_probe(&pdev->dev, PTR_ERR(rockchip->rst), > > > + "failed to get reset lines\n"); > > > + > > > return 0; > > > } > > > > > > @@ -182,18 +187,6 @@ static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip) > > > phy_power_off(rockchip->phy); > > > } > > > > > > -static int rockchip_pcie_reset_control_release(struct rockchip_pcie *rockchip) > > > -{ > > > - struct device *dev = rockchip->pci.dev; > > > - > > > - rockchip->rst = devm_reset_control_array_get_exclusive(dev); > > > - if (IS_ERR(rockchip->rst)) > > > - return dev_err_probe(dev, PTR_ERR(rockchip->rst), > > > - "failed to get reset lines\n"); > > > - > > > - return reset_control_deassert(rockchip->rst); > > > -} > > > - > > > static const struct dw_pcie_ops dw_pcie_ops = { > > > .link_up = rockchip_pcie_link_up, > > > .start_link = rockchip_pcie_start_link, > > > @@ -222,6 +215,10 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > > > if (ret) > > > return ret; > > > > > > + ret = reset_control_assert(rockchip->rst); > > > + if (ret) > > > + return ret; > > > + > > > /* DON'T MOVE ME: must be enable before PHY init */ > > > rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3"); > > > if (IS_ERR(rockchip->vpcie3v3)) { > > > @@ -241,7 +238,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > > > if (ret) > > > goto disable_regulator; > > > > > > - ret = rockchip_pcie_reset_control_release(rockchip); > > > + ret = reset_control_deassert(rockchip->rst); > > > if (ret) > > > goto deinit_phy; > > > > > > -- > > > 2.25.1 > > >
On Fri, 29 Apr 2022 08:38:26 -0400, Peter Geis wrote: > This series enables the DesignWare based PCIe controller on the rk356x > series of chips. We drop the fallback to the core driver due to > compatibility issues. We reset the PCIe controller at driver probe to > prevent issues in the future when firmware / kexec leaves the controller > in an unknown state. We add support for legacy interrupts for cards that > lack MSI support (which is partially broken currently). We then add the > device tree nodes to enable PCIe on the Quartz64 Model A. > > [...] Applied to pci/dwc, thanks! [1/5] dt-bindings: PCI: Remove fallback from Rockchip DesignWare binding https://git.kernel.org/lpieralisi/pci/c/931262e646 [2/5] PCI: rockchip-dwc: Reset core at driver probe https://git.kernel.org/lpieralisi/pci/c/431e7d2eec [3/5] PCI: rockchip-dwc: Add legacy interrupt support https://git.kernel.org/lpieralisi/pci/c/e8aae154df Thanks, Lorenzo
Am Mittwoch, 11. Mai 2022, 17:00:05 CEST schrieb Lorenzo Pieralisi: > On Wed, May 11, 2022 at 10:26:20AM -0400, Peter Geis wrote: > > On Wed, May 11, 2022 at 9:50 AM Lorenzo Pieralisi > > <lorenzo.pieralisi@arm.com> wrote: > > > > > > On Fri, Apr 29, 2022 at 08:38:28AM -0400, Peter Geis wrote: > > > > The PCIe controller is in an unknown state at driver probe. This can > > > > lead to undesireable effects when the driver attempts to configure the > > > > controller. > > > > > > > > Prevent issues in the future by resetting the core during probe. > > > > > > > > Signed-off-by: Peter Geis <pgwipeout@gmail.com> > > > > Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > > > > --- > > > > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 23 ++++++++----------- > > > > 1 file changed, 10 insertions(+), 13 deletions(-) > > > > > > I fear that the controller reset behaviour is bootloader/firmware > > > dependent. > > > > > > Are we sure we are not triggering any regressions by resetting the > > > controller in the middle of probe (aka is the driver implicitly > > > relying on existing behaviour on systems that are not the ones > > > you are testing on) ? > > > > > > Just asking, the rockchip maintainers should be able to answer this > > > question. > > > > This is a new driver with no current users, this series enables the > > first user. It does not support ACPI nor any sort of handoff at this > > time. > > Ok. I will take patches [1-3], dts changes will have to go via > platform trees, I hope that's fine. yep, that sounds great and I'll pick the dts patches then :-) Thanks Heiko > > > > diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > > > index c9b341e55cbb..faedbd6ebc20 100644 > > > > --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > > > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c > > > > @@ -152,6 +152,11 @@ static int rockchip_pcie_resource_get(struct platform_device *pdev, > > > > if (IS_ERR(rockchip->rst_gpio)) > > > > return PTR_ERR(rockchip->rst_gpio); > > > > > > > > + rockchip->rst = devm_reset_control_array_get_exclusive(&pdev->dev); > > > > + if (IS_ERR(rockchip->rst)) > > > > + return dev_err_probe(&pdev->dev, PTR_ERR(rockchip->rst), > > > > + "failed to get reset lines\n"); > > > > + > > > > return 0; > > > > } > > > > > > > > @@ -182,18 +187,6 @@ static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip) > > > > phy_power_off(rockchip->phy); > > > > } > > > > > > > > -static int rockchip_pcie_reset_control_release(struct rockchip_pcie *rockchip) > > > > -{ > > > > - struct device *dev = rockchip->pci.dev; > > > > - > > > > - rockchip->rst = devm_reset_control_array_get_exclusive(dev); > > > > - if (IS_ERR(rockchip->rst)) > > > > - return dev_err_probe(dev, PTR_ERR(rockchip->rst), > > > > - "failed to get reset lines\n"); > > > > - > > > > - return reset_control_deassert(rockchip->rst); > > > > -} > > > > - > > > > static const struct dw_pcie_ops dw_pcie_ops = { > > > > .link_up = rockchip_pcie_link_up, > > > > .start_link = rockchip_pcie_start_link, > > > > @@ -222,6 +215,10 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > > > > if (ret) > > > > return ret; > > > > > > > > + ret = reset_control_assert(rockchip->rst); > > > > + if (ret) > > > > + return ret; > > > > + > > > > /* DON'T MOVE ME: must be enable before PHY init */ > > > > rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3"); > > > > if (IS_ERR(rockchip->vpcie3v3)) { > > > > @@ -241,7 +238,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev) > > > > if (ret) > > > > goto disable_regulator; > > > > > > > > - ret = rockchip_pcie_reset_control_release(rockchip); > > > > + ret = reset_control_deassert(rockchip->rst); > > > > if (ret) > > > > goto deinit_phy; > > > > > > > > -- > > > > 2.25.1 > > > > >
Am Freitag, 29. April 2022, 14:38:30 CEST schrieb Peter Geis: > The PCIe2x1 controller is common between the rk3568 and rk3566. It is a > single lane PCIe2 compliant controller. > > Signed-off-by: Peter Geis <pgwipeout@gmail.com> > --- > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52 ++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > index 7cdef800cb3c..aea5d9255235 100644 > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > @@ -689,6 +689,58 @@ qos_vop_m1: qos@fe1a8100 { > reg = <0x0 0xfe1a8100 0x0 0x20>; > }; > > + pcie2x1: pcie@fe260000 { > + compatible = "rockchip,rk3568-pcie"; > + #address-cells = <3>; > + #size-cells = <2>; > + bus-range = <0x0 0xf>; > + clocks = <&cru ACLK_PCIE20_MST>, <&cru ACLK_PCIE20_SLV>, > + <&cru ACLK_PCIE20_DBI>, <&cru PCLK_PCIE20>, > + <&cru CLK_PCIE20_AUX_NDFT>; > + clock-names = "aclk_mst", "aclk_slv", > + "aclk_dbi", "pclk", "aux"; > + device_type = "pci"; > + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "sys", "pmc", "msi", "legacy", "err"; > + #interrupt-cells = <1>; I guess #interrupt-cells shouldn't be necessary here, as that property is meant for interrupt-controller nodes - like the subnode here which already has its own #interrupt-cells, right? > + interrupt-map-mask = <0 0 0 7>; > + interrupt-map = <0 0 0 1 &pcie_intc 0>, > + <0 0 0 2 &pcie_intc 1>, > + <0 0 0 3 &pcie_intc 2>, > + <0 0 0 4 &pcie_intc 3>; > + linux,pci-domain = <0>; > + num-ib-windows = <6>; > + num-ob-windows = <2>; > + max-link-speed = <2>; > + msi-map = <0x0 &gic 0x0 0x1000>; > + num-lanes = <1>; > + phys = <&combphy2 PHY_TYPE_PCIE>; > + phy-names = "pcie-phy"; > + power-domains = <&power RK3568_PD_PIPE>; > + reg = <0x3 0xc0000000 0x0 0x00400000>, > + <0x0 0xfe260000 0x0 0x00010000>, > + <0x3 0x00000000 0x0 0x01000000>; > + ranges = <0x01000000 0x0 0x01000000 0x3 0x01000000 0x0 0x00100000 > + 0x02000000 0x0 0x02000000 0x3 0x01100000 0x0 0x3ef00000>; > + reg-names = "dbi", "apb", "config"; > + resets = <&cru SRST_PCIE20_POWERUP>; > + reset-names = "pipe"; > + status = "disabled"; > + > + pcie_intc: legacy-interrupt-controller { > + #address-cells = <0>; > + #interrupt-cells = <1>; > + interrupt-controller; > + interrupt-parent = <&gic>; > + interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>; > + }; > + > + }; > + > sdmmc0: mmc@fe2b0000 { > compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc"; > reg = <0x0 0xfe2b0000 0x0 0x4000>; >
On Fri, 29 Apr 2022 08:38:26 -0400, Peter Geis wrote: > This series enables the DesignWare based PCIe controller on the rk356x > series of chips. We drop the fallback to the core driver due to > compatibility issues. We reset the PCIe controller at driver probe to > prevent issues in the future when firmware / kexec leaves the controller > in an unknown state. We add support for legacy interrupts for cards that > lack MSI support (which is partially broken currently). We then add the > device tree nodes to enable PCIe on the Quartz64 Model A. > > [...] Applied, thanks! [4/5] arm64: dts: rockchip: Add rk3568 PCIe2x1 controller commit: c9168492af55bdbc811e05bfc55ae70880bf8ff3 [5/5] arm64: dts: rockchip: Enable PCIe controller on quartz64-a commit: 4f4cbbb147b988daaa036dcf34628d93b2e22cd9 Best regards,