Re: [PATCH v3] PCI: imx6: Add suspend/resume support for i.MX6QDL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 23, 2024 at 10:57:35AM +0200, Stefan Eichenberger wrote:
> On Tue, Oct 22, 2024 at 10:53:49AM -0500, Bjorn Helgaas wrote:
> > On Mon, Oct 21, 2024 at 02:49:13PM +0200, Stefan Eichenberger wrote:
> > > From: Stefan Eichenberger <stefan.eichenberger@xxxxxxxxxxx>
> > > 
> > > The suspend/resume support is broken on the i.MX6QDL platform. This
> > > patch resets the link upon resuming to recover functionality. It shares
> > > most of the sequences with other i.MX devices but does not touch the
> > > critical registers, which might break PCIe. This patch addresses the
> > > same issue as the following downstream commit:
> > > https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995
> > > In comparison this patch will also reset the device if possible because
> > > the downstream patch alone would still make the ath10k driver crash.
> > > Without this patch suspend/resume will not work if a PCIe device is
> > > connected. The kernel will hang on resume and print an error:
> > > ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
> ...

> > The downstream commit log ("WARNING: this is not the official
> > workaround; user should take own risk to use it") doesn't exactly
> > inspire confidence.
> > 
> > It sounds like this resets *endpoints*?  That sounds scary and
> > unexpected in suspend/resume.
> 
> Yes, I completely agree with you, but NXP has never come up with an
> "official" workaround. Our problem is that with the current
> implementation, suspend/resume is completely broken when a PCIe device
> is connected. With this proposed patch we at least have a working device
> after resume. Even for the other i.MX devices, the driver resets the
> endpoints in the resume function (imx_pcie_resume_noir ->
> imx_pcie_host_init -> imx_pcie_assert_core_reset), we just do that now
> for the i.MX6QDL as well. If it is more appropriate to call
> imx_pcie_assert_core_reset in resume as we do for the other devices,
> that would be fine with me as well. I was thinking that if we need to
> reset the device anyway, we could put it into reset on suspend, as this
> might save some extra power.

OK, I have to admit I don't know enough about suspend/resume.  Since
we already do that for other i.MX platforms, maybe an endpoint reset
is normal for suspend.  I really don't know.  In any case, if we do it
for other i.MX platforms, I'm OK doing it for this one too.

Bjorn




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux