hi Matti,
I heard you've been helpful in the past - thank for that! Here's a
question I'm currently stuck at: In short, imx8mq can't yet resume from
suspend when using the bd71839 pmic via i2c. The original report here,
just for the background:
https://lore.kernel.org/linux-arm-kernel/[email protected]/T/#u
But here's what I *think* is going on: When the (buck3) regulator from
bd71839 is the power-supply for a power domain (gpu), the power domain
driver can't resume because buck3 can't be enabled when the pmic isn't
running yet. I'm still a bit uncertain, but here's the logs when simply
printing in the respective suspend/resume callbacks:
[ 452.199600] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume_noirq
[ 452.301450] imx-pgc imx-pgc-domain.5: failed to enable regulator: -
ETIMEDOUT
[ 452.320593] imx-i2c 30a20000.i2c: i2c_imx_resume
[ 452.322152] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume
[ 452.323853] imx-i2c 30a30000.i2c: i2c_imx_resume
[ 452.324778] imx-i2c 30a40000.i2c: i2c_imx_resume
[ 452.325017] imx-i2c 30a50000.i2c: i2c_imx_resume
and regulator_enable() in imx-pgc is called from genpd_resume_noirq().
At this point, does any workaround or fix come to your mind I could
test? I guess i2c needs to be resumed too...
Why does power domain only implement resume_noirq? How could I untangle
this?
thank you very much,
martin
On Tue, Jun 14, 2022 at 11:06:06AM +0200, Martin Kepplinger wrote:
> and regulator_enable() in imx-pgc is called from genpd_resume_noirq().
>
> At this point, does any workaround or fix come to your mind I could
> test? I guess i2c needs to be resumed too...
>
> Why does power domain only implement resume_noirq? How could I untangle
> this?
Indeed - if a power domain is controlling regulators then I'd not expect
things to go well if it tries to resume without interrupts, there will
be some things that can be done purely with GPIOs but that's depending
on the hardware having wired things up that way and the operations
needed by the power domain mapping well onto what can be done with
GPIOs.
Hi dee Ho Martin,
On 6/14/22 12:06, Martin Kepplinger wrote:
> hi Matti,
>
> I heard you've been helpful in the past - thank for that!
I try to do what I can - It may not be much though :/
> Here's a
> question I'm currently stuck at: In short, imx8mq can't yet resume from
> suspend when using the bd71839 pmic via i2c. The original report here,
> just for the background:
>
> https://lore.kernel.org/linux-arm-kernel/[email protected]/T/#u
Oh. I've missed this one. (I'm not in CC - and no keywords like bd71837
found => mail filters evaded)
>
> But here's what I *think* is going on: When the (buck3) regulator from
> bd71839 is the power-supply for a power domain (gpu), the power domain
> driver can't resume because buck3 can't be enabled when the pmic isn't
> running yet.
My guess is that the buck enable is tried while the I2C is not yet
functional. The BUCK3 (and AFAIR all of the regulators on BD71837) are
controlled via I2C. There are no GPIO controlled regulators on BD71837(*)
(*)Well, you can control PMIC state with GPIO - which can be used to
toggle all PMIC regulators to predefined ON/OFF/VOLTAGE states. (namely
to SUSPEND, IDLE, RUN - don't remember all the dirty details though).
> I'm still a bit uncertain, but here's the logs when simply
> printing in the respective suspend/resume callbacks:
>
> [ 452.199600] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume_noirq
> [ 452.301450] imx-pgc imx-pgc-domain.5: failed to enable regulator: -
> ETIMEDOUT
> [ 452.320593] imx-i2c 30a20000.i2c: i2c_imx_resume
> [ 452.322152] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume
> [ 452.323853] imx-i2c 30a30000.i2c: i2c_imx_resume
> [ 452.324778] imx-i2c 30a40000.i2c: i2c_imx_resume
> [ 452.325017] imx-i2c 30a50000.i2c: i2c_imx_resume
>
> and regulator_enable() in imx-pgc is called from genpd_resume_noirq().
>
> At this point, does any workaround or fix come to your mind I could
> test? I guess i2c needs to be resumed too...
I think so too.
Best Regards
-- Matti
--
The Linux Kernel guy at ROHM Semiconductors
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~ this year is the year of a signature writers block ~~
On 6/14/22 12:18, Mark Brown wrote:
> On Tue, Jun 14, 2022 at 11:06:06AM +0200, Martin Kepplinger wrote:
>
>> and regulator_enable() in imx-pgc is called from genpd_resume_noirq().
>>
>> At this point, does any workaround or fix come to your mind I could
>> test? I guess i2c needs to be resumed too...
>>
>> Why does power domain only implement resume_noirq? How could I untangle
>> this?
>
> Indeed - if a power domain is controlling regulators then I'd not expect
> things to go well if it tries to resume without interrupts, there will
> be some things that can be done purely with GPIOs but that's depending
> on the hardware having wired things up that way and the operations
> needed by the power domain mapping well onto what can be done with
> GPIOs.
In case of BD71837 only the PMIC 'state changes' could be initiated by
GPIO. And if the state is not 'RUN' the regulator enable/disable state
can not be controlled by the Linux driver (or - as far as I remember the
driver I've authored does not support that. It _may_ be there were
enable/disable register for IDLE/SUSPEND states for _some_ of the
BD71837 regulators. Some probably had fixed states. In any case, I don't
think the driver touched them after initial setup).
Best Regards
-- Matti
--
The Linux Kernel guy at ROHM Semiconductors
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~ this year is the year of a signature writers block ~~
Am Dienstag, dem 14.06.2022 um 10:18 +0100 schrieb Mark Brown:
> On Tue, Jun 14, 2022 at 11:06:06AM +0200, Martin Kepplinger wrote:
>
> > and regulator_enable() in imx-pgc is called from
> > genpd_resume_noirq().
> >
> > At this point, does any workaround or fix come to your mind I could
> > test? I guess i2c needs to be resumed too...
> >
> > Why does power domain only implement resume_noirq? How could I
> > untangle
> > this?
>
> Indeed - if a power domain is controlling regulators then I'd not
> expect
> things to go well if it tries to resume without interrupts, there
> will
> be some things that can be done purely with GPIOs but that's
> depending
> on the hardware having wired things up that way and the operations
> needed by the power domain mapping well onto what can be done with
> GPIOs.
and what's the danger when resuming power domains later?:
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2062,8 +2062,8 @@ int pm_genpd_init(struct generic_pm_domain
*genpd,
genpd->domain.ops.runtime_suspend = genpd_runtime_suspend;
genpd->domain.ops.runtime_resume = genpd_runtime_resume;
genpd->domain.ops.prepare = genpd_prepare;
- genpd->domain.ops.suspend_noirq = genpd_suspend_noirq;
- genpd->domain.ops.resume_noirq = genpd_resume_noirq;
+ genpd->domain.ops.suspend = genpd_suspend_noirq;
+ genpd->domain.ops.resume = genpd_resume_noirq;
genpd->domain.ops.freeze_noirq = genpd_freeze_noirq;
genpd->domain.ops.thaw_noirq = genpd_thaw_noirq;
genpd->domain.ops.poweroff_noirq = genpd_poweroff_noirq;
thanks for taking the time,
martin
On Tue, Jun 14, 2022 at 11:57:18AM +0200, Martin Kepplinger wrote:
> Am Dienstag, dem 14.06.2022 um 10:18 +0100 schrieb Mark Brown:
> > Indeed - if a power domain is controlling regulators then I'd not
> > expect
> > things to go well if it tries to resume without interrupts, there
> > will
> > be some things that can be done purely with GPIOs but that's
> > depending
> > on the hardware having wired things up that way and the operations
> > needed by the power domain mapping well onto what can be done with
> > GPIOs.
>
> and what's the danger when resuming power domains later?:
If there's a device that needs to early resume in a power domain that
needs to do something on resume then presumably this will mess up the
ordering. You probably need a separate power domain type, or both
operations.
Am Dienstag, dem 14.06.2022 um 11:16 +0100 schrieb Mark Brown:
> On Tue, Jun 14, 2022 at 11:57:18AM +0200, Martin Kepplinger wrote:
> > Am Dienstag, dem 14.06.2022 um 10:18 +0100 schrieb Mark Brown:
>
> > > Indeed - if a power domain is controlling regulators then I'd not
> > > expect
> > > things to go well if it tries to resume without interrupts, there
> > > will
> > > be some things that can be done purely with GPIOs but that's
> > > depending
> > > on the hardware having wired things up that way and the
> > > operations
> > > needed by the power domain mapping well onto what can be done
> > > with
> > > GPIOs.
> >
> > and what's the danger when resuming power domains later?:
>
> If there's a device that needs to early resume in a power domain that
> needs to do something on resume then presumably this will mess up the
> ordering. You probably need a separate power domain type, or both
> operations.
hi Mark, the followup to this would be my first try to fix this:
https://lore.kernel.org/linux-arm-kernel/[email protected]/T/#t
thank you for you help so far,
martin