Re: [PATCH] i2c: imx-lpi2c: change to PIO mode in system-wide suspend/resume progress

[Frank Li <Frank.li@nxp.com>]

On Wed, Nov 19, 2025 at 06:02:45AM +0000, Carlos Song wrote:
>
>
> > -----Original Message-----
> > From: Frank Li <frank.li@nxp.com>
> > Sent: Tuesday, November 18, 2025 11:58 PM
> > To: Carlos Song <carlos.song@nxp.com>
> > Cc: Aisheng Dong <aisheng.dong@nxp.com>; andi.shyti@kernel.org;
> > shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de;
> > festevam@gmail.com; linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] i2c: imx-lpi2c: change to PIO mode in system-wide
> > suspend/resume progress
> >
> > On Tue, Nov 18, 2025 at 03:18:37PM +0800, Carlos Song wrote:
> > > If a system-wide suspend or resume transition is in progress. LPI2C
> > > should use PIO to transfer data not DMA to avoid issue caused by not
> > > ready DMA HW resource.
> >
> > Currently there is no device link between the DMA engine and its DMA
> > consumer, which allows the DMA engine to suspend before the consumer.
> >
> > To avoid this, switch to PIO mode instead of DMA during suspend/resume so the
> > transfer does not rely on the DMA engine’s state.
> >
> > Notes: I suppose DMA engine suspend before LPI2C. Do you meet this or other
> > reason cause DMA HW resource ready.
> >
> > Not sure if below
> > https://lore.kernel.org/dmaengine/20250912-v6-16-topic-dma-devlink-v1-0-4de
> > bc2fbf901@pengutronix.de/
> > can fix your problem.
> >
> > Anyway, I think it is fine to use PIO at suspend to reduce dependence. But we
> > need know why DMA HW is not ready.
> >
> > Frank
> >
> Hi, Frank
>
> EDMA resume is in early stage and suspend is in late stage, but LPI2C resume and suspend are in NOIRQ stage.
> So LPI2C resource become ready earlier than EDMA. When IRQ enabled, immediately slave will trigger I2C to read data and
> the length meets the requirements for DMA usage, the DMA will be needed at this time. Within a very small time window,
> EDMA is still not resumed. The root cause is from here.

Put these information to commit message.

Frank

>
> dev link maybe useful in the same PM stage. But in different stage, I don’t know if it can help some.
> Maybe it is better that DMA move PM stage to NOIRQ, but now there is no dev link for EDMA, the resume/suspend sequence between LPI2C and EDMA in NOIRQ
> still cannot be completely guaranteed.
>
> I totally agree your point: use PIO to reduce dependence.
>
> If someday EDMA support dev link and move PM callback to NOIRQ stage both, this patch can be reverted I think.
>
> Carlos
> > >
> > > Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for
> > > LPI2C")
> > > Signed-off-by: Carlos Song <carlos.song@nxp.com>
> > > ---
> > >  drivers/i2c/busses/i2c-imx-lpi2c.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > index 2a0962a0b441..5050e14a9919 100644
> > > --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > @@ -592,6 +592,13 @@ static bool is_use_dma(struct lpi2c_imx_struct
> > *lpi2c_imx, struct i2c_msg *msg)
> > >  	if (!lpi2c_imx->can_use_dma)
> > >  		return false;
> > >
> > > +	/*
> > > +	 * When system is in suspend process. LPI2C should use PIO to transfer
> > data to
> > > +	 * avoid issue caused by not ready DMA HW resource.
> > > +	 */
> > > +	if (pm_suspend_in_progress())
> > > +		return false;
> > > +
> > >  	/*
> > >  	 * When the length of data is less than I2C_DMA_THRESHOLD,
> > >  	 * cpu mode is used directly to avoid low performance.
> > > --
> > > 2.34.1
> > >