PCI: imx: Initial imx7d suspend/resume support
Subsystems (6)
v4 cover PCI: imx: Initial imx7d suspend/resume support
On imx7d the pcie-phy power domain is turned off in suspend and this can make the system hang on resume when attempting any read from PCI.
Fix this by adding PM_SLEEP support to the imx6 pci driver. This is currently only enabled for imx7d but the suspend/resume sequence also applies to other socs.
V3 of this series was reviewed by Lucas but stalled because the merge window opened.
There was also some confusion about how to deal with the dependence on commit 26fce0557fa6 ("reset: imx7: Fix always writing bits as 0"). To
clarify: both patch 2 and 26fce0557fa6 are required to fix imx7d suspend but merging one without the other shouldn't cause other issues.
V4 adds 4 more patches with PME_Turn_Off support on top, using a new reset bit. I generally try to keep series short but in this case some planning might be needed to get patches into 4.20.
Since the new reset is treated as optional with old DTB there should be again no problem if reset and pci are merged out of order.
Shawn/Philipp/Lorenzo: Would it make sense to merge this series through a single specific tree, such as the one for imx?
Link to v3: https://lkml.org/lkml/2018/7/24/713
Leonard Crestez (6):
Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
PCI: imx: Initial imx7d pm support
reset: imx7: Add PCIE_CTRL_APPS_TURNOFF
dt-bindings: imx6q-pcie: Add turnoff reset for imx7d
ARM: dts: imx7d: Add turnoff reset
PCI: imx: Add PME_Turn_Off support
.../bindings/pci/fsl,imx6q-pcie.txt | 1 + arch/arm/boot/dts/imx7d.dtsi | 17 ++- drivers/pci/controller/dwc/pci-imx6.c | 112 +++++++++++++++++- drivers/reset/reset-imx7.c | 1 + include/dt-bindings/reset/imx7-reset.h | 4 +- 5 files changed, 123 insertions(+), 12 deletions(-)
Signature · 1 line
2.17.1
PATCH v4 1/6 Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
That commit followed the reference manual but unfortunately the imx7d manual is incorrect.
Tested with ath9k pcie card and confirmed internally.
--- arch/arm/boot/dts/imx7d.dtsi | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
arch/arm/boot/dts/imx7d.dtsi +8 -4
@@ -124,14 +124,18 @@ num-lanes = <1>; interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; - interrupt-map = <0 0 0 1 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 2 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 3 &intc GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 4 &intc GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; + /* + * Reference manual lists pci irqs incorrectly + * Real hardware ordering is same as imx6: D+MSI, C, B, A + */ + interrupt-map = <0 0 0 1 &intc GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &intc GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_PCIE_CTRL_ROOT_CLK>, <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>, <&clks IMX7D_PCIE_PHY_ROOT_CLK>; clock-names = "pcie", "pcie_bus", "pcie_phy"; assigned-clocks = <&clks IMX7D_PCIE_CTRL_ROOT_SRC>,
Signature · 1 line
2.17.1
PATCH v4 2/6 PCI: imx: Initial imx7d pm support
In reply to Leonard CrestezOn imx7d the pcie-phy power domain is turned off in suspend and this can make the system hang after resume when attempting any read from PCI.
Fix this by adding minimal suspend/resume code from the nxp internal tree. This will prepare for powering down on suspend and reset the block on resume.
Code is only for imx7d but a very similar sequence can be used for other socs.
The original author is mostly Richard Zhu <[email protected]>, this patch adjusts the code to the upstream imx7d implemention using reset controls and power domains.
--- drivers/pci/controller/dwc/pci-imx6.c | 97 +++++++++++++++++++++++++-- 1 file changed, 92 insertions(+), 5 deletions(-)
drivers/pci/controller/dwc/pci-imx6.c +92 -5
@@ -584,10 +584,28 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)dev_err (dev,"Speed change timeout\n" );return -EINVAL ; } +static void imx6_pcie_ltssm_enable (struct device *dev) +{ +struct imx6_pcie *imx6_pcie =dev_get_drvdata (dev); + +switch (imx6_pcie->variant) { +case IMX6Q : +case IMX6SX : +case IMX6QP : +regmap_update_bits (imx6_pcie->iomuxc_gpr,IOMUXC_GPR12 , +IMX6Q_GPR12_PCIE_CTL_2 , +IMX6Q_GPR12_PCIE_CTL_2 ); +break ; +case IMX7D : +reset_control_deassert (imx6_pcie->apps_reset); +break ; + } +} +static int imx6_pcie_establish_link (struct imx6_pcie *imx6_pcie) {struct dw_pcie *pci = imx6_pcie->pci;struct device *dev = pci->dev;u32 tmp;
@@ -602,15 +620,11 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie) tmp &= ~PCIE_RC_LCR_MAX_LINK_SPEEDS_MASK ; tmp |=PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1 ;dw_pcie_writel_dbi (pci,PCIE_RC_LCR , tmp);/* Start LTSSM. */ -if (imx6_pcie->variant ==IMX7D ) -reset_control_deassert (imx6_pcie->apps_reset); -else -regmap_update_bits (imx6_pcie->iomuxc_gpr,IOMUXC_GPR12 , -IMX6Q_GPR12_PCIE_CTL_2 ,1 <<10 ); +imx6_pcie_ltssm_enable (dev); ret =imx6_pcie_wait_for_link (imx6_pcie);if (ret) goto err_reset_phy;
@@ -724,10 +738,82 @@ static int imx6_add_pcie_port(struct imx6_pcie *imx6_pcie,static const struct dw_pcie_ops dw_pcie_ops = { .link_up = imx6_pcie_link_up, }; +#ifdef CONFIG_PM_SLEEP +static void imx6_pcie_ltssm_disable (struct device *dev) +{ +struct imx6_pcie *imx6_pcie =dev_get_drvdata (dev); + +switch (imx6_pcie->variant) { +case IMX6SX : +case IMX6QP : +regmap_update_bits (imx6_pcie->iomuxc_gpr,IOMUXC_GPR12 , +IMX6Q_GPR12_PCIE_CTL_2 ,0 ); +break ; +case IMX7D : +reset_control_assert (imx6_pcie->apps_reset); +break ; +default : +dev_err (dev,"ltssm_disable not supported\n" ); + } +} + +static void imx6_pcie_clk_disable (struct imx6_pcie *imx6_pcie) +{ +clk_disable_unprepare (imx6_pcie->pcie); +clk_disable_unprepare (imx6_pcie->pcie_phy); +clk_disable_unprepare (imx6_pcie->pcie_bus); + +if (imx6_pcie->variant ==IMX7D ) { +regmap_update_bits (imx6_pcie->iomuxc_gpr,IOMUXC_GPR12 , +IMX7D_GPR12_PCIE_PHY_REFCLK_SEL , +IMX7D_GPR12_PCIE_PHY_REFCLK_SEL ); + } +} + +static int imx6_pcie_suspend_noirq (struct device *dev) +{ +struct imx6_pcie *imx6_pcie =dev_get_drvdata (dev); + +if (imx6_pcie->variant !=IMX7D ) +return 0 ; + +imx6_pcie_clk_disable (imx6_pcie); +imx6_pcie_ltssm_disable (dev); + +return 0 ; +} + +static int imx6_pcie_resume_noirq (struct device *dev) +{ +int ret; +struct imx6_pcie *imx6_pcie =dev_get_drvdata (dev); +struct pcie_port *pp = &imx6_pcie->pci->pp; + +if (imx6_pcie->variant !=IMX7D ) +return 0 ; + +imx6_pcie_assert_core_reset (imx6_pcie); +imx6_pcie_init_phy (imx6_pcie); +imx6_pcie_deassert_core_reset (imx6_pcie); +dw_pcie_setup_rc (pp); + + ret =imx6_pcie_establish_link (imx6_pcie); +if (ret <0 ) +dev_info (dev,"pcie link is down after resume.\n" ); + +return 0 ; +} +#endif + +static const struct dev_pm_ops imx6_pcie_pm_ops = { +SET_NOIRQ_SYSTEM_SLEEP_PM_OPS (imx6_pcie_suspend_noirq, + imx6_pcie_resume_noirq) +}; +static int imx6_pcie_probe (struct platform_device *pdev) {struct device *dev = &pdev->dev;struct dw_pcie *pci;struct imx6_pcie *imx6_pcie;
@@ -894,10 +980,11 @@ static const struct of_device_id imx6_pcie_of_match[] = {static struct platform_driver imx6_pcie_driver = { .driver = { .name ="imx6q-pcie" , .of_match_table = imx6_pcie_of_match, .suppress_bind_attrs = true, + .pm = &imx6_pcie_pm_ops, }, .probe = imx6_pcie_probe, .shutdown = imx6_pcie_shutdown, };
Signature · 1 line
2.17.1
PATCH v4 3/6 reset: imx7: Add PCIE_CTRL_APPS_TURNOFF
In reply to Leonard CrestezThis is required for the imx pci driver to send the PME_Turn_Off TLP.
--- drivers/reset/reset-imx7.c | 1 + include/dt-bindings/reset/imx7-reset.h | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-)
drivers/reset/reset-imx7.c +1 -0
@@ -65,10 +65,11 @@ static const struct imx7_src_signal imx7_src_signals[IMX7_RESET_NUM] = { [IMX7_RESET_MIPI_PHY_MRST] = { SRC_MIPIPHY_RCR, BIT(1) }, [IMX7_RESET_MIPI_PHY_SRST] = { SRC_MIPIPHY_RCR, BIT(2) }, [IMX7_RESET_PCIEPHY] = { SRC_PCIEPHY_RCR, BIT(2) | BIT(1) }, [IMX7_RESET_PCIEPHY_PERST] = { SRC_PCIEPHY_RCR, BIT(3) }, [IMX7_RESET_PCIE_CTRL_APPS_EN] = { SRC_PCIEPHY_RCR, BIT(6) }, + [IMX7_RESET_PCIE_CTRL_APPS_TURNOFF] = { SRC_PCIEPHY_RCR, BIT(11) }, [IMX7_RESET_DDRC_PRST] = { SRC_DDRC_RCR, BIT(0) }, [IMX7_RESET_DDRC_CORE_RST] = { SRC_DDRC_RCR, BIT(1) }, };static struct imx7_src *to_imx7_src (struct reset_controller_dev *rcdev)
include/dt-bindings/reset/imx7-reset.h +3 -1
@@ -54,9 +54,11 @@*/ #define IMX7_RESET_PCIE_CTRL_APPS_EN 22#define IMX7_RESET_DDRC_PRST 23#define IMX7_RESET_DDRC_CORE_RST 24 -#define IMX7_RESET_NUM 25 +#define IMX7_RESET_PCIE_CTRL_APPS_TURNOFF 25 + +#define IMX7_RESET_NUM 26#endif
Signature · 1 line
2.17.1
Re: [PATCH v4 3/6] reset: imx7: Add PCIE_CTRL_APPS_TURNOFF
Quoted 7 lines · Leonard Crestez
This is required for the imx pci driver to send the
PME_Turn_OffTLP.Signed-off-by Leonard Crestez <[email protected]>--- drivers/reset/reset-imx7.c | 1 +include/dt-bindings/reset/imx7-reset.h | 4 +++-
Quoted 1 line
2 files changed, 4 insertions(+), 1 deletion(-)
PATCH v4 4/6 dt-bindings: imx6q-pcie: Add turnoff reset for imx7d
In reply to Leonard CrestezThis is documented as "required" but won't be present in old dtbs.
These resets are also present on other imx chips but right now only imx7d implements them through the reset controller subsystem.
--- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt +1 -0
@@ -48,10 +48,11 @@ Additional required properties for imx7d-pcie: - resets: Must contain phandles to PCIe-related reset lines exposed by SRC IP block - reset-names: Must contain the following entires: - "pciephy" - "apps" + - "turnoff" Example: pcie at 01000000 { compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
Signature · 1 line
2.17.1
Re: [PATCH v4 4/6] dt-bindings: imx6q-pcie: Add turnoff reset for imx7d
Quoted 10 lines · Leonard Crestez
This is documented as "required" but won't be present in old dtbs.
These resets are also present on other imx chips but right now only imx7d implements them through the reset controller subsystem.
Signed-off-by Leonard Crestez <[email protected]>--- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 1 + 1 file changed, 1 insertion(+)
PATCH v4 5/6 ARM: dts: imx7d: Add turnoff reset
In reply to Leonard CrestezThis is required for the imx pci driver to send the PME_Turn_Off TLP.
--- arch/arm/boot/dts/imx7d.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx7d.dtsi +3 -2
@@ -144,12 +144,13 @@ <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>; fsl,max-link-speed = <2>; power-domains = <&pgc_pcie_phy>; resets = <&src IMX7_RESET_PCIEPHY>, - <&src IMX7_RESET_PCIE_CTRL_APPS_EN>; - reset-names = "pciephy", "apps"; + <&src IMX7_RESET_PCIE_CTRL_APPS_EN>, + <&src IMX7_RESET_PCIE_CTRL_APPS_TURNOFF>; + reset-names = "pciephy", "apps", "turnoff"; status = "disabled"; }; }; &ca_funnel_ports {
Signature · 1 line
2.17.1
Re: [PATCH v4 5/6] ARM: dts: imx7d: Add turnoff reset
Quoted 3 lines · Leonard Crestez
This is required for the imx pci driver to send the
PME_Turn_OffTLP.Signed-off-by Leonard Crestez <[email protected]>
Quoted 32 lines
--- arch/arm/boot/dts/imx7d.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)arch/arm/boot/dts/imx7d.dtsi +3
-2@@ -144,12 +144,13 @@ <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>; fsl,max-link-speed = <2>; power-domains = <&pgc_pcie_phy>; resets = <&src IMX7_RESET_PCIEPHY>, - <&src IMX7_RESET_PCIE_CTRL_APPS_EN>; - reset-names = "pciephy", "apps"; + <&src IMX7_RESET_PCIE_CTRL_APPS_EN>, + <&src IMX7_RESET_PCIE_CTRL_APPS_TURNOFF>; + reset-names = "pciephy", "apps", "turnoff"; status = "disabled"; }; }; &ca_funnel_ports {Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v4 6/6 PCI: imx: Add PME_Turn_Off support
In reply to Leonard CrestezWhen the root complex suspends it must send a PME_Turn_Off TLP. Implement this by asserting the "turnoff" reset.
On imx7d this is functionality is part of the SRC and exposed through the linux reset-controller subsystem. On imx6 equivalent bits are in the IOMUXC GPR area which the imx6-pcie driver accesses directly.
This is only for imx7d right now but it's deliberately implemented as an optional reset, ignoring the chip variant:
* Older dtbs won't have this reset so it will be ignored.
* Future chips might also expose this as a reset controller.
For example imx8m (not yet supported) has the exact same PCIE_CTRL_APPS_TURNOFF bit in the same location.
--- drivers/pci/controller/dwc/pci-imx6.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
drivers/pci/controller/dwc/pci-imx6.c +15 -0
@@ -50,10 +50,11 @@ struct imx6_pcie {struct clk *pcie_inbound_axi;struct clk *pcie;struct regmap *iomuxc_gpr;struct reset_control *pciephy_reset;struct reset_control *apps_reset; +struct reset_control *turnoff_reset;enum imx6_pcie_variants variant;u32 tx_deemph_gen1;u32 tx_deemph_gen2_3p5db;u32 tx_deemph_gen2_6db;u32 tx_swing_full;
@@ -757,10 +758,16 @@ static void imx6_pcie_ltssm_disable(struct device *dev)default :dev_err (dev,"ltssm_disable not supported\n" ); } } +static void imx6_pcie_pm_turnoff (struct imx6_pcie *imx6_pcie) +{ +reset_control_assert (imx6_pcie->turnoff_reset); +reset_control_deassert (imx6_pcie->turnoff_reset); +} +static void imx6_pcie_clk_disable (struct imx6_pcie *imx6_pcie) {clk_disable_unprepare (imx6_pcie->pcie);clk_disable_unprepare (imx6_pcie->pcie_phy);clk_disable_unprepare (imx6_pcie->pcie_bus);
@@ -777,10 +784,11 @@ static int imx6_pcie_suspend_noirq(struct device *dev)struct imx6_pcie *imx6_pcie =dev_get_drvdata (dev);if (imx6_pcie->variant !=IMX7D )return 0 ; +imx6_pcie_pm_turnoff (imx6_pcie);imx6_pcie_clk_disable (imx6_pcie);imx6_pcie_ltssm_disable (dev);return 0 ; }
@@ -904,10 +912,17 @@ static int imx6_pcie_probe(struct platform_device *pdev)break ;default :break ; } +/* Grab turnoff reset */ + imx6_pcie->turnoff_reset =devm_reset_control_get_optional_exclusive (dev,"turnoff" ); +if (IS_ERR (imx6_pcie->turnoff_reset)) { +dev_err (dev,"Failed to get TURNOFF reset control\n" ); +return PTR_ERR (imx6_pcie->turnoff_reset); + } +/* Grab GPR config register range */ imx6_pcie->iomuxc_gpr =syscon_regmap_lookup_by_compatible ("fsl,imx6q-iomuxc-gpr" );if (IS_ERR (imx6_pcie->iomuxc_gpr)) {dev_err (dev,"unable to find iomuxc registers\n" );
Signature · 1 line
2.17.1
Quoted 20 lines · Leonard Crestez
On imx7d the pcie-phy power domain is turned off in suspend and this can make the system hang on resume when attempting any read from PCI.
Fix this by adding
PM_SLEEPsupport to the imx6 pci driver. This is currently only enabled for imx7d but the suspend/resume sequence also applies to other socs.V3 of this series was reviewed by Lucas but stalled because the merge window opened.
There was also some confusion about how to deal with the dependence on commit
26fce0557fa6("reset: imx7: Fix always writing bits as 0"). To
clarify: both patch 2 and26fce0557fa6are required to fix imx7d suspend but merging one without the other shouldn't cause other issues.V4 adds 4 more patches with
PME_Turn_Offsupport on top, using a new reset bit. I generally try to keep series short but in this case some planning might be needed to get patches into 4.20.
Quoted 6 lines
Since the new reset is treated as optional with old DTB there should be again no problem if reset and pci are merged out of order.
Shawn/Philipp/Lorenzo: Would it make sense to merge this series through a single specific tree, such as the one for imx?
This series is a bit of a mixture of multiple things hard to discern (actually I already merged patch 2 and patch 1 seems completely unrelated).
I would take the series through the PCI tree but I need an ACK for patches 5 and 6, please let me know how you want to handle it.
Lorenzo
Quoted 20 lines
Link to v3: https://lkml.org/lkml/2018/7/24/713
Leonard Crestez (6):
Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
PCI: imx: Initial imx7d pm support
reset: imx7: AddPCIE_CTRL_APPS_TURNOFF
dt-bindings: imx6q-pcie: Add turnoff reset for imx7d
ARM: dts: imx7d: Add turnoff reset
PCI: imx: AddPME_Turn_Offsupport.../bindings/pci/fsl,imx6q-pcie.txt | 1 + arch/arm/boot/dts/imx7d.dtsi | 17 ++- drivers/pci/controller/dwc/pci-imx6.c | 112 +++++++++++++++++- drivers/reset/reset-imx7.c | 1 + include/dt-bindings/reset/imx7-reset.h | 4 +- 5 files changed, 123 insertions(+), 12 deletions(-)Signature · 1 line
2.17.1
Quoted 12 lines · Lorenzo Pieralisi
Quoted 9 lines · Leonard Crestez
V4 adds 4 more patches with
PME_Turn_Offsupport on top, using a new reset bit. I generally try to keep series short but in this case some planning might be needed to get patches into 4.20.Since the new reset is treated as optional with old DTB there should be again no problem if reset and pci are merged out of order.
Shawn/Philipp/Lorenzo: Would it make sense to merge this series through a single specific tree, such as the one for imx?
Quoted 6 lines
This series is a bit of a mixture of multiple things hard to discern (actually I already merged patch 2 and patch 1 seems completely unrelated).
I would take the series through the PCI tree but I need an ACK for patches 5 and 6, please let me know how you want to handle it.
Patches 1 and 2 are already in, the rest need review. I can now just resend patches 3-6 as a separate series, unless somebody complains about spam.
Multiple separate patches are required because it touches reset + dt + pci. I guess adding the include constant should be moved from the dts patch to dt-bindings though.
Merging reset and pci out of order should be fine here and is required by DT compatibility rules anyway.
--
Regards,
Leonard
Quoted 17 lines · Leonard Crestez
Quoted 16 lines · Lorenzo Pieralisi
Quoted 9 lines · Leonard Crestez
V4 adds 4 more patches with
PME_Turn_Offsupport on top, using a new reset bit. I generally try to keep series short but in this case some planning might be needed to get patches into 4.20.Since the new reset is treated as optional with old DTB there should be again no problem if reset and pci are merged out of order.
Shawn/Philipp/Lorenzo: Would it make sense to merge this series through a single specific tree, such as the one for imx?
This series is a bit of a mixture of multiple things hard to discern (actually I already merged patch 2 and patch 1 seems completely unrelated).
Quoted 6 lines
Quoted 2 lines
I would take the series through the PCI tree but I need an ACK for patches 5 and 6, please let me know how you want to handle it.
Patches 1 and 2 are already in, the rest need review. I can now just resend patches 3-6 as a separate series, unless somebody complains about spam.
What do you mean by "are already in" ? Patch 2 I queued via the PCI tree, patch 1 ? Can I drop it from the PCI patch queue ?
I do not think there is any need to resend, I can merge patches 3-4 since they have been reviewed but patches 5 and 6 need review.
Lorenzo
Quoted 10 lines
Multiple separate patches are required because it touches reset + dt + pci. I guess adding the include constant should be moved from the dts patch to dt-bindings though.
Merging reset and pci out of order should be fine here and is required by DT compatibility rules anyway.
--
Regards,
Leonard
Quoted 20 lines · Lorenzo Pieralisi
Quoted 19 lines · Leonard Crestez
Quoted 17 lines · Lorenzo Pieralisi
Quoted 9 lines · Leonard Crestez
V4 adds 4 more patches with
PME_Turn_Offsupport on top, using a new reset bit. I generally try to keep series short but in this case some planning might be needed to get patches into 4.20.Since the new reset is treated as optional with old DTB there should be again no problem if reset and pci are merged out of order.
Shawn/Philipp/Lorenzo: Would it make sense to merge this series through a single specific tree, such as the one for imx?
This series is a bit of a mixture of multiple things hard to discern (actually I already merged patch 2 and patch 1 seems completely unrelated).
I would take the series through the PCI tree but I need an ACK for patches 5 and 6, please let me know how you want to handle it.
Quoted 6 lines
Quoted 3 lines
Patches 1 and 2 are already in, the rest need review. I can now just resend patches 3-6 as a separate series, unless somebody complains about spam.
What do you mean by "are already in" ? Patch 2 I queued via the PCI tree, patch 1 ? Can I drop it from the PCI patch queue ?
Sorry, what I meant here is "accepted by a maintainer". So keep patch 2 please; patch 1 was accepted by Shawn few weeks ago.
Quoted 2 lines
I do not think there is any need to resend, I can merge patches 3-4 since they have been reviewed but patches 5 and 6 need review.
Patches 3-4 were acked by Rob Herring mostly from the devicetree perspective. Since patches 3-6 are not useful independently somebody like Lucas should review the whole series and then it can be merged.
--
Regards,
Leonard