| Message ID | 1404135864.4305.23.camel@weser.hi.pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jun 30, 2014 at 03:44:24PM +0200, Lucas Stach wrote: > Hi Shawn, > > can you please test the attached patch on top of 3.16-rc* to see if it > helps? If it works for you I would like to try and get this into 3.16 as > a bugfix. Unfortunately, it doesn't work. With your change, now it hangs in suspend procedure. $ echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.005 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done. PM: Entering mem sleep sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk PM: suspend of devices complete after 102.992 msecs PM: suspend devices took 0.110 seconds PM: late suspend of devices complete after 12.808 msecs Shawn > > Regards, > Lucas > > --------------------------->8----------------------------- > From f3bfdc9c19249188fa153b1568c3129cd31af4f5 Mon Sep 17 00:00:00 2001 > From: Lucas Stach <l.stach@pengutronix.de> > Date: Mon, 30 Jun 2014 15:33:04 +0200 > Subject: [PATCH] PCI: imx6: add workaround for errata ERR005723 > > Fixes system hang after resume from suspend to mem. > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de> > --- > drivers/pci/host/pci-imx6.c | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c > index a568efaa331c..5c58a3ee5dbf 100644 > --- a/drivers/pci/host/pci-imx6.c > +++ b/drivers/pci/host/pci-imx6.c > @@ -589,6 +589,38 @@ static int __init imx6_pcie_probe(struct platform_device *pdev) > return 0; > } > > +#ifdef CONFIG_PM_SLEEP > +static int imx6_pcie_suspend(struct device *dev) > +{ > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev); > + > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, > + IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18); > + > + return 0; > +} > + > +static int imx6_pcie_resume(struct device *dev) > +{ > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev); > + > + /* > + * This is a workaround for > + * ERR005723: PCIe does not support L2 power down > + * Toggling the PHY PD bit around system L2 state switching seems to be > + * enough to wake the PCIe logic after a power down. > + */ > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, > + IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18); > + > + return 0; > +} > +#endif > + > +static SIMPLE_DEV_PM_OPS(imx6_pcie_pm_ops, > + imx6_pcie_suspend, > + imx6_pcie_resume); > + > static const struct of_device_id imx6_pcie_of_match[] = { > { .compatible = "fsl,imx6q-pcie", }, > {}, > @@ -600,6 +632,7 @@ static struct platform_driver imx6_pcie_driver = { > .name = "imx6q-pcie", > .owner = THIS_MODULE, > .of_match_table = imx6_pcie_of_match, > + .pm = &imx6_pcie_pm_ops, > }, > }; > > -- > 2.0.0 > > > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | >
Hi Shawn, Over the weekend I tried to reproduce your problem on a SabreSD board, but wasn't able to trigger the issue. 3.16-rc3 with PCIe active works just fine over a suspend and resume cycle for me. One possibly relevant difference is that I've booted with NFSroot, while it seems you are using a SATA connected device. Is this right? If so, can you test if it works if you boot from SDcard or the like? This might be relevant as PCIe and SATA share some clocks. Regards, Lucas Am Dienstag, den 01.07.2014, 14:51 +0800 schrieb Shawn Guo: > On Mon, Jun 30, 2014 at 03:44:24PM +0200, Lucas Stach wrote: > > Hi Shawn, > > > > can you please test the attached patch on top of 3.16-rc* to see if it > > helps? If it works for you I would like to try and get this into 3.16 as > > a bugfix. > > Unfortunately, it doesn't work. With your change, now it hangs in > suspend procedure. > > $ echo mem > /sys/power/state > PM: Syncing filesystems ... done. > PM: Preparing system for mem sleep > Freezing user space processes ... (elapsed 0.005 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done. > PM: Entering mem sleep > sd 0:0:0:0: [sda] Synchronizing SCSI cache > sd 0:0:0:0: [sda] Stopping disk > PM: suspend of devices complete after 102.992 msecs > PM: suspend devices took 0.110 seconds > PM: late suspend of devices complete after 12.808 msecs > > Shawn > > > > > Regards, > > Lucas > > > > --------------------------->8----------------------------- > > From f3bfdc9c19249188fa153b1568c3129cd31af4f5 Mon Sep 17 00:00:00 2001 > > From: Lucas Stach <l.stach@pengutronix.de> > > Date: Mon, 30 Jun 2014 15:33:04 +0200 > > Subject: [PATCH] PCI: imx6: add workaround for errata ERR005723 > > > > Fixes system hang after resume from suspend to mem. > > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de> > > --- > > drivers/pci/host/pci-imx6.c | 33 +++++++++++++++++++++++++++++++++ > > 1 file changed, 33 insertions(+) > > > > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c > > index a568efaa331c..5c58a3ee5dbf 100644 > > --- a/drivers/pci/host/pci-imx6.c > > +++ b/drivers/pci/host/pci-imx6.c > > @@ -589,6 +589,38 @@ static int __init imx6_pcie_probe(struct platform_device *pdev) > > return 0; > > } > > > > +#ifdef CONFIG_PM_SLEEP > > +static int imx6_pcie_suspend(struct device *dev) > > +{ > > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev); > > + > > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, > > + IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18); > > + > > + return 0; > > +} > > + > > +static int imx6_pcie_resume(struct device *dev) > > +{ > > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev); > > + > > + /* > > + * This is a workaround for > > + * ERR005723: PCIe does not support L2 power down > > + * Toggling the PHY PD bit around system L2 state switching seems to be > > + * enough to wake the PCIe logic after a power down. > > + */ > > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, > > + IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18); > > + > > + return 0; > > +} > > +#endif > > + > > +static SIMPLE_DEV_PM_OPS(imx6_pcie_pm_ops, > > + imx6_pcie_suspend, > > + imx6_pcie_resume); > > + > > static const struct of_device_id imx6_pcie_of_match[] = { > > { .compatible = "fsl,imx6q-pcie", }, > > {}, > > @@ -600,6 +632,7 @@ static struct platform_driver imx6_pcie_driver = { > > .name = "imx6q-pcie", > > .owner = THIS_MODULE, > > .of_match_table = imx6_pcie_of_match, > > + .pm = &imx6_pcie_pm_ops, > > }, > > }; > > > > -- > > 2.0.0 > > > > > > -- > > Pengutronix e.K. | Lucas Stach | > > Industrial Linux Solutions | http://www.pengutronix.de/ | > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote: > Hi Shawn, > > Over the weekend I tried to reproduce your problem on a SabreSD board, > but wasn't able to trigger the issue. 3.16-rc3 with PCIe active works > just fine over a suspend and resume cycle for me. That's strange. In my setup, PCIe support is enabled in kernel and DT, but I do not have a PCIe device connected to the board. > > One possibly relevant difference is that I've booted with NFSroot, while > it seems you are using a SATA connected device. Is this right? I have a SATA disk connected, but did boot with NFSroot. > If so, > can you test if it works if you boot from SDcard or the like? This might > be relevant as PCIe and SATA share some clocks. I tried to disable SATA support completely, but it doesn't help. $ echo mem > /sys/power/state [ 410.052595] PM: Syncing filesystems ... done. [ 410.150033] PM: Preparing system for mem sleep [ 410.207963] Freezing user space processes ... (elapsed 0.004 seconds) done. [ 410.219796] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 410.230243] PM: Entering mem sleep [ 410.316574] PM: suspend of devices complete after 79.461 msecs [ 410.322498] PM: suspend devices took 0.090 seconds [ 410.332655] PM: late suspend of devices complete after 5.338 msecs Shawn
On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote: > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote: > > Hi Shawn, > > > > Over the weekend I tried to reproduce your problem on a SabreSD board, > > but wasn't able to trigger the issue. 3.16-rc3 with PCIe active works > > just fine over a suspend and resume cycle for me. > > That's strange. In my setup, PCIe support is enabled in kernel and DT, > but I do not have a PCIe device connected to the board. > > > > > One possibly relevant difference is that I've booted with NFSroot, while > > it seems you are using a SATA connected device. Is this right? > > I have a SATA disk connected, but did boot with NFSroot. > > > If so, > > can you test if it works if you boot from SDcard or the like? This might > > be relevant as PCIe and SATA share some clocks. > > I tried to disable SATA support completely, but it doesn't help. Lucas, any news on this? Or should we just try to use Richard's patch to solve the problem? Shawn
Hi Shawn, Am Mittwoch, den 16.07.2014, 14:55 +0800 schrieb Shawn Guo: > On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote: > > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote: > > > Hi Shawn, > > > > > > Over the weekend I tried to reproduce your problem on a SabreSD board, > > > but wasn't able to trigger the issue. 3.16-rc3 with PCIe active works > > > just fine over a suspend and resume cycle for me. > > > > That's strange. In my setup, PCIe support is enabled in kernel and DT, > > but I do not have a PCIe device connected to the board. > > > > > > > > One possibly relevant difference is that I've booted with NFSroot, while > > > it seems you are using a SATA connected device. Is this right? > > > > I have a SATA disk connected, but did boot with NFSroot. > > > > > If so, > > > can you test if it works if you boot from SDcard or the like? This might > > > be relevant as PCIe and SATA share some clocks. > > > > I tried to disable SATA support completely, but it doesn't help. > > Lucas, any news on this? Or should we just try to use Richard's patch > to solve the problem? I would like to understand the problem first before throwing "fixes" at the issue. As you said this isn't a regression we are in no hurry and should try to analyze the issue properly. I just retested and I'm still not able to reproduce the issue on my SabreSD. Maybe there are board revision that exhibit different behavior? My board has two sticks on saying "Rev B3" and "Rev X3". As you can see from the log suspend/resume is working fine for me with kernel 3.16-rc5 + imx_v6_v7_defconfig. root@XXX:~ echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.004 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 95.846 msecs PM: suspend devices took 0.100 seconds PM: late suspend of devices complete after 5.395 msecs PM: noirq suspend of devices complete after 4.914 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Enabling non-boot CPUs ... CPU1: Booted secondary processor CPU1 is up CPU2: Booted secondary processor CPU2 is up CPU3: Booted secondary processor CPU3 is up PM: noirq resume of devices complete after 1556.385 msecs PM: early resume of devices complete after 3.134 msecs PM: resume of devices complete after 153.568 msecs PM: resume devices took 0.160 seconds Restarting tasks ... done. ata1: SATA link down (SStatus 0 SControl 300) fec 2188000.ethernet eth0: Link is Down fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off root@XXX:~ echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.002 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 87.638 msecs PM: suspend devices took 0.090 seconds PM: late suspend of devices complete after 4.528 msecs PM: noirq suspend of devices complete after 5.031 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Enabling non-boot CPUs ... CPU1: Booted secondary processor CPU1 is up CPU2: Booted secondary processor CPU2 is up CPU3: Booted secondary processor CPU3 is up PM: noirq resume of devices complete after 1425.302 msecs PM: early resume of devices complete after 2.736 msecs PM: resume of devices complete after 156.013 msecs PM: resume devices took 0.160 seconds Restarting tasks ... done. ata1: SATA link down (SStatus 0 SControl 300) fec 2188000.ethernet eth0: Link is Down fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off root@XXX:~
> -----Original Message----- > From: Lucas Stach [mailto:l.stach@pengutronix.de] > Sent: Thursday, July 17, 2014 9:55 PM > To: Guo Shawn-R65073 > Cc: Zhu Richard-R65037; linux-pci@vger.kernel.org; Sascha Hauer; Bjorn Helgaas; > Shawn Guo; Fabio Estevam; linux-arm-kernel@lists.infradead.org > Subject: Re: The imx6q suspend/resume is broken on 3.16-rc due to PCIe > > Hi Shawn, > > Am Mittwoch, den 16.07.2014, 14:55 +0800 schrieb Shawn Guo: > > On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote: > > > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote: > > > > Hi Shawn, > > > > > > > > Over the weekend I tried to reproduce your problem on a SabreSD > > > > board, but wasn't able to trigger the issue. 3.16-rc3 with PCIe > > > > active works just fine over a suspend and resume cycle for me. > > > > > > That's strange. In my setup, PCIe support is enabled in kernel and > > > DT, but I do not have a PCIe device connected to the board. > > > > > > > > > > > One possibly relevant difference is that I've booted with NFSroot, > > > > while it seems you are using a SATA connected device. Is this right? > > > > > > I have a SATA disk connected, but did boot with NFSroot. > > > > > > > If so, > > > > can you test if it works if you boot from SDcard or the like? This > > > > might be relevant as PCIe and SATA share some clocks. > > > > > > I tried to disable SATA support completely, but it doesn't help. > > > > Lucas, any news on this? Or should we just try to use Richard's patch > > to solve the problem? > > I would like to understand the problem first before throwing "fixes" at the > issue. As you said this isn't a regression we are in no hurry and should try > to analyze the issue properly. I just retested and I'm still not able to > reproduce the issue on my SabreSD. Maybe there are board revision that exhibit > different behavior? My board has two sticks on saying "Rev B3" and "Rev X3". > > As you can see from the log suspend/resume is working fine for me with kernel > 3.16-rc5 + imx_v6_v7_defconfig. [Richard] As I know that imx6 pcie is not enabled in imx_v6_v7_defconfig in default. Menu-config is required if you want to tests system suspend/resume with pcie built-in. Just double confirm, is the pcie built-in at your side? > > root@XXX:~ echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.004 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: suspend of devices complete after 95.846 msecs > PM: suspend devices took 0.100 seconds > PM: late suspend of devices complete after 5.395 msecs > PM: noirq suspend of devices complete after 4.914 msecs Disabling non-boot > CPUs ... > CPU1: shutdown > CPU2: shutdown > CPU3: shutdown > Enabling non-boot CPUs ... > CPU1: Booted secondary processor > CPU1 is up > CPU2: Booted secondary processor > CPU2 is up > CPU3: Booted secondary processor > CPU3 is up > PM: noirq resume of devices complete after 1556.385 msecs > PM: early resume of devices complete after 3.134 msecs > PM: resume of devices complete after 153.568 msecs > PM: resume devices took 0.160 seconds > Restarting tasks ... done. > ata1: SATA link down (SStatus 0 SControl 300) fec 2188000.ethernet eth0: Link > is Down fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off > root@XXX:~ echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.002 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: suspend of devices complete after 87.638 msecs > PM: suspend devices took 0.090 seconds > PM: late suspend of devices complete after 4.528 msecs > PM: noirq suspend of devices complete after 5.031 msecs Disabling non-boot > CPUs ... > CPU1: shutdown > CPU2: shutdown > CPU3: shutdown > Enabling non-boot CPUs ... > CPU1: Booted secondary processor > CPU1 is up > CPU2: Booted secondary processor > CPU2 is up > CPU3: Booted secondary processor > CPU3 is up > PM: noirq resume of devices complete after 1425.302 msecs > PM: early resume of devices complete after 2.736 msecs > PM: resume of devices complete after 156.013 msecs > PM: resume devices took 0.160 seconds > Restarting tasks ... done. > ata1: SATA link down (SStatus 0 SControl 300) fec 2188000.ethernet eth0: Link > is Down fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off > root@XXX:~ > > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | Best Regards Richard Zhu
Am Freitag, den 18.07.2014, 02:11 +0000 schrieb Hong-Xing.Zhu@freescale.com: > > -----Original Message----- > > From: Lucas Stach [mailto:l.stach@pengutronix.de] > > Sent: Thursday, July 17, 2014 9:55 PM > > To: Guo Shawn-R65073 > > Cc: Zhu Richard-R65037; linux-pci@vger.kernel.org; Sascha Hauer; Bjorn Helgaas; > > Shawn Guo; Fabio Estevam; linux-arm-kernel@lists.infradead.org > > Subject: Re: The imx6q suspend/resume is broken on 3.16-rc due to PCIe > > > > Hi Shawn, > > > > Am Mittwoch, den 16.07.2014, 14:55 +0800 schrieb Shawn Guo: > > > On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote: > > > > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote: > > > > > Hi Shawn, > > > > > > > > > > Over the weekend I tried to reproduce your problem on a SabreSD > > > > > board, but wasn't able to trigger the issue. 3.16-rc3 with PCIe > > > > > active works just fine over a suspend and resume cycle for me. > > > > > > > > That's strange. In my setup, PCIe support is enabled in kernel and > > > > DT, but I do not have a PCIe device connected to the board. > > > > > > > > > > > > > > One possibly relevant difference is that I've booted with NFSroot, > > > > > while it seems you are using a SATA connected device. Is this right? > > > > > > > > I have a SATA disk connected, but did boot with NFSroot. > > > > > > > > > If so, > > > > > can you test if it works if you boot from SDcard or the like? This > > > > > might be relevant as PCIe and SATA share some clocks. > > > > > > > > I tried to disable SATA support completely, but it doesn't help. > > > > > > Lucas, any news on this? Or should we just try to use Richard's patch > > > to solve the problem? > > > > I would like to understand the problem first before throwing "fixes" at the > > issue. As you said this isn't a regression we are in no hurry and should try > > to analyze the issue properly. I just retested and I'm still not able to > > reproduce the issue on my SabreSD. Maybe there are board revision that exhibit > > different behavior? My board has two sticks on saying "Rev B3" and "Rev X3". > > > > As you can see from the log suspend/resume is working fine for me with kernel > > 3.16-rc5 + imx_v6_v7_defconfig. > [Richard] As I know that imx6 pcie is not enabled in imx_v6_v7_defconfig in default. > Menu-config is required if you want to tests system suspend/resume with pcie built-in. > Just double confirm, is the pcie built-in at your side? This is not right, PCI is enabled in imx_v6_v7_defconfig since c0bea59ca58e30fb8fd29254569bdaae482398ad "ARM: imx_v6_v7_defconfig: Select PCI support". However I seem to have a board with rev 1.1 silicon and although the pci driver starts up it never establishes a link. So my board may just work by chance as I don't really know the differences between rev 1.1 silicon and later revisions. Regards, Lucas
On Fri, Jul 18, 2014 at 11:21:48AM +0200, Lucas Stach wrote: > However I seem to have a board with rev 1.1 silicon and although the pci > driver starts up it never establishes a link. So my board may just work > by chance as I don't really know the differences between rev 1.1 silicon > and later revisions. Lucas, thanks for the info. I just checked my board on which the issue is seen, and found it has a rev 1.3 silicon. I just tested on a board with rev 1.2 and did not even see the issue. Richard, Is this an issue only with rev 1.3? Shawn
On Sun, Jul 20, 2014 at 11:50 PM, Shawn Guo <shawn.guo@freescale.com> wrote: > On Fri, Jul 18, 2014 at 11:21:48AM +0200, Lucas Stach wrote: >> However I seem to have a board with rev 1.1 silicon and although the pci >> driver starts up it never establishes a link. So my board may just work >> by chance as I don't really know the differences between rev 1.1 silicon >> and later revisions. > > Lucas, thanks for the info. > > I just checked my board on which the issue is seen, and found it has a > rev 1.3 silicon. I just tested on a board with rev 1.2 and did not even > see the issue. > > Richard, > > Is this an issue only with rev 1.3? I could see this issue on my board with rev 1.2.
On Sun, Jul 20, 2014 at 11:55:42PM -0300, Fabio Estevam wrote: > On Sun, Jul 20, 2014 at 11:50 PM, Shawn Guo <shawn.guo@freescale.com> wrote: > > On Fri, Jul 18, 2014 at 11:21:48AM +0200, Lucas Stach wrote: > >> However I seem to have a board with rev 1.1 silicon and although the pci > >> driver starts up it never establishes a link. So my board may just work > >> by chance as I don't really know the differences between rev 1.1 silicon > >> and later revisions. > > > > Lucas, thanks for the info. > > > > I just checked my board on which the issue is seen, and found it has a > > rev 1.3 silicon. I just tested on a board with rev 1.2 and did not even > > see the issue. > > > > Richard, > > > > Is this an issue only with rev 1.3? > > I could see this issue on my board with rev 1.2. Hmm, that's strange. I tested two imx6q-sabresd boards with rev 1.2 silicon, and did not see this issue. Hopefully, someone else can also test. Shawn
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index a568efaa331c..5c58a3ee5dbf 100644 --- a/drivers/pci/host/pci-imx6.c +++ b/drivers/pci/host/pci-imx6.c @@ -589,6 +589,38 @@ static int __init imx6_pcie_probe(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int imx6_pcie_suspend(struct device *dev) +{ + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev); + + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, + IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18); + + return 0; +} + +static int imx6_pcie_resume(struct device *dev) +{ + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev); + + /* + * This is a workaround for + * ERR005723: PCIe does not support L2 power down + * Toggling the PHY PD bit around system L2 state switching seems to be + * enough to wake the PCIe logic after a power down. + */ + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, + IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18); + + return 0; +} +#endif + +static SIMPLE_DEV_PM_OPS(imx6_pcie_pm_ops, + imx6_pcie_suspend, + imx6_pcie_resume); + static const struct of_device_id imx6_pcie_of_match[] = { { .compatible = "fsl,imx6q-pcie", }, {}, @@ -600,6 +632,7 @@ static struct platform_driver imx6_pcie_driver = { .name = "imx6q-pcie", .owner = THIS_MODULE, .of_match_table = imx6_pcie_of_match, + .pm = &imx6_pcie_pm_ops, }, };