[PATCH] i2c: imx: add irqf_no_suspend flag

[Clark Wang]

Hi Wolfram,

> -----Original Message-----
> From: Wolfram Sang <wsa at kernel.org>
> Sent: 2022年12月2日 7:11
> To: Oleksij Rempel <o.rempel at pengutronix.de>
> Cc: Clark Wang <xiaoning.wang at nxp.com>; linux at rempel-privat.de;
> kernel at pengutronix.de; shawnguo at kernel.org; s.hauer at pengutronix.de;
> festevam at gmail.com; dl-linux-imx <linux-imx at nxp.com>;
> linux-i2c at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] i2c: imx: add irqf_no_suspend flag
> 
> On Wed, Nov 16, 2022 at 10:02:49AM +0100, Oleksij Rempel wrote:
> > On Wed, Nov 16, 2022 at 03:44:31PM +0800, Clark Wang wrote:
> > > The i2c irq is masked when user starts an i2c transfer process
> > > during noirq suspend stage. As a result, i2c transfer fails.
> > > To solve the problem, IRQF_NO_SUSPEND is added to i2c bus.
> > >
> > > Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
> >
> > Acked-by: Oleksij Rempel <o.rempel at pengutronix.de>
> 
> Is this really happening? The driver already implements master_xfer_atomic,
> so I'd suspect it gets called instead?

Yes, you are right!

For the atomic API, I have a question. Will this api be used only in the noirq phase? We have a case that is currently bothering us.

Case description: Use the typec device interrupt pin to wake up the suspend system. We used ptn5110 for typec device. It's an i2c device, configure it via i2c bus.

We found that when the system is in the resume process of wakeup, because the typec interrupt is not disabled during suspend, once the noirq phase is over, it will immediately call i2c xfer to read and write ptn5110 to handle that interrupt. At this time, even resume_early has not been called, that is, the runtime pm of the i2c controller has not been enabled.
We made a workaround to check whether the runtime pm is enabled in i2c xfer. If it is not enabled, temporarily enable it, and call pm_runtime_disable at the end of i2c xfer. However, sometimes the resume_early will be called when the runtime pm is temporarily enabled in this workaround, resulting in an unbalanced enabling of the runtime pm of i2c controller.

Do you think this is a problem? Is the I2C atomic API helpful for this case?

Thank you very much!

Best Regards,
Clark Wang