[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<AM0PR0402MB3937ECA7D10662217F787AEBE8312@AM0PR0402MB3937.eurprd04.prod.outlook.com>
Date: Fri, 6 Dec 2024 09:13:16 +0000
From: Carlos Song <carlos.song@....com>
To: Andi Shyti <andi.shyti@...nel.org>
CC: "o.rempel@...gutronix.de" <o.rempel@...gutronix.de>,
"kernel@...gutronix.de" <kernel@...gutronix.de>, "shawnguo@...nel.org"
<shawnguo@...nel.org>, "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"festevam@...il.com" <festevam@...il.com>, Frank Li <frank.li@....com>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c: imx: make controller available until system
suspend_noirq() and from resume_noirq()
> -----Original Message-----
> From: Andi Shyti <andi.shyti@...nel.org>
> Sent: Thursday, December 5, 2024 7:54 PM
> To: Carlos Song <carlos.song@....com>
> Cc: o.rempel@...gutronix.de; kernel@...gutronix.de; shawnguo@...nel.org;
> s.hauer@...gutronix.de; festevam@...il.com; Frank Li <frank.li@....com>;
> linux-i2c@...r.kernel.org; imx@...ts.linux.dev;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org
> Subject: [EXT] Re: [PATCH] i2c: imx: make controller available until system
> suspend_noirq() and from resume_noirq()
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> Hi Carlos,
>
> ...
>
> > +static int i2c_imx_suspend(struct device *dev) {
> > + /*
> > + * Some I2C devices may need I2C controller up during resume_noirq()
> > + * or suspend_noirq(), if the controller is autosuspended, there is
> > + * no way to wakeup it once runtime pm is disabled (in
> suspend_late()).
> > + * When system resume, I2C controller will be available until runtime
> pm
> > + * is enabled(in_resume_early()). But it is too late for some devices.
> > + * Wakeup the controller in suspend() callback while runtime pm is
> enabled,
> > + * I2C controller will be available until suspend_noirq() callback
> > + * (pm_runtime_force_suspend()) is called. During the resume, I2C
> controller
> > + * can be restored by resume_noirq() callback
> (pm_runtime_force_resume()).
> > + * Then resume() callback enables autosuspend. It will make I2C
> controller
> > + * available until system suspend_noirq() and from resume_noirq().
> > + */
>
> Just made some little adjustments to the comment above, please let me know if
> they are fine:
>
> /*
> * Some I2C devices may need the I2C controller to remain active
> * during resume_noirq() or suspend_noirq(). If the controller is
> * autosuspended, there is no way to wake it up once runtime PM is
> * disabled (in suspend_late()).
> *
> * During system resume, the I2C controller will be available only
> * after runtime PM is re-enabled (in resume_early()). However, this
> * may be too late for some devices.
> *
> * Wake up the controller in the suspend() callback while runtime PM
> * is still enabled. The I2C controller will remain available until
> * the suspend_noirq() callback (pm_runtime_force_suspend()) is
> * called. During resume, the I2C controller can be restored by the
> * resume_noirq() callback (pm_runtime_force_resume()).
> *
> * Finally, the resume() callback re-enables autosuspend, ensuring
> * the I2C controller remains available until the system enters
> * suspend_noirq() and from resume_noirq().
> */
>
> If so, I will take it in.
>
Hi, Andi,
That is so nice!
> Andi
>
> > + return pm_runtime_resume_and_get(dev); }
Powered by blists - more mailing lists