From: Andreas Kemnade <andreas@kemnade.info> To: Tony Lindgren <tony@atomide.com> Cc: linux@armlinux.org.uk, khilman@kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, letux-kernel@openphoenux.org Subject: Re: [PATCH] omap3: give off mode enable a more prominent place Date: Wed, 6 Feb 2019 07:37:32 +0100 [thread overview] Message-ID: <20190206073732.35ad315f@kemnade.info> (raw) In-Reply-To: <20190204184317.GO5720@atomide.com> [-- Attachment #1: Type: text/plain, Size: 3227 bytes --] On Mon, 4 Feb 2019 10:43:17 -0800 Tony Lindgren <tony@atomide.com> wrote: > * Andreas Kemnade <andreas@kemnade.info> [190204 18:33]: > > On Mon, 4 Feb 2019 07:56:04 -0800 > > Tony Lindgren <tony@atomide.com> wrote: > > > > > * Andreas Kemnade <andreas@kemnade.info> [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. > Hmm, system = software + hardware. At least that I had in mind when writing this text. So for the software part: I guess off mode is on our all test schedule, so it should be reliable. dt describes the hardware, so there should be any MODE7 quirks defined if they are required and the proper pmic setting. But wait... twl4030-power.c is to a big part about switching regulators on and off. But how does that connect to hwmods going to ret or off mode? That is imho slightly another topic. Ok, looking a bit closer, there is the sys_off_mode line which needs to be used. So we have to derive that from the devicetree. > 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". > We have also ti,twl4030-power-omap3-sdp, ti,twl4030-power-omap3-ldp, ti,twl4030-power-omap3-evm so we have to maintain a list, especially if we want to allow another pmic. But since it is about connecting the soc to the pmic, we could also add a flag in the dtb on the soc side, so we are prepared if someone uses another pmic. It feels a bit strange to query something from devicetree for another device. Regards, Andreas PS: I hope my omap-gta04.dtsi-related patches have made their way into your review queue and are not starving in a generic lkml fallback folder [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Kemnade <andreas@kemnade.info> To: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org, khilman@kernel.org, linux-kernel@vger.kernel.org, linux@armlinux.org.uk, letux-kernel@openphoenux.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] omap3: give off mode enable a more prominent place Date: Wed, 6 Feb 2019 07:37:32 +0100 [thread overview] Message-ID: <20190206073732.35ad315f@kemnade.info> (raw) In-Reply-To: <20190204184317.GO5720@atomide.com> [-- Attachment #1.1: Type: text/plain, Size: 3227 bytes --] On Mon, 4 Feb 2019 10:43:17 -0800 Tony Lindgren <tony@atomide.com> wrote: > * Andreas Kemnade <andreas@kemnade.info> [190204 18:33]: > > On Mon, 4 Feb 2019 07:56:04 -0800 > > Tony Lindgren <tony@atomide.com> wrote: > > > > > * Andreas Kemnade <andreas@kemnade.info> [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. > Hmm, system = software + hardware. At least that I had in mind when writing this text. So for the software part: I guess off mode is on our all test schedule, so it should be reliable. dt describes the hardware, so there should be any MODE7 quirks defined if they are required and the proper pmic setting. But wait... twl4030-power.c is to a big part about switching regulators on and off. But how does that connect to hwmods going to ret or off mode? That is imho slightly another topic. Ok, looking a bit closer, there is the sys_off_mode line which needs to be used. So we have to derive that from the devicetree. > 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". > We have also ti,twl4030-power-omap3-sdp, ti,twl4030-power-omap3-ldp, ti,twl4030-power-omap3-evm so we have to maintain a list, especially if we want to allow another pmic. But since it is about connecting the soc to the pmic, we could also add a flag in the dtb on the soc side, so we are prepared if someone uses another pmic. It feels a bit strange to query something from devicetree for another device. Regards, Andreas PS: I hope my omap-gta04.dtsi-related patches have made their way into your review queue and are not starving in a generic lkml fallback folder [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-06 6:38 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-02 5:58 [PATCH] omap3: give off mode enable a more prominent place Andreas Kemnade 2019-02-02 5:58 ` Andreas Kemnade 2019-02-02 6:18 ` Andreas Kemnade 2019-02-02 6:18 ` Andreas Kemnade 2019-02-04 15:56 ` Tony Lindgren 2019-02-04 15:56 ` Tony Lindgren 2019-02-04 18:33 ` Andreas Kemnade 2019-02-04 18:33 ` Andreas Kemnade 2019-02-04 18:43 ` Tony Lindgren 2019-02-04 18:43 ` Tony Lindgren 2019-02-06 6:37 ` Andreas Kemnade [this message] 2019-02-06 6:37 ` Andreas Kemnade 2019-02-06 15:56 ` Tony Lindgren 2019-02-06 15:56 ` Tony Lindgren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190206073732.35ad315f@kemnade.info \ --to=andreas@kemnade.info \ --cc=khilman@kernel.org \ --cc=letux-kernel@openphoenux.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.