[v4,0/6] PCI: imx: Initial imx7d suspend/resume support
mbox series

Message ID cover.1534264292.git.leonard.crestez@nxp.com
Headers show
Series
  • PCI: imx: Initial imx7d suspend/resume support
Related show

Message

Leonard Crestez Aug. 14, 2018, 4:50 p.m. UTC
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(-)

Comments

Lorenzo Pieralisi Sept. 17, 2018, 3:09 p.m. UTC | #1
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
>
Leonard Crestez Sept. 17, 2018, 4:01 p.m. UTC | #2
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
Lorenzo Pieralisi Sept. 17, 2018, 4:52 p.m. UTC | #3
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
Leonard Crestez Sept. 17, 2018, 5:15 p.m. UTC | #4
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