Message ID | cover.1534264292.git.leonard.crestez@nxp.com (mailing list archive) |
---|---|
Headers | show |
Series | PCI: imx: Initial imx7d suspend/resume support | expand |
On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote: > 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? 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 > 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(-) > > -- > 2.17.1 >
On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote: > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote: > > 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? > > 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
On Mon, Sep 17, 2018 at 04:01:21PM +0000, Leonard Crestez wrote: > On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote: > > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote: > > > > 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? > > > > 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. 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 > 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
On Mon, 2018-09-17 at 17:52 +0100, Lorenzo Pieralisi wrote: > On Mon, Sep 17, 2018 at 04:01:21PM +0000, Leonard Crestez wrote: > > On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote: > > > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote: > > > > 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? > > > > > > 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. > > 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. > 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