ARM: sunxi: Support cpufreq on sun[457]i

The touchscreen controller has a temperature sensor embedded in the SoC, which already has hwmon support in the driver.

Add DT thermal zone support so we can use it with cpufreq for thermal throttling.

This also adds a comment stating that we do not know the actual formula for calculating the temperature.

Signed-off-by Chen-Yu Tsai <[email protected]>

---

changes since v2:

- Use common function for temperature calculation

changes since v1:

- clean up thermal zone sensor when input device register fails
- unconditionally unregister thermal zone sensor on removal. the unregister function checks the pointers passed in.
- add comment explaining the lack of documents for the temperature calculation formula

---
 .../bindings/input/touchscreen/sun4i.txt           |  2 +
 drivers/input/touchscreen/sun4i-ts.c               | 54 ++++++++++++++++++++--
 2 files changed, 52 insertions(+), 4 deletions(-)

Documentation/devicetree/bindings/input/touchscreen/sun4i.txt +2 -0

index aef57791f40b..a8405bab6c00 100644
@@ -5,6 +5,7 @@ Required properties:
  - compatible: "allwinner,sun4i-a10-ts"
  - reg: mmio address range of the chip
  - interrupts: interrupt to which the chip is connected
+ - #thermal-sensor-cells: shall be 0
 
 Optional properties:
  - allwinner,ts-attached: boolean indicating that an actual touchscreen is

@@ -17,4 +18,5 @@ Example:
 		reg = <0x01c25000 0x100>;
 		interrupts = <29>;
 		allwinner,ts-attached;
+		#thermal-sensor-cells = <0>;
 	};

drivers/input/touchscreen/sun4i-ts.c +50 -4

index 28a06749ae42..5851aa0bd78b 100644
@@ -34,6 +34,7 @@
 
 #include <linux/err.h>
 #include <linux/hwmon.h>
+#include <linux/thermal.h>
 #include <linux/init.h>
 #include <linux/input.h>
 #include <linux/interrupt.h>

@@ -107,6 +108,7 @@
 struct sun4i_ts_data {
 	struct device *dev;
 	struct input_dev *input;
+	struct thermal_zone_device *tz;
 	void __iomem *base;
 	unsigned int irq;
 	bool ignore_fifo_data;

@@ -180,16 +182,48 @@ static void sun4i_ts_close(struct input_dev *dev)
 	writel(TEMP_IRQ_EN(1), ts->base + TP_INT_FIFOC);
 }
 
+static int get_temp(const struct sun4i_ts_data *ts, long *temp)
+{
+	/* No temp_data until the first irq */
+	if (ts->temp_data == -1)
+		return -EAGAIN;
+
+	/*
+	 * The user manuals do not contain the formula for calculating
+	 * the temperature. The formula used here is from the AXP209,
+	 * which is designed by X-Powers, an affiliate of Allwinner:
+	 *
+	 *     temperature = -144.7 + (value * 0.1)
+	 *
+	 * This should be replaced with the correct one if such information
+	 * becomes available.
+	 */
+	*temp = (ts->temp_data - 1447) * 100;
+
+	return 0;
+}
+
+static int get_tz_temp(void *data, long *temp)
+{
+	return get_temp(data, temp);
+}
+
+static struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
+	.get_temp = get_tz_temp,
+};
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *devattr,
 			 char *buf)
 {
 	struct sun4i_ts_data *ts = dev_get_drvdata(dev);
+	long temp;
+	int ret;
 
-	/* No temp_data until the first irq */
-	if (ts->temp_data == -1)
-		return -EAGAIN;
+	ret = get_temp(ts, &temp);
+	if (ret)
+		return ret;
 
-	return sprintf(buf, "%d\n", (ts->temp_data - 1447) * 100);
+	return sprintf(buf, "%ld\n", temp);
 }
 
 static ssize_t show_temp_label(struct device *dev,

@@ -283,17 +317,27 @@ static int sun4i_ts_probe(struct platform_device *pdev)
 	writel(STYLUS_UP_DEBOUN(5) | STYLUS_UP_DEBOUN_EN(1) | TP_MODE_EN(1),
 	       ts->base + TP_CTRL1);
 
+	/*
+	 * The thermal core does not register hwmon devices for DT-based
+	 * thermal zone sensors, such as this one.
+	 */
 	hwmon = devm_hwmon_device_register_with_groups(ts->dev, "sun4i_ts",
 						       ts, sun4i_ts_groups);
 	if (IS_ERR(hwmon))
 		return PTR_ERR(hwmon);
 
+	ts->tz = thermal_zone_of_sensor_register(ts->dev, 0, ts,
+						 &sun4i_ts_tz_ops);
+	if (IS_ERR(ts->tz))
+		ts->tz = NULL;
+
 	writel(TEMP_IRQ_EN(1), ts->base + TP_INT_FIFOC);
 
 	if (ts_attached) {
 		error = input_register_device(ts->input);
 		if (error) {
 			writel(0, ts->base + TP_INT_FIFOC);
+			thermal_zone_of_sensor_unregister(ts->dev, ts->tz);
 			return error;
 		}
 	}

@@ -310,6 +354,8 @@ static int sun4i_ts_remove(struct platform_device *pdev)
 	if (ts->input)
 		input_unregister_device(ts->input);
 
+	thermal_zone_of_sensor_unregister(ts->dev, ts->tz);
+
 	/* Deactivate all IRQs */
 	writel(0, ts->base + TP_INT_FIFOC);
 

Signature · 1 line

2.1.4

This patch adds the regulator nodes for the axp209 by including the axp209 dtsi. As the inputs of these regulators are from the axp209's PS output, which is basically just a mux over the 2 inputs, it is considered to be unregulated. Thus we do not provide input supply properties for them.

The regulator names and constraints are based on the board schematics and the SoC datasheet.

DCDC2 is used as the cpu power supply. This patch also references it from the cpu node.

Also get rid of axp209 properties already set in axp209.dtsi.

Signed-off-by Chen-Yu Tsai <[email protected]>

---

changes since v2

none

changes since v1:

- Use preprocessor include for axp209.dtsi
- Remove incorrectly squashed axp209.dtsi patch

---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 35 +++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +21 -4

index 18fc5db9c976..ec1fc2c8b3e3 100644
@@ -88,13 +88,9 @@
 			status = "okay";
 
 			axp209: pmic at 34 {
-				compatible = "x-powers,axp209";
 				reg = <0x34>;
 				interrupt-parent = <&nmi_intc>;
 				interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-				interrupt-controller;
-				#interrupt-cells = <1>;
 			};
 		};
 

@@ -145,3 +141,34 @@
 		status = "okay";
 	};
 };
+
+#include "axp209.dtsi"
+
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1450000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-int-dll";
+};
+

Hi Chen-Yu,

Quoted 78 lines · Chen-Yu Tsai

This patch adds the regulator nodes for the axp209 by including the axp209 dtsi. As the inputs of these regulators are from the axp209's PS output, which is basically just a mux over the 2 inputs, it is considered to be unregulated. Thus we do not provide input supply properties for them.

The regulator names and constraints are based on the board schematics and the SoC datasheet.

DCDC2 is used as the cpu power supply. This patch also references it from the cpu node.

Also get rid of axp209 properties already set in axp209.dtsi.

Signed-off-by Chen-Yu Tsai <[email protected]>

---

changes since v2

none

changes since v1:

- Use preprocessor include for axp209.dtsi
- Remove incorrectly squashed axp209.dtsi patch

---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 35 +++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +26 -4

index 18fc5db9c976..ec1fc2c8b3e3 100644
@@ -88,13 +88,9 @@
                      status = "okay";
 
                      axp209: pmic at 34 {
-                             compatible = "x-powers,axp209";
                              reg = <0x34>;
                              interrupt-parent = <&nmi_intc>;
                              interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-                             interrupt-controller;
-                             #interrupt-cells = <1>;
                      };
              };
 

@@ -145,3 +141,34 @@
              status = "okay";
      };
 };
+
+#include "axp209.dtsi"
+
+&cpu0 {
+     cpu-supply = <&reg_dcdc2>;
+};
+
+&reg_dcdc2 {
+     regulator-always-on;
+     regulator-min-microvolt = <1000000>;
+     regulator-max-microvolt = <1450000>;
+     regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+     regulator-always-on;
+     regulator-min-microvolt = <1000000>;
+     regulator-max-microvolt = <1400000>;
+     regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+     regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts line 174

Quoted 5 lines

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +5 -0

+     regulator-always-on;
+     regulator-min-microvolt = <3000000>;
+     regulator-max-microvolt = <3000000>;
+     regulator-name = "avcc";
+};

How do reg_vcc3v3 and the other reg used in this DT (ahci, USB) fit into that?

Eventually, I think we would be able to remove sunxi-common-regulators.dtsi, or at least, expose the proper regulator hierarchy.

Hi,

Quoted 81 lines · Maxime Ripard

Hi Chen-Yu,

Quoted 78 lines · Chen-Yu Tsai

This patch adds the regulator nodes for the axp209 by including the axp209 dtsi. As the inputs of these regulators are from the axp209's PS output, which is basically just a mux over the 2 inputs, it is considered to be unregulated. Thus we do not provide input supply properties for them.

The regulator names and constraints are based on the board schematics and the SoC datasheet.

DCDC2 is used as the cpu power supply. This patch also references it from the cpu node.

Also get rid of axp209 properties already set in axp209.dtsi.

Signed-off-by Chen-Yu Tsai <[email protected]>

---

changes since v2

none

changes since v1:

- Use preprocessor include for axp209.dtsi
- Remove incorrectly squashed axp209.dtsi patch

---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 35 +++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +26 -4

index 18fc5db9c976..ec1fc2c8b3e3 100644
@@ -88,13 +88,9 @@
                      status = "okay";
 
                      axp209: pmic at 34 {
-                             compatible = "x-powers,axp209";
                              reg = <0x34>;
                              interrupt-parent = <&nmi_intc>;
                              interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-                             interrupt-controller;
-                             #interrupt-cells = <1>;
                      };
              };
 

@@ -145,3 +141,34 @@
              status = "okay";
      };
 };
+
+#include "axp209.dtsi"
+
+&cpu0 {
+     cpu-supply = <&reg_dcdc2>;
+};
+
+&reg_dcdc2 {
+     regulator-always-on;
+     regulator-min-microvolt = <1000000>;
+     regulator-max-microvolt = <1450000>;
+     regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+     regulator-always-on;
+     regulator-min-microvolt = <1000000>;
+     regulator-max-microvolt = <1400000>;
+     regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+     regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {

Quoted 8 lines

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts line 174

Quoted 5 lines

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +5 -0

+     regulator-always-on;
+     regulator-min-microvolt = <3000000>;
+     regulator-max-microvolt = <3000000>;
+     regulator-name = "avcc";
+};

How do reg_vcc3v3 and the other reg used in this DT (ahci, USB) fit into that?

The following applies to boards that use AXP209.

reg_vcc3v3 or reg_vcc3v0 is an external buck regulator with it's enable pin tied to EXTEN on the AXP. This pin is controllable, but we do not have the driver for it. It is possible that multiple regulators are tied to this pin. I suggest not touching it without the correct schematics.

The source for usb and ahci regulators, or reg_vcc5v if you will, is either the unregulated 5v from the power supply or the usb otg port. For the Cubietruck, there's an additional uncontrollable boost regulator that boosts the lipo battery's power up to 5v.

On some of the Olimex boards that use higher input voltages, they use an uncontrollable buck regulator to step down the voltage to 5v. The Olinuxino-Micro also has a boost regulator for the battery, tied to EXTEN.

The AXP209 simply does not have enough outputs for all the needed voltages.

You could probably chain the regulators in the DT via xxx-supply if it helps. But beyond that, it is hard to do anything meaningful at this point. Modeling them as fixed regulators beyond our control is simpler. We also do not have an IPSOUT regulator for the AXP.

Quoted 3 lines

Eventually, I think we would be able to remove sunxi-common-regulators.dtsi, or at least, expose the proper regulator hierarchy.

The USB and SATA regulators are just GPIO enabled switches (MOSFETs) or current limiters. I think these will always exist because of the reference designs. Or do you want to move them back into the board dts files? FWIW, I like it the way it is now. Not that I don't like it to be accurate.

Hi,

Quoted 112 lines · Chen-Yu Tsai

Hi,

Quoted 81 lines · Maxime Ripard

Hi Chen-Yu,

Quoted 78 lines · Chen-Yu Tsai

This patch adds the regulator nodes for the axp209 by including the axp209 dtsi. As the inputs of these regulators are from the axp209's PS output, which is basically just a mux over the 2 inputs, it is considered to be unregulated. Thus we do not provide input supply properties for them.

The regulator names and constraints are based on the board schematics and the SoC datasheet.

DCDC2 is used as the cpu power supply. This patch also references it from the cpu node.

Also get rid of axp209 properties already set in axp209.dtsi.

Signed-off-by Chen-Yu Tsai <[email protected]>

---

changes since v2

none

changes since v1:

- Use preprocessor include for axp209.dtsi
- Remove incorrectly squashed axp209.dtsi patch

---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 35 +++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +26 -4

index 18fc5db9c976..ec1fc2c8b3e3 100644
@@ -88,13 +88,9 @@
                      status = "okay";
 
                      axp209: pmic at 34 {
-                             compatible = "x-powers,axp209";
                              reg = <0x34>;
                              interrupt-parent = <&nmi_intc>;
                              interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-                             interrupt-controller;
-                             #interrupt-cells = <1>;
                      };
              };
 

@@ -145,3 +141,34 @@
              status = "okay";
      };
 };
+
+#include "axp209.dtsi"
+
+&cpu0 {
+     cpu-supply = <&reg_dcdc2>;
+};
+
+&reg_dcdc2 {
+     regulator-always-on;
+     regulator-min-microvolt = <1000000>;
+     regulator-max-microvolt = <1450000>;
+     regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+     regulator-always-on;
+     regulator-min-microvolt = <1000000>;
+     regulator-max-microvolt = <1400000>;
+     regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+     regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {

Quoted 8 lines

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts line 174

Quoted 5 lines

arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +5 -0

+     regulator-always-on;
+     regulator-min-microvolt = <3000000>;
+     regulator-max-microvolt = <3000000>;
+     regulator-name = "avcc";
+};

How do reg_vcc3v3 and the other reg used in this DT (ahci, USB) fit into that?

The following applies to boards that use AXP209.

reg_vcc3v3 or reg_vcc3v0 is an external buck regulator with it's enable pin tied to EXTEN on the AXP. This pin is controllable, but we do not have the driver for it. It is possible that multiple regulators are tied to this pin. I suggest not touching it without the correct schematics.

The source for usb and ahci regulators, or reg_vcc5v if you will, is either the unregulated 5v from the power supply or the usb otg port. For the Cubietruck, there's an additional uncontrollable boost regulator that boosts the lipo battery's power up to 5v.

On some of the Olimex boards that use higher input voltages, they use an uncontrollable buck regulator to step down the voltage to 5v. The Olinuxino-Micro also has a boost regulator for the battery, tied to EXTEN.

Quoted 2 lines

The AXP209 simply does not have enough outputs for all the needed voltages.

Hmm, yes, ok. It makes sense.

Quoted 9 lines

You could probably chain the regulators in the DT via xxx-supply if it helps. But beyond that, it is hard to do anything meaningful at this point. Modeling them as fixed regulators beyond our control is simpler. We also do not have an IPSOUT regulator for the AXP.

Quoted 3 lines

Eventually, I think we would be able to remove sunxi-common-regulators.dtsi, or at least, expose the proper regulator hierarchy.

Quoted 5 lines

The USB and SATA regulators are just GPIO enabled switches (MOSFETs) or current limiters. I think these will always exist because of the reference designs. Or do you want to move them back into the board dts files? FWIW, I like it the way it is now. Not that I don't like it to be accurate.

At least providing the right hierarchy at the board level would be great. Adding the -supply property to all our fixed regulators wouldn't take too much code, and would be enough to model properly the regulator trees.

Quoted 15 lines

Quoted 9 lines

You could probably chain the regulators in the DT via xxx-supply if it helps. But beyond that, it is hard to do anything meaningful at this point. Modeling them as fixed regulators beyond our control is simpler. We also do not have an IPSOUT regulator for the AXP.

Quoted 3 lines

Eventually, I think we would be able to remove sunxi-common-regulators.dtsi, or at least, expose the proper regulator hierarchy.

Quoted 5 lines

The USB and SATA regulators are just GPIO enabled switches (MOSFETs) or current limiters. I think these will always exist because of the reference designs. Or do you want to move them back into the board dts files? FWIW, I like it the way it is now. Not that I don't like it to be accurate.

Quoted 4 lines

At least providing the right hierarchy at the board level would be great. Adding the -supply property to all our fixed regulators wouldn't take too much code, and would be enough to model properly the regulator trees.

These are all unrelated to axp209. You'd end up with

    vin-supply = <&reg_vcc5v>;

for the usb and sata power regulators. You could put these in sunxi-common-regulators, and override them for boards that actually have something controllable.

Hi,

This is v3 of the cpufreq support series for sunxi. The series has been rebased onto the latest sunxi-next. I've dropped all the patches Maxime merged. This includes "ARM: sunxi: Register cpufreq-dt for sun[45678]i" which was merged but not published yet.

Individual changes since v2 are listed within each patch.

Original cover letter follows:

This series adds support cpufreq support for sun[457]i using cpufreq-dt. This also supports passive cpu cooling (thermal throttling) using thermal zones with the temperature sensor in the SoC.

The operating points for the supported platforms were taken from the linux-sunxi FEX files repository. The majority of boards use the same settings. Only with sun7i do we see slight variations, either disabling some frequencies, or bumping up the voltage a bit. In either case this can be done by limiting the constraints for the supply regulator, or overriding the OPP table in the board dts file.

On sun7i, there is an additional operating point not found in the FEX files, 960 MHz @ 1.4V, which is the full speed setting in both u-boot-sunxi and mainline u-boot.

The series has been tested on the 4 boards I have. With cpufreq active, the effects are visible as a decrease in SoC internal temperature. Stability for the operating points has been tested using:

http://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings

More real world usage feedback is appreciated. Thermal throttling hasn't been tested much, due to not being able to generate enough load without the GPU for the SoC to heat up. Also on sun4i, the temperature sensor still hasn't been calibrated, so the readings are highly inaccurate.

Quoted 31 lines · Chen-Yu Tsai

Hi,

This is v3 of the cpufreq support series for sunxi. The series has been rebased onto the latest sunxi-next. I've dropped all the patches Maxime merged. This includes "ARM: sunxi: Register cpufreq-dt for sun[45678]i" which was merged but not published yet.

Individual changes since v2 are listed within each patch.

Original cover letter follows:

This series adds support cpufreq support for sun[457]i using cpufreq-dt. This also supports passive cpu cooling (thermal throttling) using thermal zones with the temperature sensor in the SoC.

The operating points for the supported platforms were taken from the linux-sunxi FEX files repository. The majority of boards use the same settings. Only with sun7i do we see slight variations, either disabling some frequencies, or bumping up the voltage a bit. In either case this can be done by limiting the constraints for the supply regulator, or overriding the OPP table in the board dts file.

On sun7i, there is an additional operating point not found in the FEX files, 960 MHz @ 1.4V, which is the full speed setting in both u-boot-sunxi and mainline u-boot.

The series has been tested on the 4 boards I have. With cpufreq active, the effects are visible as a decrease in SoC internal temperature. Stability for the operating points has been tested using:

Quoted 6 lines

http://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings

More real world usage feedback is appreciated. Thermal throttling hasn't been tested much, due to not being able to generate enough load without the GPU for the SoC to heat up. Also on sun4i, the temperature sensor still hasn't been calibrated, so the readings are highly inaccurate.

Applied 2, 3, 6 and 8.