Subject: Re: [PATCH] omap3: give off mode enable a more prominent place

From: Tony Lindgren <[email-masked]>
Date: Mon, 4 Feb 2019 10:43:17 -0800

* Andreas Kemnade <[email-masked]> [190204 18:33]:
> On Mon, 4 Feb 2019 07:56:04 -0800
> Tony Lindgren <[email-masked]> wrote:
> 
> > * Andreas Kemnade <[email-masked]> [190202 06:01]:
> > > Enabling off mode was only reachable deeply hidden
> > > in the debugfs. As powersaving is an important feature,
> > > move the option out of its shady place.  
> > 
> > How about let's enable always if we have the twl4030
> > configured to allow it? You can just check if the dts has
> > "ti,twl4030-power-idle" or "ti,twl4030-power-idle-osc-off"
> > properties set.
> > 
> > In order to enable deeper idle states, the user space still
> > needs to idle the UARTs and possibly other hardware blocking
> > idle. So we should be safe there.
> > 
> Let us not mix up runtime pm and system pm. The uarts need
> to be idled for runtime suspend, but they are off/ret for
> system suspend without userspace intervention, so allowing off mode
> will have an influence even without uart runtime suspend,
> and also probably for other powerdomains (non-core/per).
> So we still need to be sure to handle at least some erratas and
> context save/restore correctly.

True that's a good point.

> Your Idea seems to be in pseudocode
> if (powersaving_wanted)
> 	enable_off_mode()
> 
> I had something in mind like
> if (system_is_trusted_to_handle_offmode()
> 	enable_off_mode()

For omap3, the properties for "ti,twl4030-power-idle" or
"ti,twl4030-power-idle-osc-off" mean just that.

The PMIC is wired and configured for off mode, and those
properties should not be set unless the system is truly capable
of entering off mode. If not set, we should not enable off
idle by default.

Otherwise the boards should be already using just
"ti,twl4030-power" or "ti,twl4030-power-reset".

So it should be safe to set a flag for off_mode based
on that flag during boot, or set a flag for off
mode allowed if the flag is needed later on.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel