From: Tony Lindgren <tony@atomide.com> To: Adam Ford <aford173@gmail.com> Cc: Linux-OMAP <linux-omap@vger.kernel.org>, "Adam Ford" <adam.ford@logicpd.com>, "H. Nikolaus Schaller" <hns@goldelico.com>, "Benoît Cousson" <bcousson@baylibre.com>, "Rob Herring" <robh+dt@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Russell King" <linux@armlinux.org.uk>, devicetree <devicetree@vger.kernel.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, arm-soc <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Date: Tue, 22 Oct 2019 15:19:19 -0700 [thread overview] Message-ID: <20191022221919.GF5610@atomide.com> (raw) In-Reply-To: <CAHCN7xLy975mxX+cm56PMx-TKODEZjYPfMHb=byspKxYXXq7OA@mail.gmail.com> * Adam Ford <aford173@gmail.com> [191022 19:01]: > On Tue, Oct 22, 2019 at 11:22 AM Tony Lindgren <tony@atomide.com> wrote: > > > > Hi, > > > > * Adam Ford <aford173@gmail.com> [191007 15:06]: > > > The some in the OMAP3 family have a bandgap thermal sensor, but > > > omap2plus has it disabled. > > > > > > This patch enables the OMAP3_THERMAL by default like the rest of > > > the OMAP family. > > > > Looks like this breaks off mode during idle for omap3, and that's > > probably why it never got enabled. The difference in power > > consumption during idle is about 7mW vs 32mW for the SoC as > > measured from torpedo shunt for main_battery_som. > > > > I think the right fix might be simply to add handling for > > CPU_CLUSTER_PM_ENTER to the related thermal driver to disable > > it during idle like we have for gpio-omap.c for example. > > I am not sure I know where to start on fixing that issue. Would you > entertain enabling the driver if we set the device tree to 'disabled' > by default? This way if people want to to use it, it can be enabled > on a per-device option. Once the power stuff gets resolved, we might > be able to enable it by default. For people who are planning on using > the DM3730 @ 1GHz in high temp environments, I am not sure they'll > care about low power. They should both work fine together though. They are not mutually exclusive features. > I'll try to look into it when I have time, but I was hoping a > compromise might be a reasonable work-around. It should be hopefully a trivial fix.. I have not looked at the driver code though. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com> To: Adam Ford <aford173@gmail.com> Cc: "Mark Rutland" <mark.rutland@arm.com>, devicetree <devicetree@vger.kernel.org>, "H. Nikolaus Schaller" <hns@goldelico.com>, "Russell King" <linux@armlinux.org.uk>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Benoît Cousson" <bcousson@baylibre.com>, Linux-OMAP <linux-omap@vger.kernel.org>, "Adam Ford" <adam.ford@logicpd.com>, arm-soc <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Date: Tue, 22 Oct 2019 15:19:19 -0700 [thread overview] Message-ID: <20191022221919.GF5610@atomide.com> (raw) In-Reply-To: <CAHCN7xLy975mxX+cm56PMx-TKODEZjYPfMHb=byspKxYXXq7OA@mail.gmail.com> * Adam Ford <aford173@gmail.com> [191022 19:01]: > On Tue, Oct 22, 2019 at 11:22 AM Tony Lindgren <tony@atomide.com> wrote: > > > > Hi, > > > > * Adam Ford <aford173@gmail.com> [191007 15:06]: > > > The some in the OMAP3 family have a bandgap thermal sensor, but > > > omap2plus has it disabled. > > > > > > This patch enables the OMAP3_THERMAL by default like the rest of > > > the OMAP family. > > > > Looks like this breaks off mode during idle for omap3, and that's > > probably why it never got enabled. The difference in power > > consumption during idle is about 7mW vs 32mW for the SoC as > > measured from torpedo shunt for main_battery_som. > > > > I think the right fix might be simply to add handling for > > CPU_CLUSTER_PM_ENTER to the related thermal driver to disable > > it during idle like we have for gpio-omap.c for example. > > I am not sure I know where to start on fixing that issue. Would you > entertain enabling the driver if we set the device tree to 'disabled' > by default? This way if people want to to use it, it can be enabled > on a per-device option. Once the power stuff gets resolved, we might > be able to enable it by default. For people who are planning on using > the DM3730 @ 1GHz in high temp environments, I am not sure they'll > care about low power. They should both work fine together though. They are not mutually exclusive features. > I'll try to look into it when I have time, but I was hoping a > compromise might be a reasonable work-around. It should be hopefully a trivial fix.. I have not looked at the driver code though. Regards, Tony _______________________________________________ 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-10-22 22:19 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-07 22:05 [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Adam Ford 2019-10-07 22:05 ` Adam Ford 2019-10-07 22:05 ` [PATCH 2/2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families Adam Ford 2019-10-07 22:05 ` Adam Ford 2020-08-05 13:17 ` Adam Ford 2020-08-05 13:17 ` Adam Ford 2020-08-17 11:48 ` Tony Lindgren 2020-08-17 11:48 ` Tony Lindgren 2019-10-22 16:22 ` [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Tony Lindgren 2019-10-22 16:22 ` Tony Lindgren 2019-10-22 19:01 ` Adam Ford 2019-10-22 19:01 ` Adam Ford 2019-10-22 22:19 ` Tony Lindgren [this message] 2019-10-22 22:19 ` Tony Lindgren 2019-10-23 4:41 ` H. Nikolaus Schaller 2019-10-23 4:41 ` H. Nikolaus Schaller 2019-10-23 4:41 ` H. Nikolaus Schaller 2019-10-23 14:36 ` Tony Lindgren 2019-10-23 14:36 ` Tony Lindgren 2019-11-08 20:02 ` Adam Ford 2019-11-08 20:02 ` Adam Ford 2019-11-08 20:02 ` Adam Ford 2019-11-08 20:51 ` Tony Lindgren 2019-11-08 20:51 ` Tony Lindgren 2019-11-08 21:04 ` Adam Ford 2019-11-08 21:04 ` Adam Ford 2019-11-08 21:21 ` Tony Lindgren 2019-11-08 21:21 ` 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=20191022221919.GF5610@atomide.com \ --to=tony@atomide.com \ --cc=adam.ford@logicpd.com \ --cc=aford173@gmail.com \ --cc=bcousson@baylibre.com \ --cc=devicetree@vger.kernel.org \ --cc=hns@goldelico.com \ --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=mark.rutland@arm.com \ --cc=robh+dt@kernel.org \ /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.