RE: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS suspend skip

From: Hongxing Zhu

Date: Mon Apr 06 2026 - 23:32:07 EST


> -----Original Message-----
> From: mani@xxxxxxxxxx <mani@xxxxxxxxxx>
> Sent: 2026年4月4日 1:03
> To: Hongxing Zhu <hongxing.zhu@xxxxxxx>
> Cc: Bjorn Helgaas <helgaas@xxxxxxxxxx>; Frank Li <frank.li@xxxxxxx>;
> jingoohan1@xxxxxxxxx; l.stach@xxxxxxxxxxxxxx; lpieralisi@xxxxxxxxxx;
> kwilczynski@xxxxxxxxxx; robh@xxxxxxxxxx; bhelgaas@xxxxxxxxxx;
> s.hauer@xxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx; festevam@xxxxxxxxx;
> linux-pci@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> imx@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS
> suspend skip
>
> On Tue, Mar 24, 2026 at 02:01:58AM +0000, Hongxing Zhu wrote:
> > > -----Original Message-----
> > > From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
> > > Sent: 2026年3月24日 6:09
> > > To: Hongxing Zhu <hongxing.zhu@xxxxxxx>
> > > Cc: Frank Li <frank.li@xxxxxxx>; jingoohan1@xxxxxxxxx;
> > > l.stach@xxxxxxxxxxxxxx; lpieralisi@xxxxxxxxxx;
> > > kwilczynski@xxxxxxxxxx; mani@xxxxxxxxxx; robh@xxxxxxxxxx;
> > > bhelgaas@xxxxxxxxxx; s.hauer@xxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx;
> > > festevam@xxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx;
> > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> > > imx@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > > stable@xxxxxxxxxxxxxxx
> > > Subject: Re: [PATCH v1] PCI: imx6: Add force_suspend flag to
> > > override L1SS suspend skip
> > >
> > > On Wed, Mar 18, 2026 at 02:55:45AM +0000, Hongxing Zhu wrote:
> > > > > -----Original Message-----
> > > > > From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
> > > > ... [messed up quoting]
> > >
> > > > > On Tue, Mar 17, 2026 at 02:12:56PM +0800, Richard Zhu wrote:
> > > > > > Add a force_suspend flag to allow platform drivers to force
> > > > > > the PCIe link into L2 state during suspend, even when L1SS
> > > > > > (ASPM L1
> > > > > > Sub-States) is enabled.
> > > > > >
> > > > > > By default, the DesignWare PCIe host controller skips L2
> > > > > > suspend when L1SS is supported to meet low resume latency
> > > > > > requirements for devices like NVMe. However, some platforms
> > > > > > like i.MX PCIe need to enter L2 state for proper power
> > > > > > management regardless of L1SS
> > > support.
> > > > > >
> > > > > > Enable force_suspend for i.MX PCIe to ensure the link enters
> > > > > > L2 during system suspend.
> > > > >
> > > > > I'm a little bit skeptical about this.
> > > > >
> > > > > What exactly does a "low resume latency requirement" mean? Is
> > > > > this an actual functional requirement that's special to NVMe, or
> > > > > is it just the desire for low resume latency that everybody has
> > > > > for all devices?
> > > >
> > > > From my understanding, L1SS mode is characterized by lower latency
> > > > when compared to L2 or L3 modes.
> > > >
> > > > It can be used on all devices, avoiding frequent power on/off cycles.
> > > > NVMe can also extend the service life of the equipment.
> > >
> > > All the above applies to all platforms, so it's not an argument for
> > > i.MX-specific code here.
> > >
> > Hi Bjorn:
> > Thanks for your kindly review.
> > Yes, it is.
> > > > > Is there something special about i.MX here? Why do we want i.MX
> > > > > to be different from other host controllers?
> > > >
> > > > i.MX PCIe loses power supply during Deep Sleep Mode (DSM),
> > > > requiring full reinitialization after system wake-up.
> > >
> > > I don't know what DSM means in PCIe or how it would help justify
> > > this change.
> > >
> > i.MX PCIe power is gated off during suspend, requiring full
> > reinitialization on resume
> >
>
> Is this an unconditional behavior? What if the PCIe device is configured as a
> wakeup source like WOL, WOW? And if you connect NVMe, this behavior will
> result in resume failure as NVMe driver expects the power to be retained if
> ASPM is supported.

Yes, this is unconditional behavior. The i.MX PCIe controller exclusively
supports sideband wakeup mechanisms, which operate independently of the
PCIe link state and device power configuration.

For devices configured as wakeup sources (WOL, WOW, etc.): The sideband
wakeup path bypasses the standard PCIe power management, so these
configurations do not impact the i.MX PCIe RC controller's suspend/resume
behavior.

For NVMe devices with ASPM: While NVMe drivers typically expect power
retention when ASPM is enabled, the i.MX implementation's sideband wakeup
mechanism operates through a separate signaling path. The wakeup functionality
does not depend on maintaining PCIe link power, thus avoiding conflicts with
NVMe power state expectations.

Best Regards
Richard Zhu
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்