* [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL @ 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-22 16:22 ` [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Tony Lindgren 0 siblings, 2 replies; 13+ messages in thread From: Adam Ford @ 2019-10-07 22:05 UTC (permalink / raw) To: linux-omap Cc: Mark Rutland, devicetree, Tony Lindgren, hns, Russell King, adam.ford, Rob Herring, linux-arm-kernel, Benoît Cousson, Adam Ford, linux-kernel 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. Signed-off-by: Adam Ford <aford173@gmail.com> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 8f1c2b6f9e56..7e14a8c8bb29 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -292,6 +292,7 @@ CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_USER_SPACE=y CONFIG_CPU_THERMAL=y CONFIG_TI_THERMAL=y +CONFIG_OMAP3_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families 2019-10-07 22:05 [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Adam Ford @ 2019-10-07 22:05 ` Adam Ford 2020-08-05 13:17 ` Adam Ford 2019-10-22 16:22 ` [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Tony Lindgren 1 sibling, 1 reply; 13+ messages in thread From: Adam Ford @ 2019-10-07 22:05 UTC (permalink / raw) To: linux-omap Cc: Mark Rutland, devicetree, Tony Lindgren, hns, Russell King, adam.ford, Rob Herring, linux-arm-kernel, Benoît Cousson, Adam Ford, linux-kernel The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C depending on commercial or industrial temperature ratings. This patch expands the thermal information to include the limits of 90 and 105C for alert and critical. It sets the coolings-cells for the 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi. For boards who never use industrial temperatures, these can be changed on their respective device trees with something like: &cpu_alert0 { temperature = <85000>; /* millicelsius */ }; &cpu_crit { temperature = <90000>; /* millicelsius */ }; Signed-off-by: Adam Ford <aford173@gmail.com> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> # on GTA04A5 with dm3730cbp100 diff --git a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi index 235ecfd61e2d..dfbd0cb0b00b 100644 --- a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi +++ b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi @@ -17,4 +17,25 @@ cpu_thermal: cpu_thermal { /* sensor ID */ thermal-sensors = <&bandgap 0>; + + cpu_trips: trips { + cpu_alert0: cpu_alert { + temperature = <90000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_crit: cpu_crit { + temperature = <105000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "critical"; + }; + }; + + cpu_cooling_maps: cooling-maps { + map0 { + trip = <&cpu_alert0>; + cooling-device = + <&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi index 7b09cbee8bb8..99a7161bebb2 100644 --- a/arch/arm/boot/dts/omap34xx.dtsi +++ b/arch/arm/boot/dts/omap34xx.dtsi @@ -26,6 +26,7 @@ 600000 1350000 >; clock-latency = <300000>; /* From legacy driver */ + #cooling-cells = <2>; }; }; diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi index 1e552f08f120..8096b6ef0ae1 100644 --- a/arch/arm/boot/dts/omap36xx.dtsi +++ b/arch/arm/boot/dts/omap36xx.dtsi @@ -28,6 +28,7 @@ 800000 1325000 >; clock-latency = <300000>; /* From legacy driver */ + #cooling-cells = <2>; }; }; -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families 2019-10-07 22:05 ` [PATCH 2/2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families Adam Ford @ 2020-08-05 13:17 ` Adam Ford 2020-08-17 11:48 ` Tony Lindgren 0 siblings, 1 reply; 13+ messages in thread From: Adam Ford @ 2020-08-05 13:17 UTC (permalink / raw) To: Linux-OMAP Cc: Mark Rutland, devicetree, Tony Lindgren, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Adam Ford, arm-soc On Mon, Oct 7, 2019 at 5:06 PM Adam Ford <aford173@gmail.com> wrote: > > The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C > depending on commercial or industrial temperature ratings. > > This patch expands the thermal information to include the limits of 90 > and 105C for alert and critical. It sets the coolings-cells for the > 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi. > > For boards who never use industrial temperatures, these can be > changed on their respective device trees with something like: > > &cpu_alert0 { > temperature = <85000>; /* millicelsius */ > }; > > &cpu_crit { > temperature = <90000>; /* millicelsius */ > }; > > Signed-off-by: Adam Ford <aford173@gmail.com> > Tested-by: H. Nikolaus Schaller <hns@goldelico.com> # on GTA04A5 with dm3730cbp100 > Tony, I know this is an old thread. I am trying to revisit some of the other issues that came about with this, but is there any way we can get patch 2/2 applied? It might not do anything unless the bandgap sensor is enabled, but it at least gets us one step closer for those who choose to enable it. With 1GHz support now available, it would be nice to have the precautions to protect the processor from running too fast when its too hot. thanks adam > diff --git a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi > index 235ecfd61e2d..dfbd0cb0b00b 100644 > --- a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi > +++ b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi > @@ -17,4 +17,25 @@ cpu_thermal: cpu_thermal { > > /* sensor ID */ > thermal-sensors = <&bandgap 0>; > + > + cpu_trips: trips { > + cpu_alert0: cpu_alert { > + temperature = <90000>; /* millicelsius */ > + hysteresis = <2000>; /* millicelsius */ > + type = "passive"; > + }; > + cpu_crit: cpu_crit { > + temperature = <105000>; /* millicelsius */ > + hysteresis = <2000>; /* millicelsius */ > + type = "critical"; > + }; > + }; > + > + cpu_cooling_maps: cooling-maps { > + map0 { > + trip = <&cpu_alert0>; > + cooling-device = > + <&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; > + }; > + }; > }; > diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi > index 7b09cbee8bb8..99a7161bebb2 100644 > --- a/arch/arm/boot/dts/omap34xx.dtsi > +++ b/arch/arm/boot/dts/omap34xx.dtsi > @@ -26,6 +26,7 @@ > 600000 1350000 > >; > clock-latency = <300000>; /* From legacy driver */ > + #cooling-cells = <2>; > }; > }; > > diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi > index 1e552f08f120..8096b6ef0ae1 100644 > --- a/arch/arm/boot/dts/omap36xx.dtsi > +++ b/arch/arm/boot/dts/omap36xx.dtsi > @@ -28,6 +28,7 @@ > 800000 1325000 > >; > clock-latency = <300000>; /* From legacy driver */ > + #cooling-cells = <2>; > }; > }; > > -- > 2.17.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families 2020-08-05 13:17 ` Adam Ford @ 2020-08-17 11:48 ` Tony Lindgren 0 siblings, 0 replies; 13+ messages in thread From: Tony Lindgren @ 2020-08-17 11:48 UTC (permalink / raw) To: Adam Ford Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc * Adam Ford <aford173@gmail.com> [200805 13:17]: > I know this is an old thread. I am trying to revisit some of the > other issues that came about with this, but is there any way we can > get patch 2/2 applied? It might not do anything unless the bandgap > sensor is enabled, but it at least gets us one step closer for those > who choose to enable it. With 1GHz support now available, it would be > nice to have the precautions to protect the processor from running too > fast when its too hot. Sure seems OK to me. Care to resend as I no longer have it in my inbox? Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-10-07 22:05 [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 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-22 16:22 ` Tony Lindgren 2019-10-22 19:01 ` Adam Ford 1 sibling, 1 reply; 13+ messages in thread From: Tony Lindgren @ 2019-10-22 16:22 UTC (permalink / raw) To: Adam Ford Cc: Mark Rutland, devicetree, hns, Russell King, linux-kernel, Rob Herring, Benoît Cousson, linux-omap, adam.ford, linux-arm-kernel 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. Regards, Tony > > Signed-off-by: Adam Ford <aford173@gmail.com> > > diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig > index 8f1c2b6f9e56..7e14a8c8bb29 100644 > --- a/arch/arm/configs/omap2plus_defconfig > +++ b/arch/arm/configs/omap2plus_defconfig > @@ -292,6 +292,7 @@ CONFIG_THERMAL_GOV_FAIR_SHARE=y > CONFIG_THERMAL_GOV_USER_SPACE=y > CONFIG_CPU_THERMAL=y > CONFIG_TI_THERMAL=y > +CONFIG_OMAP3_THERMAL=y > CONFIG_OMAP4_THERMAL=y > CONFIG_OMAP5_THERMAL=y > CONFIG_DRA752_THERMAL=y > -- > 2.17.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-10-22 16:22 ` [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL Tony Lindgren @ 2019-10-22 19:01 ` Adam Ford 2019-10-22 22:19 ` Tony Lindgren 0 siblings, 1 reply; 13+ messages in thread From: Adam Ford @ 2019-10-22 19:01 UTC (permalink / raw) To: Tony Lindgren Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc 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. I'll try to look into it when I have time, but I was hoping a compromise might be a reasonable work-around. adam > > Regards, > > Tony > > > > > Signed-off-by: Adam Ford <aford173@gmail.com> > > > > diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig > > index 8f1c2b6f9e56..7e14a8c8bb29 100644 > > --- a/arch/arm/configs/omap2plus_defconfig > > +++ b/arch/arm/configs/omap2plus_defconfig > > @@ -292,6 +292,7 @@ CONFIG_THERMAL_GOV_FAIR_SHARE=y > > CONFIG_THERMAL_GOV_USER_SPACE=y > > CONFIG_CPU_THERMAL=y > > CONFIG_TI_THERMAL=y > > +CONFIG_OMAP3_THERMAL=y > > CONFIG_OMAP4_THERMAL=y > > CONFIG_OMAP5_THERMAL=y > > CONFIG_DRA752_THERMAL=y > > -- > > 2.17.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-10-22 19:01 ` Adam Ford @ 2019-10-22 22:19 ` Tony Lindgren 2019-10-23 4:41 ` H. Nikolaus Schaller 0 siblings, 1 reply; 13+ messages in thread From: Tony Lindgren @ 2019-10-22 22:19 UTC (permalink / raw) To: Adam Ford Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc * 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-10-22 22:19 ` Tony Lindgren @ 2019-10-23 4:41 ` H. Nikolaus Schaller 2019-10-23 14:36 ` Tony Lindgren 0 siblings, 1 reply; 13+ messages in thread From: H. Nikolaus Schaller @ 2019-10-23 4:41 UTC (permalink / raw) To: Tony Lindgren Cc: Mark Rutland, devicetree, Adam Ford, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc > Am 23.10.2019 um 00:19 schrieb Tony Lindgren <tony@atomide.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. If I am taken right, it is the drivers/thermal/ti-soc-thermal/ti-*.c which is a common driver for omap3, omap4, omap5. They only differ in the thermal data and which registers and bits are used to access the ADC. So is this problem with off mode also known for omap4 and omap5? BR, Nikolaus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-10-23 4:41 ` H. Nikolaus Schaller @ 2019-10-23 14:36 ` Tony Lindgren 2019-11-08 20:02 ` Adam Ford 0 siblings, 1 reply; 13+ messages in thread From: Tony Lindgren @ 2019-10-23 14:36 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Mark Rutland, devicetree, Adam Ford, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc * H. Nikolaus Schaller <hns@goldelico.com> [191023 04:42]: > > > Am 23.10.2019 um 00:19 schrieb Tony Lindgren <tony@atomide.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. > > If I am taken right, it is the drivers/thermal/ti-soc-thermal/ti-*.c > which is a common driver for omap3, omap4, omap5. They only differ > in the thermal data and which registers and bits are used to access > the ADC. Yes so it seems. Enabling OMAP3_THERMAL adds support to of_ti_bandgap_match[] for omap3 and causes the issue. > So is this problem with off mode also known for omap4 and omap5? Probably. But we don't have off mode working for omap4, and it cannot be used for omap5 AFAIK. My guess is we need to call clk_disable() and call ti_bandgap_save_ctxt() on CPU_CLUSTER_PM_ENTER similar to what ti_bandgap_suspend does. And then restore it on CPU_CLUSTER_PM_EXIT. There's a similar example already in gpio_omap_cpu_notifier(). Not sure if there is some related errata to deal with too, probably the old Nokia n900 or n9 would provide some hints on what exactly needs to be done. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-10-23 14:36 ` Tony Lindgren @ 2019-11-08 20:02 ` Adam Ford 2019-11-08 20:51 ` Tony Lindgren 0 siblings, 1 reply; 13+ messages in thread From: Adam Ford @ 2019-11-08 20:02 UTC (permalink / raw) To: Tony Lindgren Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc On Wed, Oct 23, 2019 at 9:36 AM Tony Lindgren <tony@atomide.com> wrote: > > * H. Nikolaus Schaller <hns@goldelico.com> [191023 04:42]: > > > > > Am 23.10.2019 um 00:19 schrieb Tony Lindgren <tony@atomide.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. > > > > If I am taken right, it is the drivers/thermal/ti-soc-thermal/ti-*.c > > which is a common driver for omap3, omap4, omap5. They only differ > > in the thermal data and which registers and bits are used to access > > the ADC. > > Yes so it seems. Enabling OMAP3_THERMAL adds support to > of_ti_bandgap_match[] for omap3 and causes the issue. > > > So is this problem with off mode also known for omap4 and omap5? > > Probably. But we don't have off mode working for omap4, and > it cannot be used for omap5 AFAIK. > > My guess is we need to call clk_disable() and call > ti_bandgap_save_ctxt() on CPU_CLUSTER_PM_ENTER similar to > what ti_bandgap_suspend does. And then restore it on > CPU_CLUSTER_PM_EXIT. > > There's a similar example already in gpio_omap_cpu_notifier(). > Not sure if there is some related errata to deal with too, > probably the old Nokia n900 or n9 would provide some hints > on what exactly needs to be done. I 'think' I have a patch ready that does what you're asking, but I will fully admit that I don't completely grasp what's going on. I'll submit it as an RFC, but I am not even sure I understand what to put into the description, so if you're OK with reviewing the RFC, feel free to mark up the actual commit message as well. From what I can see, the changes haven't negatively impact stuff. I didn't see the power consumption go up before, so I am not sure I can replicate your findings. It'll be posted shortly. adam > > Regards, > > Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-11-08 20:02 ` Adam Ford @ 2019-11-08 20:51 ` Tony Lindgren 2019-11-08 21:04 ` Adam Ford 0 siblings, 1 reply; 13+ messages in thread From: Tony Lindgren @ 2019-11-08 20:51 UTC (permalink / raw) To: Adam Ford Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc * Adam Ford <aford173@gmail.com> [191108 20:03]: > On Wed, Oct 23, 2019 at 9:36 AM Tony Lindgren <tony@atomide.com> wrote: > > My guess is we need to call clk_disable() and call > > ti_bandgap_save_ctxt() on CPU_CLUSTER_PM_ENTER similar to > > what ti_bandgap_suspend does. And then restore it on > > CPU_CLUSTER_PM_EXIT. > > > > There's a similar example already in gpio_omap_cpu_notifier(). > > Not sure if there is some related errata to deal with too, > > probably the old Nokia n900 or n9 would provide some hints > > on what exactly needs to be done. > > I 'think' I have a patch ready that does what you're asking, but I > will fully admit that I don't completely grasp what's going on. > > I'll submit it as an RFC, but I am not even sure I understand what to > put into the description, so if you're OK with reviewing the RFC, feel > free to mark up the actual commit message as well. > > From what I can see, the changes haven't negatively impact stuff. I > didn't see the power consumption go up before, so I am not sure I can > replicate your findings. > > It'll be posted shortly. Yeah seems to do the job, thanks for fixing this issue. Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-11-08 20:51 ` Tony Lindgren @ 2019-11-08 21:04 ` Adam Ford 2019-11-08 21:21 ` Tony Lindgren 0 siblings, 1 reply; 13+ messages in thread From: Adam Ford @ 2019-11-08 21:04 UTC (permalink / raw) To: Tony Lindgren Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc On Fri, Nov 8, 2019 at 2:51 PM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [191108 20:03]: > > On Wed, Oct 23, 2019 at 9:36 AM Tony Lindgren <tony@atomide.com> wrote: > > > My guess is we need to call clk_disable() and call > > > ti_bandgap_save_ctxt() on CPU_CLUSTER_PM_ENTER similar to > > > what ti_bandgap_suspend does. And then restore it on > > > CPU_CLUSTER_PM_EXIT. > > > > > > There's a similar example already in gpio_omap_cpu_notifier(). > > > Not sure if there is some related errata to deal with too, > > > probably the old Nokia n900 or n9 would provide some hints > > > on what exactly needs to be done. > > > > I 'think' I have a patch ready that does what you're asking, but I > > will fully admit that I don't completely grasp what's going on. > > > > I'll submit it as an RFC, but I am not even sure I understand what to > > put into the description, so if you're OK with reviewing the RFC, feel > > free to mark up the actual commit message as well. > > > > From what I can see, the changes haven't negatively impact stuff. I > > didn't see the power consumption go up before, so I am not sure I can > > replicate your findings. > > > > It'll be posted shortly. > > Yeah seems to do the job, thanks for fixing this issue. I am glad I could help! I am learning new stuff. :-) Once the other patch to fix the bandgap clock idling, will it be possible to accept this as-is, or do you need me to re-base and submit again? Ideally, once we get the thermal stuff in and we can drop Nikolaus' turbo option on the 1GHz processor and just let the processor scale to 1GHz without having to deal with the boost stuff since it should throttle back when the junction temp hits its threshold. If you want me to re-base, please let me know which branch I should use. Thank you, adam > > Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 2019-11-08 21:04 ` Adam Ford @ 2019-11-08 21:21 ` Tony Lindgren 0 siblings, 0 replies; 13+ messages in thread From: Tony Lindgren @ 2019-11-08 21:21 UTC (permalink / raw) To: Adam Ford Cc: Mark Rutland, devicetree, H. Nikolaus Schaller, Russell King, Linux Kernel Mailing List, Rob Herring, Benoît Cousson, Linux-OMAP, Adam Ford, arm-soc * Adam Ford <aford173@gmail.com> [191108 21:05]: > On Fri, Nov 8, 2019 at 2:51 PM Tony Lindgren <tony@atomide.com> wrote: > > > > * Adam Ford <aford173@gmail.com> [191108 20:03]: > > > On Wed, Oct 23, 2019 at 9:36 AM Tony Lindgren <tony@atomide.com> wrote: > > > > My guess is we need to call clk_disable() and call > > > > ti_bandgap_save_ctxt() on CPU_CLUSTER_PM_ENTER similar to > > > > what ti_bandgap_suspend does. And then restore it on > > > > CPU_CLUSTER_PM_EXIT. > > > > > > > > There's a similar example already in gpio_omap_cpu_notifier(). > > > > Not sure if there is some related errata to deal with too, > > > > probably the old Nokia n900 or n9 would provide some hints > > > > on what exactly needs to be done. > > > > > > I 'think' I have a patch ready that does what you're asking, but I > > > will fully admit that I don't completely grasp what's going on. > > > > > > I'll submit it as an RFC, but I am not even sure I understand what to > > > put into the description, so if you're OK with reviewing the RFC, feel > > > free to mark up the actual commit message as well. > > > > > > From what I can see, the changes haven't negatively impact stuff. I > > > didn't see the power consumption go up before, so I am not sure I can > > > replicate your findings. > > > > > > It'll be posted shortly. > > > > Yeah seems to do the job, thanks for fixing this issue. > > I am glad I could help! I am learning new stuff. :-) > > Once the other patch to fix the bandgap clock idling, will it be > possible to accept this as-is, or do you need me to re-base and submit > again? No need to resend, I've tagged it again to apply after the driver fix hits the mainline kernel. > Ideally, once we get the thermal stuff in and we can drop Nikolaus' > turbo option on the 1GHz processor and just let the processor scale to > 1GHz without having to deal with the boost stuff since it should > throttle back when the junction temp hits its threshold. Right. AFAIK we also still need some way to represent the arch/arm/mach-omap2/voltage.c as drivers/regulator some kind of regulator controller regulator for cpufreq to use. > If you want me to re-base, please let me know which branch I should use. No need for that. Thanks, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-08-17 11:49 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-07 22:05 [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL 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 2020-08-05 13:17 ` Adam Ford 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 19:01 ` Adam Ford 2019-10-22 22:19 ` Tony Lindgren 2019-10-23 4:41 ` H. Nikolaus Schaller 2019-10-23 14:36 ` Tony Lindgren 2019-11-08 20:02 ` Adam Ford 2019-11-08 20:51 ` Tony Lindgren 2019-11-08 21:04 ` Adam Ford 2019-11-08 21:21 ` Tony Lindgren
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).