[PATCH v12] Add Mediatek thermal support

[PATCH v12] Add Mediatek thermal support

[Sascha Hauer]

This series adds support for the thermal sensors included in the
MT8173 SoC. Currently only basic temperature reading is supported
without any interrupt support.

The cpufreq driver for MT8173 is currently under review, so there's no
real cooling device available in mainline. Until this is available the
thermal driver can be tested with the following dts snippet. It creates
a fake gpio fan and a fake trip point which is so low that it can easily
be reached with a "cat /dev/zero > /dev/null" on the command line.

Sascha

Changes since v11:
- Fix usage of uninitialized variable gcc didn't warn about

changes since v10:
- Some style cleanup
- Add comment to make clear why we use the sensors in banks even if we
  currently only use the maximum of all banks

changes since v9:
- rebase on v4.3
- Add support for reading the calibration values from nvmem fuses
- Only register a single thermal zone instead of four as it seems
  that's everything needed

changes since v8:
- Add commit description to binding patch
- rebase on v4.3-rc2

changes since v7:
- re-add some used defines removed in v5
- Use MT8173_THERMAL_ZONE_* defines as array indices in static initializers

changes since v6:
- remove dot in Hanyi Wus name

changes since v5:
- update copyright
- remove unused defines

Changes since v4:
- give calibration constants more meaningful names (offset, slope)
- Use define instead of 0x00c for register access.

Changes since v3:
- add include/dt-bindings/thermal/mt8173.h for to be able to use sensor names
  in dts files
- fix disabling wrong clock in error path
- remove now unused reset-names property from binding document
- rename MT8173_NUM_BANKS -> MT8173_NUM_ZONES
- rename MT8173_NUM_SENSING_POINTS -> MT8173_NUM_SENSORS_PER_ZONE
- rename struct thermal_zone_device *tz -> struct thermal_zone_device *tzd

Changes since v2:
- sort #includes alphabetically
- Add prefix to register defines
- drop some members from struct mtk_thermal
- simplify raw_to_mcelsius()
- add and use more register bit defines
- use device_reset() instead of devm_reset_control_get()/reset_control_reset()
- misc other stuff

Changes since v1:
- Use "mediatek," prefix for custom properties
- Drop "thermal: consistently use int for temperatures" dependency

-------------

	fan: gpio_fan {
		compatible = "gpio-fan";
		gpios = <&pio 24 0>;
		gpio-fan,speed-map = <0    0
				      4500 1>;
		#cooling-cells = <2>;
	};

	thermal-zones {
			cpu_thermal: cpu_thermal {
			polling-delay-passive = <1000>; /* milliseconds */
			polling-delay = <1000>; /* milliseconds */

			thermal-sensors = <&thermal>;

			trips {
				cpu_passive: cpu_passive {
					temperature = <47000>; /* millicelsius */
					hysteresis = <2000>; /* millicelsius */
					type = "passive";
				};

				cpu_crit {
					temperature = <90000>; /* millicelsius */
					hysteresis = <2000>; /* millicelsius */
					type = "critical";
				};
			};

			cooling-maps {
				map0 {
					trip = <&cpu_passive>;
					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
				};
			};
		};
	};

[PATCH v12] Add Mediatek thermal support

[Sascha Hauer]

This series adds support for the thermal sensors included in the
MT8173 SoC. Currently only basic temperature reading is supported
without any interrupt support.

The cpufreq driver for MT8173 is currently under review, so there's no
real cooling device available in mainline. Until this is available the
thermal driver can be tested with the following dts snippet. It creates
a fake gpio fan and a fake trip point which is so low that it can easily
be reached with a "cat /dev/zero > /dev/null" on the command line.

Sascha

Changes since v11:
- Fix usage of uninitialized variable gcc didn't warn about

changes since v10:
- Some style cleanup
- Add comment to make clear why we use the sensors in banks even if we
  currently only use the maximum of all banks

changes since v9:
- rebase on v4.3
- Add support for reading the calibration values from nvmem fuses
- Only register a single thermal zone instead of four as it seems
  that's everything needed

changes since v8:
- Add commit description to binding patch
- rebase on v4.3-rc2

changes since v7:
- re-add some used defines removed in v5
- Use MT8173_THERMAL_ZONE_* defines as array indices in static initializers

changes since v6:
- remove dot in Hanyi Wus name

changes since v5:
- update copyright
- remove unused defines

Changes since v4:
- give calibration constants more meaningful names (offset, slope)
- Use define instead of 0x00c for register access.

Changes since v3:
- add include/dt-bindings/thermal/mt8173.h for to be able to use sensor names
  in dts files
- fix disabling wrong clock in error path
- remove now unused reset-names property from binding document
- rename MT8173_NUM_BANKS -> MT8173_NUM_ZONES
- rename MT8173_NUM_SENSING_POINTS -> MT8173_NUM_SENSORS_PER_ZONE
- rename struct thermal_zone_device *tz -> struct thermal_zone_device *tzd

Changes since v2:
- sort #includes alphabetically
- Add prefix to register defines
- drop some members from struct mtk_thermal
- simplify raw_to_mcelsius()
- add and use more register bit defines
- use device_reset() instead of devm_reset_control_get()/reset_control_reset()
- misc other stuff

Changes since v1:
- Use "mediatek," prefix for custom properties
- Drop "thermal: consistently use int for temperatures" dependency

-------------

	fan: gpio_fan {
		compatible = "gpio-fan";
		gpios = <&pio 24 0>;
		gpio-fan,speed-map = <0    0
				      4500 1>;
		#cooling-cells = <2>;
	};

	thermal-zones {
			cpu_thermal: cpu_thermal {
			polling-delay-passive = <1000>; /* milliseconds */
			polling-delay = <1000>; /* milliseconds */

			thermal-sensors = <&thermal>;

			trips {
				cpu_passive: cpu_passive {
					temperature = <47000>; /* millicelsius */
					hysteresis = <2000>; /* millicelsius */
					type = "passive";
				};

				cpu_crit {
					temperature = <90000>; /* millicelsius */
					hysteresis = <2000>; /* millicelsius */
					type = "critical";
				};
			};

			cooling-maps {
				map0 {
					trip = <&cpu_passive>;
					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
				};
			};
		};
	};

[PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Sascha Hauer]

This adds the device tree binding documentation for the mediatek thermal
controller found on Mediatek MT8173 and other SoCs.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
new file mode 100644
index 0000000..81f9a51
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
@@ -0,0 +1,43 @@
+* Mediatek Thermal
+
+This describes the device tree binding for the Mediatek thermal controller
+which measures the on-SoC temperatures. This device does not have its own ADC,
+instead it directly controls the AUXADC via AHB bus accesses. For this reason
+this device needs phandles to the AUXADC. Also it controls a mux in the
+apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
+is also needed.
+
+Required properties:
+- compatible: "mediatek,mt8173-thermal"
+- reg: Address range of the thermal controller
+- interrupts: IRQ for the thermal controller
+- clocks, clock-names: Clocks needed for the thermal controller. required
+                       clocks are:
+		       "therm":	 Main clock needed for register access
+		       "auxadc": The AUXADC clock
+- resets: Reference to the reset controller controlling the thermal controller.
+- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
+- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
+- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
+
+Optional properties:
+- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
+               unspecified default values shall be used.
+- nvmem-cell-names: Should be "calibration-data"
+
+Example:
+
+	thermal: thermal@1100b000 {
+		#thermal-sensor-cells = <1>;
+		compatible = "mediatek,mt8173-thermal";
+		reg = <0 0x1100b000 0 0x1000>;
+		interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+		clock-names = "therm", "auxadc";
+		resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
+		reset-names = "therm";
+		mediatek,auxadc = <&auxadc>;
+		mediatek,apmixedsys = <&apmixedsys>;
+		nvmem-cells = <&thermal_calibration_data>;
+		nvmem-cell-names = "calibration-data";
+	};
-- 
2.6.2

[PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Sascha Hauer]

This adds the device tree binding documentation for the mediatek thermal
controller found on Mediatek MT8173 and other SoCs.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
new file mode 100644
index 0000000..81f9a51
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
@@ -0,0 +1,43 @@
+* Mediatek Thermal
+
+This describes the device tree binding for the Mediatek thermal controller
+which measures the on-SoC temperatures. This device does not have its own ADC,
+instead it directly controls the AUXADC via AHB bus accesses. For this reason
+this device needs phandles to the AUXADC. Also it controls a mux in the
+apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
+is also needed.
+
+Required properties:
+- compatible: "mediatek,mt8173-thermal"
+- reg: Address range of the thermal controller
+- interrupts: IRQ for the thermal controller
+- clocks, clock-names: Clocks needed for the thermal controller. required
+                       clocks are:
+		       "therm":	 Main clock needed for register access
+		       "auxadc": The AUXADC clock
+- resets: Reference to the reset controller controlling the thermal controller.
+- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
+- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
+- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
+
+Optional properties:
+- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
+               unspecified default values shall be used.
+- nvmem-cell-names: Should be "calibration-data"
+
+Example:
+
+	thermal: thermal at 1100b000 {
+		#thermal-sensor-cells = <1>;
+		compatible = "mediatek,mt8173-thermal";
+		reg = <0 0x1100b000 0 0x1000>;
+		interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+		clock-names = "therm", "auxadc";
+		resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
+		reset-names = "therm";
+		mediatek,auxadc = <&auxadc>;
+		mediatek,apmixedsys = <&apmixedsys>;
+		nvmem-cells = <&thermal_calibration_data>;
+		nvmem-cell-names = "calibration-data";
+	};
-- 
2.6.2

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Daniel Kurtz]

On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This adds the device tree binding documentation for the mediatek thermal
> controller found on Mediatek MT8173 and other SoCs.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> new file mode 100644
> index 0000000..81f9a51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> @@ -0,0 +1,43 @@
> +* Mediatek Thermal
> +
> +This describes the device tree binding for the Mediatek thermal controller
> +which measures the on-SoC temperatures. This device does not have its own ADC,
> +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> +this device needs phandles to the AUXADC. Also it controls a mux in the
> +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> +is also needed.
> +
> +Required properties:
> +- compatible: "mediatek,mt8173-thermal"
> +- reg: Address range of the thermal controller
> +- interrupts: IRQ for the thermal controller
> +- clocks, clock-names: Clocks needed for the thermal controller. required
> +                       clocks are:
> +                      "therm":  Main clock needed for register access
> +                      "auxadc": The AUXADC clock
> +- resets: Reference to the reset controller controlling the thermal controller.
> +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> +
> +Optional properties:
> +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> +               unspecified default values shall be used.
> +- nvmem-cell-names: Should be "calibration-data"
> +
> +Example:
> +
> +       thermal: thermal@1100b000 {
> +               #thermal-sensor-cells = <1>;

Tiny nit: this should now be:

#thermal-sensor-cells = <0>;

> +               compatible = "mediatek,mt8173-thermal";
> +               reg = <0 0x1100b000 0 0x1000>;
> +               interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +               clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +               clock-names = "therm", "auxadc";
> +               resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +               reset-names = "therm";
> +               mediatek,auxadc = <&auxadc>;
> +               mediatek,apmixedsys = <&apmixedsys>;
> +               nvmem-cells = <&thermal_calibration_data>;
> +               nvmem-cell-names = "calibration-data";
> +       };
> --
> 2.6.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Daniel Kurtz]

On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This adds the device tree binding documentation for the mediatek thermal
> controller found on Mediatek MT8173 and other SoCs.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> new file mode 100644
> index 0000000..81f9a51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> @@ -0,0 +1,43 @@
> +* Mediatek Thermal
> +
> +This describes the device tree binding for the Mediatek thermal controller
> +which measures the on-SoC temperatures. This device does not have its own ADC,
> +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> +this device needs phandles to the AUXADC. Also it controls a mux in the
> +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> +is also needed.
> +
> +Required properties:
> +- compatible: "mediatek,mt8173-thermal"
> +- reg: Address range of the thermal controller
> +- interrupts: IRQ for the thermal controller
> +- clocks, clock-names: Clocks needed for the thermal controller. required
> +                       clocks are:
> +                      "therm":  Main clock needed for register access
> +                      "auxadc": The AUXADC clock
> +- resets: Reference to the reset controller controlling the thermal controller.
> +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> +
> +Optional properties:
> +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> +               unspecified default values shall be used.
> +- nvmem-cell-names: Should be "calibration-data"
> +
> +Example:
> +
> +       thermal: thermal at 1100b000 {
> +               #thermal-sensor-cells = <1>;

Tiny nit: this should now be:

#thermal-sensor-cells = <0>;

> +               compatible = "mediatek,mt8173-thermal";
> +               reg = <0 0x1100b000 0 0x1000>;
> +               interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +               clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +               clock-names = "therm", "auxadc";
> +               resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +               reset-names = "therm";
> +               mediatek,auxadc = <&auxadc>;
> +               mediatek,apmixedsys = <&apmixedsys>;
> +               nvmem-cells = <&thermal_calibration_data>;
> +               nvmem-cell-names = "calibration-data";
> +       };
> --
> 2.6.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Daniel Kurtz]

On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This adds the device tree binding documentation for the mediatek thermal
> controller found on Mediatek MT8173 and other SoCs.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> new file mode 100644
> index 0000000..81f9a51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> @@ -0,0 +1,43 @@
> +* Mediatek Thermal
> +
> +This describes the device tree binding for the Mediatek thermal controller
> +which measures the on-SoC temperatures. This device does not have its own ADC,
> +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> +this device needs phandles to the AUXADC. Also it controls a mux in the
> +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> +is also needed.
> +
> +Required properties:
> +- compatible: "mediatek,mt8173-thermal"
> +- reg: Address range of the thermal controller
> +- interrupts: IRQ for the thermal controller
> +- clocks, clock-names: Clocks needed for the thermal controller. required
> +                       clocks are:
> +                      "therm":  Main clock needed for register access
> +                      "auxadc": The AUXADC clock
> +- resets: Reference to the reset controller controlling the thermal controller.
> +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> +
> +Optional properties:
> +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> +               unspecified default values shall be used.
> +- nvmem-cell-names: Should be "calibration-data"
> +
> +Example:
> +
> +       thermal: thermal@1100b000 {
> +               #thermal-sensor-cells = <1>;

Tiny nit: this should now be:

#thermal-sensor-cells = <0>;

> +               compatible = "mediatek,mt8173-thermal";
> +               reg = <0 0x1100b000 0 0x1000>;
> +               interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +               clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +               clock-names = "therm", "auxadc";
> +               resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +               reset-names = "therm";
> +               mediatek,auxadc = <&auxadc>;
> +               mediatek,apmixedsys = <&apmixedsys>;
> +               nvmem-cells = <&thermal_calibration_data>;
> +               nvmem-cell-names = "calibration-data";
> +       };
> --
> 2.6.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Eduardo Valentin]

On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > This adds the device tree binding documentation for the mediatek thermal
> > controller found on Mediatek MT8173 and other SoCs.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> >  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > new file mode 100644
> > index 0000000..81f9a51
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > @@ -0,0 +1,43 @@
> > +* Mediatek Thermal
> > +
> > +This describes the device tree binding for the Mediatek thermal controller
> > +which measures the on-SoC temperatures. This device does not have its own ADC,
> > +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> > +is also needed.
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt8173-thermal"
> > +- reg: Address range of the thermal controller
> > +- interrupts: IRQ for the thermal controller
> > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > +                       clocks are:
> > +                      "therm":  Main clock needed for register access
> > +                      "auxadc": The AUXADC clock
> > +- resets: Reference to the reset controller controlling the thermal controller.
> > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> > +
> > +Optional properties:
> > +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> > +               unspecified default values shall be used.
> > +- nvmem-cell-names: Should be "calibration-data"
> > +
> > +Example:
> > +
> > +       thermal: thermal@1100b000 {
> > +               #thermal-sensor-cells = <1>;
> 
> Tiny nit: this should now be:
> 
> #thermal-sensor-cells = <0>;


This is actually not so tiny'shy. Why does this driver masks out all
sensors available? Why don't we expose all of them and use id property
to expose and identify each of them?

[PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Eduardo Valentin]

On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > This adds the device tree binding documentation for the mediatek thermal
> > controller found on Mediatek MT8173 and other SoCs.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> >  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > new file mode 100644
> > index 0000000..81f9a51
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > @@ -0,0 +1,43 @@
> > +* Mediatek Thermal
> > +
> > +This describes the device tree binding for the Mediatek thermal controller
> > +which measures the on-SoC temperatures. This device does not have its own ADC,
> > +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> > +is also needed.
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt8173-thermal"
> > +- reg: Address range of the thermal controller
> > +- interrupts: IRQ for the thermal controller
> > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > +                       clocks are:
> > +                      "therm":  Main clock needed for register access
> > +                      "auxadc": The AUXADC clock
> > +- resets: Reference to the reset controller controlling the thermal controller.
> > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> > +
> > +Optional properties:
> > +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> > +               unspecified default values shall be used.
> > +- nvmem-cell-names: Should be "calibration-data"
> > +
> > +Example:
> > +
> > +       thermal: thermal at 1100b000 {
> > +               #thermal-sensor-cells = <1>;
> 
> Tiny nit: this should now be:
> 
> #thermal-sensor-cells = <0>;


This is actually not so tiny'shy. Why does this driver masks out all
sensors available? Why don't we expose all of them and use id property
to expose and identify each of them?

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Eduardo Valentin]

On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > This adds the device tree binding documentation for the mediatek thermal
> > controller found on Mediatek MT8173 and other SoCs.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> >  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > new file mode 100644
> > index 0000000..81f9a51
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > @@ -0,0 +1,43 @@
> > +* Mediatek Thermal
> > +
> > +This describes the device tree binding for the Mediatek thermal controller
> > +which measures the on-SoC temperatures. This device does not have its own ADC,
> > +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> > +is also needed.
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt8173-thermal"
> > +- reg: Address range of the thermal controller
> > +- interrupts: IRQ for the thermal controller
> > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > +                       clocks are:
> > +                      "therm":  Main clock needed for register access
> > +                      "auxadc": The AUXADC clock
> > +- resets: Reference to the reset controller controlling the thermal controller.
> > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> > +
> > +Optional properties:
> > +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> > +               unspecified default values shall be used.
> > +- nvmem-cell-names: Should be "calibration-data"
> > +
> > +Example:
> > +
> > +       thermal: thermal@1100b000 {
> > +               #thermal-sensor-cells = <1>;
> 
> Tiny nit: this should now be:
> 
> #thermal-sensor-cells = <0>;


This is actually not so tiny'shy. Why does this driver masks out all
sensors available? Why don't we expose all of them and use id property
to expose and identify each of them?

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Sascha Hauer]

On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > This adds the device tree binding documentation for the mediatek thermal
> > > controller found on Mediatek MT8173 and other SoCs.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > >  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > new file mode 100644
> > > index 0000000..81f9a51
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > @@ -0,0 +1,43 @@
> > > +* Mediatek Thermal
> > > +
> > > +This describes the device tree binding for the Mediatek thermal controller
> > > +which measures the on-SoC temperatures. This device does not have its own ADC,
> > > +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> > > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > > +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> > > +is also needed.
> > > +
> > > +Required properties:
> > > +- compatible: "mediatek,mt8173-thermal"
> > > +- reg: Address range of the thermal controller
> > > +- interrupts: IRQ for the thermal controller
> > > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > > +                       clocks are:
> > > +                      "therm":  Main clock needed for register access
> > > +                      "auxadc": The AUXADC clock
> > > +- resets: Reference to the reset controller controlling the thermal controller.
> > > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> > > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> > > +
> > > +Optional properties:
> > > +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> > > +               unspecified default values shall be used.
> > > +- nvmem-cell-names: Should be "calibration-data"
> > > +
> > > +Example:
> > > +
> > > +       thermal: thermal@1100b000 {
> > > +               #thermal-sensor-cells = <1>;
> > 
> > Tiny nit: this should now be:
> > 
> > #thermal-sensor-cells = <0>;
> 
> 
> This is actually not so tiny'shy. Why does this driver masks out all
> sensors available? Why don't we expose all of them and use id property
> to expose and identify each of them?

This has been the case until v9 of this series. It was requested by
Mediatek that the CPU frequency regulation works better when the maximum
of all sensors is taken instead of only single sensors. We decided to
expose the maximum of all sensors in the device tree. IN the end it will
be easier to add additional sensors should we need them later than it is
to get rid of sensors we don't need.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Sascha Hauer]

On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > This adds the device tree binding documentation for the mediatek thermal
> > > controller found on Mediatek MT8173 and other SoCs.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > >  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > new file mode 100644
> > > index 0000000..81f9a51
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > @@ -0,0 +1,43 @@
> > > +* Mediatek Thermal
> > > +
> > > +This describes the device tree binding for the Mediatek thermal controller
> > > +which measures the on-SoC temperatures. This device does not have its own ADC,
> > > +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> > > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > > +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> > > +is also needed.
> > > +
> > > +Required properties:
> > > +- compatible: "mediatek,mt8173-thermal"
> > > +- reg: Address range of the thermal controller
> > > +- interrupts: IRQ for the thermal controller
> > > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > > +                       clocks are:
> > > +                      "therm":  Main clock needed for register access
> > > +                      "auxadc": The AUXADC clock
> > > +- resets: Reference to the reset controller controlling the thermal controller.
> > > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> > > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> > > +
> > > +Optional properties:
> > > +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> > > +               unspecified default values shall be used.
> > > +- nvmem-cell-names: Should be "calibration-data"
> > > +
> > > +Example:
> > > +
> > > +       thermal: thermal at 1100b000 {
> > > +               #thermal-sensor-cells = <1>;
> > 
> > Tiny nit: this should now be:
> > 
> > #thermal-sensor-cells = <0>;
> 
> 
> This is actually not so tiny'shy. Why does this driver masks out all
> sensors available? Why don't we expose all of them and use id property
> to expose and identify each of them?

This has been the case until v9 of this series. It was requested by
Mediatek that the CPU frequency regulation works better when the maximum
of all sensors is taken instead of only single sensors. We decided to
expose the maximum of all sensors in the device tree. IN the end it will
be easier to add additional sensors should we need them later than it is
to get rid of sensors we don't need.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Sascha Hauer]

On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > This adds the device tree binding documentation for the mediatek thermal
> > > controller found on Mediatek MT8173 and other SoCs.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > >  .../bindings/thermal/mediatek-thermal.txt          | 43 ++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > new file mode 100644
> > > index 0000000..81f9a51
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > @@ -0,0 +1,43 @@
> > > +* Mediatek Thermal
> > > +
> > > +This describes the device tree binding for the Mediatek thermal controller
> > > +which measures the on-SoC temperatures. This device does not have its own ADC,
> > > +instead it directly controls the AUXADC via AHB bus accesses. For this reason
> > > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > > +apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
> > > +is also needed.
> > > +
> > > +Required properties:
> > > +- compatible: "mediatek,mt8173-thermal"
> > > +- reg: Address range of the thermal controller
> > > +- interrupts: IRQ for the thermal controller
> > > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > > +                       clocks are:
> > > +                      "therm":  Main clock needed for register access
> > > +                      "auxadc": The AUXADC clock
> > > +- resets: Reference to the reset controller controlling the thermal controller.
> > > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
> > > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description.
> > > +
> > > +Optional properties:
> > > +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
> > > +               unspecified default values shall be used.
> > > +- nvmem-cell-names: Should be "calibration-data"
> > > +
> > > +Example:
> > > +
> > > +       thermal: thermal@1100b000 {
> > > +               #thermal-sensor-cells = <1>;
> > 
> > Tiny nit: this should now be:
> > 
> > #thermal-sensor-cells = <0>;
> 
> 
> This is actually not so tiny'shy. Why does this driver masks out all
> sensors available? Why don't we expose all of them and use id property
> to expose and identify each of them?

This has been the case until v9 of this series. It was requested by
Mediatek that the CPU frequency regulation works better when the maximum
of all sensors is taken instead of only single sensors. We decided to
expose the maximum of all sensors in the device tree. IN the end it will
be easier to add additional sensors should we need them later than it is
to get rid of sensors we don't need.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Eduardo Valentin]

Hello Sascha,

On Fri, Dec 18, 2015 at 08:16:33AM +0100, Sascha Hauer wrote:
> On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> > On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > +Example:

<cut>

> > > > +
> > > > +       thermal: thermal@1100b000 {
> > > > +               #thermal-sensor-cells = <1>;
> > > 
> > > Tiny nit: this should now be:
> > > 
> > > #thermal-sensor-cells = <0>;
> > 
> > 
> > This is actually not so tiny'shy. Why does this driver masks out all
> > sensors available? Why don't we expose all of them and use id property
> > to expose and identify each of them?
> 
> This has been the case until v9 of this series. It was requested by
> Mediatek that the CPU frequency regulation works better when the maximum
> of all sensors is taken instead of only single sensors. We decided to
> expose the maximum of all sensors in the device tree. IN the end it will
> be easier to add additional sensors should we need them later than it is
> to get rid of sensors we don't need.

Apologize as I completely missed this transition from v9 to v10. In
fact, I really cannot understand the benefit of having such constraint
implemented in the driver. In device tree you can mark a thermal zone as
status disabled and it won't appear in your system.

One can select which sensors / thermal zones are required. And even
reuse same dtsi, and change status on dts per board. 

The combination of the above, with the possibility to select the maximum
from thermal core / sysfs, would be bring much more flexibility for a
system engineer, than having the maximum coded in the driver, because,
well, changing that relation would require changing the code. If you
keep the driver as simple as possible, changing the this setup later
would be as simple as changing the dts(i).

What do you think?

BR,

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Eduardo Valentin]

Hello Sascha,

On Fri, Dec 18, 2015 at 08:16:33AM +0100, Sascha Hauer wrote:
> On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> > On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > +Example:

<cut>

> > > > +
> > > > +       thermal: thermal at 1100b000 {
> > > > +               #thermal-sensor-cells = <1>;
> > > 
> > > Tiny nit: this should now be:
> > > 
> > > #thermal-sensor-cells = <0>;
> > 
> > 
> > This is actually not so tiny'shy. Why does this driver masks out all
> > sensors available? Why don't we expose all of them and use id property
> > to expose and identify each of them?
> 
> This has been the case until v9 of this series. It was requested by
> Mediatek that the CPU frequency regulation works better when the maximum
> of all sensors is taken instead of only single sensors. We decided to
> expose the maximum of all sensors in the device tree. IN the end it will
> be easier to add additional sensors should we need them later than it is
> to get rid of sensors we don't need.

Apologize as I completely missed this transition from v9 to v10. In
fact, I really cannot understand the benefit of having such constraint
implemented in the driver. In device tree you can mark a thermal zone as
status disabled and it won't appear in your system.

One can select which sensors / thermal zones are required. And even
reuse same dtsi, and change status on dts per board. 

The combination of the above, with the possibility to select the maximum
from thermal core / sysfs, would be bring much more flexibility for a
system engineer, than having the maximum coded in the driver, because,
well, changing that relation would require changing the code. If you
keep the driver as simple as possible, changing the this setup later
would be as simple as changing the dts(i).

What do you think?

BR,

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Eduardo Valentin]

Hello Sascha,

On Fri, Dec 18, 2015 at 08:16:33AM +0100, Sascha Hauer wrote:
> On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> > On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > > > +Example:

<cut>

> > > > +
> > > > +       thermal: thermal@1100b000 {
> > > > +               #thermal-sensor-cells = <1>;
> > > 
> > > Tiny nit: this should now be:
> > > 
> > > #thermal-sensor-cells = <0>;
> > 
> > 
> > This is actually not so tiny'shy. Why does this driver masks out all
> > sensors available? Why don't we expose all of them and use id property
> > to expose and identify each of them?
> 
> This has been the case until v9 of this series. It was requested by
> Mediatek that the CPU frequency regulation works better when the maximum
> of all sensors is taken instead of only single sensors. We decided to
> expose the maximum of all sensors in the device tree. IN the end it will
> be easier to add additional sensors should we need them later than it is
> to get rid of sensors we don't need.

Apologize as I completely missed this transition from v9 to v10. In
fact, I really cannot understand the benefit of having such constraint
implemented in the driver. In device tree you can mark a thermal zone as
status disabled and it won't appear in your system.

One can select which sensors / thermal zones are required. And even
reuse same dtsi, and change status on dts per board. 

The combination of the above, with the possibility to select the maximum
from thermal core / sysfs, would be bring much more flexibility for a
system engineer, than having the maximum coded in the driver, because,
well, changing that relation would require changing the code. If you
keep the driver as simple as possible, changing the this setup later
would be as simple as changing the dts(i).

What do you think?

BR,

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

This adds support for the Mediatek thermal controller found on MT8173
and likely other SoCs.
The controller is a bit special. It does not have its own ADC, instead
it controls the on-SoC AUXADC via AHB bus accesses. For this reason
we need the physical address of the AUXADC. Also it controls a mux
using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/thermal/Kconfig       |   8 +
 drivers/thermal/Makefile      |   1 +
 drivers/thermal/mtk_thermal.c | 623 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 632 insertions(+)
 create mode 100644 drivers/thermal/mtk_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5aabc4b..503448a 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL
 	  Thermal reporting device will provide temperature reading,
 	  programmable trip points and other information.
 
+config MTK_THERMAL
+	tristate "Temperature sensor driver for mediatek SoCs"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	default y
+	help
+	  Enable this option if you want to have support for thermal management
+	  controller present in Mediatek SoCs
+
 menu "Texas Instruments thermal drivers"
 depends on ARCH_HAS_BANDGAP || COMPILE_TEST
 source "drivers/thermal/ti-soc-thermal/Kconfig"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 26f1608..5f979e7 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL)	+= intel_pch_thermal.o
 obj-$(CONFIG_ST_THERMAL)	+= st/
 obj-$(CONFIG_TEGRA_SOCTHERM)	+= tegra_soctherm.o
 obj-$(CONFIG_HISI_THERMAL)     += hisi_thermal.o
+obj-$(CONFIG_MTK_THERMAL)	+= mtk_thermal.o
diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
new file mode 100644
index 0000000..589a138
--- /dev/null
+++ b/drivers/thermal/mtk_thermal.c
@@ -0,0 +1,623 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Hanyi Wu <hanyi.wu@mediatek.com>
+ *         Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/thermal.h>
+#include <linux/reset.h>
+#include <linux/types.h>
+#include <linux/nvmem-consumer.h>
+
+/* AUXADC Registers */
+#define AUXADC_CON0_V		0x000
+#define AUXADC_CON1_V		0x004
+#define AUXADC_CON1_SET_V	0x008
+#define AUXADC_CON1_CLR_V	0x00c
+#define AUXADC_CON2_V		0x010
+#define AUXADC_DATA(channel)	(0x14 + (channel) * 4)
+#define AUXADC_MISC_V		0x094
+
+#define AUXADC_CON1_CHANNEL(x)	BIT(x)
+
+#define APMIXED_SYS_TS_CON1	0x604
+
+/* Thermal Controller Registers */
+#define TEMP_MONCTL0		0x000
+#define TEMP_MONCTL1		0x004
+#define TEMP_MONCTL2		0x008
+#define TEMP_MONIDET0		0x014
+#define TEMP_MONIDET1		0x018
+#define TEMP_MSRCTL0		0x038
+#define TEMP_AHBPOLL		0x040
+#define TEMP_AHBTO		0x044
+#define TEMP_ADCPNP0		0x048
+#define TEMP_ADCPNP1		0x04c
+#define TEMP_ADCPNP2		0x050
+#define TEMP_ADCPNP3		0x0b4
+
+#define TEMP_ADCMUX		0x054
+#define TEMP_ADCEN		0x060
+#define TEMP_PNPMUXADDR		0x064
+#define TEMP_ADCMUXADDR		0x068
+#define TEMP_ADCENADDR		0x074
+#define TEMP_ADCVALIDADDR	0x078
+#define TEMP_ADCVOLTADDR	0x07c
+#define TEMP_RDCTRL		0x080
+#define TEMP_ADCVALIDMASK	0x084
+#define TEMP_ADCVOLTAGESHIFT	0x088
+#define TEMP_ADCWRITECTRL	0x08c
+#define TEMP_MSR0		0x090
+#define TEMP_MSR1		0x094
+#define TEMP_MSR2		0x098
+#define TEMP_MSR3		0x0B8
+
+#define TEMP_SPARE0		0x0f0
+
+#define PTPCORESEL		0x400
+
+#define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
+
+#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
+#define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
+
+#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
+
+#define TEMP_ADCWRITECTRL_ADC_PNP_WRITE		BIT(0)
+#define TEMP_ADCWRITECTRL_ADC_MUX_WRITE		BIT(1)
+
+#define TEMP_ADCVALIDMASK_VALID_HIGH		BIT(5)
+#define TEMP_ADCVALIDMASK_VALID_POS(bit)	(bit)
+
+#define MT8173_TS1	0
+#define MT8173_TS2	1
+#define MT8173_TS3	2
+#define MT8173_TS4	3
+#define MT8173_TSABB	4
+
+/* AUXADC channel 11 is used for the temperature sensors */
+#define MT8173_TEMP_AUXADC_CHANNEL	11
+
+/* The total number of temperature sensors in the MT8173 */
+#define MT8173_NUM_SENSORS		5
+
+/* The number of banks in the MT8173 */
+#define MT8173_NUM_ZONES		4
+
+/* The number of sensing points per bank */
+#define MT8173_NUM_SENSORS_PER_ZONE	4
+
+/* Layout of the fuses providing the calibration data */
+#define MT8173_CALIB_BUF0_VALID		(1 << 0)
+#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
+#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
+#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
+#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
+#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
+#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
+
+#define THERMAL_NAME    "mtk-thermal"
+
+struct mtk_thermal;
+
+struct mtk_thermal_bank {
+	struct mtk_thermal *mt;
+	int id;
+};
+
+struct mtk_thermal {
+	struct device *dev;
+	void __iomem *thermal_base;
+
+	struct clk *clk_peri_therm;
+	struct clk *clk_auxadc;
+
+	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
+
+	struct mutex lock;
+
+	/* Calibration values */
+	s32 adc_ge;
+	s32 degc_cali;
+	s32 o_slope;
+	s32 vts[MT8173_NUM_SENSORS];
+
+	struct thermal_zone_device *tzd;
+};
+
+struct mtk_thermal_bank_cfg {
+	unsigned int num_sensors;
+	unsigned int sensors[MT8173_NUM_SENSORS_PER_ZONE];
+};
+
+static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+
+/*
+ * The MT8173 thermal controller has four banks. Each bank can read up to
+ * four temperature sensors simultaneously. The MT8173 has a total of 5
+ * temperature sensors. We use each bank to measure a certain area of the
+ * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple
+ * areas, hence is used in different banks.
+ *
+ * The thermal core only gets the maximum temperature of all banks, so
+ * the bank concept wouldn't be necessary here. However, the SVS (Smart
+ * Voltage Scaling) unit makes its decisions based on the same bank
+ * data, and this indeed needs the temperatures of the individual banks
+ * for making better decisions.
+ */
+static const struct mtk_thermal_bank_cfg bank_data[] = {
+	{
+		.num_sensors = 2,
+		.sensors = { MT8173_TS2, MT8173_TS3 },
+	}, {
+		.num_sensors = 2,
+		.sensors = { MT8173_TS2, MT8173_TS4 },
+	}, {
+		.num_sensors = 3,
+		.sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
+	}, {
+		.num_sensors = 1,
+		.sensors = { MT8173_TS2 },
+	},
+};
+
+struct mtk_thermal_sense_point {
+	int msr;
+	int adcpnp;
+};
+
+static const struct mtk_thermal_sense_point
+		sensing_points[MT8173_NUM_SENSORS_PER_ZONE] = {
+	{
+		.msr = TEMP_MSR0,
+		.adcpnp = TEMP_ADCPNP0,
+	}, {
+		.msr = TEMP_MSR1,
+		.adcpnp = TEMP_ADCPNP1,
+	}, {
+		.msr = TEMP_MSR2,
+		.adcpnp = TEMP_ADCPNP2,
+	}, {
+		.msr = TEMP_MSR3,
+		.adcpnp = TEMP_ADCPNP3,
+	},
+};
+
+/**
+ * raw_to_mcelsius - convert a raw ADC value to mcelsius
+ * @mt:		The thermal controller
+ * @raw:	raw ADC value
+ *
+ * This converts the raw ADC value to mcelsius using the SoC specific
+ * calibration constants
+ */
+static int raw_to_mcelsius(struct mtk_thermal *mt, int sensno, s32 raw)
+{
+	s32 tmp;
+
+	raw &= 0xfff;
+
+	tmp = 203450520 << 3;
+	tmp /= 165 + mt->o_slope;
+	tmp /= 10000 + mt->adc_ge;
+	tmp *= raw - mt->vts[sensno] - 3350;
+	tmp >>= 3;
+
+	return mt->degc_cali * 500 - tmp;
+}
+
+/**
+ * mtk_thermal_get_bank - get bank
+ * @bank:	The bank
+ *
+ * The bank registers are banked, we have to select a bank in the
+ * PTPCORESEL register to access it.
+ */
+static void mtk_thermal_get_bank(struct mtk_thermal_bank *bank)
+{
+	struct mtk_thermal *mt = bank->mt;
+	u32 val;
+
+	mutex_lock(&mt->lock);
+
+	val = readl(mt->thermal_base + PTPCORESEL);
+	val &= ~0xf;
+	val |= bank->id;
+	writel(val, mt->thermal_base + PTPCORESEL);
+}
+
+/**
+ * mtk_thermal_put_bank - release bank
+ * @bank:	The bank
+ *
+ * release a bank previously taken with mtk_thermal_get_bank,
+ */
+static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
+{
+	struct mtk_thermal *mt = bank->mt;
+
+	mutex_unlock(&mt->lock);
+}
+
+/**
+ * mtk_thermal_bank_temperature - get the temperature of a bank
+ * @bank:	The bank
+ *
+ * The temperature of a bank is considered the maximum temperature of
+ * the sensors associated to the bank.
+ */
+static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
+{
+	struct mtk_thermal *mt = bank->mt;
+	int temp, i, max;
+	u32 raw;
+
+	temp = max = INT_MIN;
+
+	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
+		raw = readl(mt->thermal_base + sensing_points[i].msr);
+
+		temp = raw_to_mcelsius(mt, bank_data[bank->id].sensors[i], raw);
+
+		/*
+		 * The first read of a sensor often contains very high bogus
+		 * temperature value. Filter these out so that the system does
+		 * not immediately shut down.
+		 */
+		if (temp > 200000)
+			temp = 0;
+
+		if (temp > max)
+			max = temp;
+	}
+
+	return max;
+}
+
+static int mtk_read_temp(void *data, int *temperature)
+{
+	struct mtk_thermal *mt = data;
+	int i;
+	int tempmax = INT_MIN;
+
+	for (i = 0; i < MT8173_NUM_ZONES; i++) {
+		struct mtk_thermal_bank *bank = &mt->banks[i];
+
+		mtk_thermal_get_bank(bank);
+
+		tempmax = max(tempmax, mtk_thermal_bank_temperature(bank));
+
+		mtk_thermal_put_bank(bank);
+	}
+
+	*temperature = tempmax;
+
+	return 0;
+}
+
+static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
+	.get_temp = mtk_read_temp,
+};
+
+static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
+		u32 apmixed_phys_base, u32 auxadc_phys_base)
+{
+	struct mtk_thermal_bank *bank = &mt->banks[num];
+	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
+	int i;
+
+	bank->id = num;
+	bank->mt = mt;
+
+	mtk_thermal_get_bank(bank);
+
+	/* bus clock 66M counting unit is 12 * 15.15ns * 256 = 46.540us */
+	writel(TEMP_MONCTL1_PERIOD_UNIT(12), mt->thermal_base + TEMP_MONCTL1);
+
+	/*
+	 * filt interval is 1 * 46.540us = 46.54us,
+	 * sen interval is 429 * 46.540us = 19.96ms
+	 */
+	writel(TEMP_MONCTL2_FILTER_INTERVAL(1) |
+			TEMP_MONCTL2_SENSOR_INTERVAL(429),
+			mt->thermal_base + TEMP_MONCTL2);
+
+	/* poll is set to 10u */
+	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
+			mt->thermal_base + TEMP_AHBPOLL);
+
+	/* temperature sampling control, 1 sample */
+	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
+
+	/* exceed this polling time, IRQ would be inserted */
+	writel(0xffffffff, mt->thermal_base + TEMP_AHBTO);
+
+	/* number of interrupts per event, 1 is enough */
+	writel(0x0, mt->thermal_base + TEMP_MONIDET0);
+	writel(0x0, mt->thermal_base + TEMP_MONIDET1);
+
+	/*
+	 * The MT8173 thermal controller does not have its own ADC. Instead it
+	 * uses AHB bus accesses to control the AUXADC. To do this the thermal
+	 * controller has to be programmed with the physical addresses of the
+	 * AUXADC registers and with the various bit positions in the AUXADC.
+	 * Also the thermal controller controls a mux in the APMIXEDSYS register
+	 * space.
+	 */
+
+	/*
+	 * this value will be stored to TEMP_PNPMUXADDR (TEMP_SPARE0)
+	 * automatically by hw
+	 */
+	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCMUX);
+
+	/* AHB address for auxadc mux selection */
+	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
+			mt->thermal_base + TEMP_ADCMUXADDR);
+
+	/* AHB address for pnp sensor mux selection */
+	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
+			mt->thermal_base + TEMP_PNPMUXADDR);
+
+	/* AHB value for auxadc enable */
+	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
+
+	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
+	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
+			mt->thermal_base + TEMP_ADCENADDR);
+
+	/* AHB address for auxadc valid bit */
+	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
+			mt->thermal_base + TEMP_ADCVALIDADDR);
+
+	/* AHB address for auxadc voltage output */
+	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
+			mt->thermal_base + TEMP_ADCVOLTADDR);
+
+	/* read valid & voltage are at the same register */
+	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
+
+	/* indicate where the valid bit is */
+	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
+			mt->thermal_base + TEMP_ADCVALIDMASK);
+
+	/* no shift */
+	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
+
+	/* enable auxadc mux write transaction */
+	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+			mt->thermal_base + TEMP_ADCWRITECTRL);
+
+	for (i = 0; i < cfg->num_sensors; i++)
+		writel(sensor_mux_values[cfg->sensors[i]],
+				mt->thermal_base + sensing_points[i].adcpnp);
+
+	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
+
+	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+			mt->thermal_base + TEMP_ADCWRITECTRL);
+
+	mtk_thermal_put_bank(bank);
+}
+
+static u64 of_get_phys_base(struct device_node *np)
+{
+	u64 size64;
+	const __be32 *regaddr_p;
+
+	regaddr_p = of_get_address(np, 0, &size64, NULL);
+	if (!regaddr_p)
+		return OF_BAD_ADDR;
+
+	return of_translate_address(np, regaddr_p);
+}
+
+static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
+{
+	struct nvmem_cell *cell;
+	u32 *buf;
+	size_t len;
+	int i, ret = 0;
+
+	/* Start with default values */
+	mt->adc_ge = 512;
+	for (i = 0; i < MT8173_NUM_SENSORS; i++)
+		mt->vts[i] = 260;
+	mt->degc_cali = 40;
+	mt->o_slope = 0;
+
+	cell = nvmem_cell_get(dev, "calibration-data");
+	if (IS_ERR(cell)) {
+		if (PTR_ERR(cell) == -EPROBE_DEFER)
+			return PTR_ERR(cell);
+		return 0;
+	}
+
+	buf = (u32 *)nvmem_cell_read(cell, &len);
+
+	nvmem_cell_put(cell);
+
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
+
+	if (len < 3 * sizeof(u32)) {
+		dev_warn(dev, "invalid calibration data\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (buf[0] & MT8173_CALIB_BUF0_VALID) {
+		mt->adc_ge = MT8173_CALIB_BUF1_ADC_GE(buf[1]);
+		mt->vts[MT8173_TS1] = MT8173_CALIB_BUF0_VTS_TS1(buf[0]);
+		mt->vts[MT8173_TS2] = MT8173_CALIB_BUF0_VTS_TS2(buf[0]);
+		mt->vts[MT8173_TS3] = MT8173_CALIB_BUF1_VTS_TS3(buf[1]);
+		mt->vts[MT8173_TS4] = MT8173_CALIB_BUF2_VTS_TS4(buf[2]);
+		mt->vts[MT8173_TSABB] = MT8173_CALIB_BUF2_VTS_TSABB(buf[2]);
+		mt->degc_cali = MT8173_CALIB_BUF0_DEGC_CALI(buf[0]);
+		mt->o_slope = MT8173_CALIB_BUF0_O_SLOPE(buf[0]);
+	} else {
+		dev_info(dev, "Device not calibrated, using default calibration values\n");
+	}
+
+out:
+	kfree(buf);
+
+	return ret;
+}
+
+static int mtk_thermal_probe(struct platform_device *pdev)
+{
+	int ret, i;
+	struct device_node *auxadc, *apmixedsys, *np = pdev->dev.of_node;
+	struct mtk_thermal *mt;
+	struct resource *res;
+	u64 auxadc_phys_base, apmixed_phys_base;
+
+	mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL);
+	if (!mt)
+		return -ENOMEM;
+
+	mt->clk_peri_therm = devm_clk_get(&pdev->dev, "therm");
+	if (IS_ERR(mt->clk_peri_therm))
+		return PTR_ERR(mt->clk_peri_therm);
+
+	mt->clk_auxadc = devm_clk_get(&pdev->dev, "auxadc");
+	if (IS_ERR(mt->clk_auxadc))
+		return PTR_ERR(mt->clk_auxadc);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mt->thermal_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mt->thermal_base))
+		return PTR_ERR(mt->thermal_base);
+
+	ret = mtk_thermal_get_calibration_data(&pdev->dev, mt);
+	if (ret)
+		return ret;
+
+	mutex_init(&mt->lock);
+
+	mt->dev = &pdev->dev;
+
+	auxadc = of_parse_phandle(np, "mediatek,auxadc", 0);
+	if (!auxadc) {
+		dev_err(&pdev->dev, "missing auxadc node\n");
+		return -ENODEV;
+	}
+
+	auxadc_phys_base = of_get_phys_base(auxadc);
+
+	of_node_put(auxadc);
+
+	if (auxadc_phys_base == OF_BAD_ADDR) {
+		dev_err(&pdev->dev, "Can't get auxadc phys address\n");
+		return -EINVAL;
+	}
+
+	apmixedsys = of_parse_phandle(np, "mediatek,apmixedsys", 0);
+	if (!apmixedsys) {
+		dev_err(&pdev->dev, "missing apmixedsys node\n");
+		return -ENODEV;
+	}
+
+	apmixed_phys_base = of_get_phys_base(apmixedsys);
+
+	of_node_put(apmixedsys);
+
+	if (apmixed_phys_base == OF_BAD_ADDR) {
+		dev_err(&pdev->dev, "Can't get auxadc phys address\n");
+		return -EINVAL;
+	}
+
+	ret = clk_prepare_enable(mt->clk_auxadc);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n", ret);
+		return ret;
+	}
+
+	ret = device_reset(&pdev->dev);
+	if (ret)
+		goto err_disable_clk_auxadc;
+
+	ret = clk_prepare_enable(mt->clk_peri_therm);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't enable peri clk: %d\n", ret);
+		goto err_disable_clk_auxadc;
+	}
+
+	for (i = 0; i < MT8173_NUM_ZONES; i++)
+		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
+
+	platform_set_drvdata(pdev, mt);
+
+	mt->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0, mt,
+				&mtk_thermal_ops);
+	if (IS_ERR(mt->tzd))
+		goto err_register;
+
+	return 0;
+
+err_register:
+	clk_disable_unprepare(mt->clk_peri_therm);
+
+err_disable_clk_auxadc:
+	clk_disable_unprepare(mt->clk_auxadc);
+
+	return ret;
+}
+
+static int mtk_thermal_remove(struct platform_device *pdev)
+{
+	struct mtk_thermal *mt = platform_get_drvdata(pdev);
+
+	thermal_zone_of_sensor_unregister(&pdev->dev, mt->tzd);
+
+	clk_disable_unprepare(mt->clk_peri_therm);
+	clk_disable_unprepare(mt->clk_auxadc);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_thermal_of_match[] = {
+	{
+		.compatible = "mediatek,mt8173-thermal",
+	}, {
+	},
+};
+
+static struct platform_driver mtk_thermal_driver = {
+	.probe = mtk_thermal_probe,
+	.remove = mtk_thermal_remove,
+	.driver = {
+		.name = THERMAL_NAME,
+		.of_match_table = mtk_thermal_of_match,
+	},
+};
+
+module_platform_driver(mtk_thermal_driver);
+
+MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de");
+MODULE_AUTHOR("Hanyi Wu <hanyi.wu@mediatek.com>");
+MODULE_DESCRIPTION("Mediatek thermal driver");
+MODULE_LICENSE("GPL v2");
-- 
2.6.2

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

This adds support for the Mediatek thermal controller found on MT8173
and likely other SoCs.
The controller is a bit special. It does not have its own ADC, instead
it controls the on-SoC AUXADC via AHB bus accesses. For this reason
we need the physical address of the AUXADC. Also it controls a mux
using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/thermal/Kconfig       |   8 +
 drivers/thermal/Makefile      |   1 +
 drivers/thermal/mtk_thermal.c | 623 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 632 insertions(+)
 create mode 100644 drivers/thermal/mtk_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5aabc4b..503448a 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL
 	  Thermal reporting device will provide temperature reading,
 	  programmable trip points and other information.
 
+config MTK_THERMAL
+	tristate "Temperature sensor driver for mediatek SoCs"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	default y
+	help
+	  Enable this option if you want to have support for thermal management
+	  controller present in Mediatek SoCs
+
 menu "Texas Instruments thermal drivers"
 depends on ARCH_HAS_BANDGAP || COMPILE_TEST
 source "drivers/thermal/ti-soc-thermal/Kconfig"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 26f1608..5f979e7 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL)	+= intel_pch_thermal.o
 obj-$(CONFIG_ST_THERMAL)	+= st/
 obj-$(CONFIG_TEGRA_SOCTHERM)	+= tegra_soctherm.o
 obj-$(CONFIG_HISI_THERMAL)     += hisi_thermal.o
+obj-$(CONFIG_MTK_THERMAL)	+= mtk_thermal.o
diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
new file mode 100644
index 0000000..589a138
--- /dev/null
+++ b/drivers/thermal/mtk_thermal.c
@@ -0,0 +1,623 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Hanyi Wu <hanyi.wu@mediatek.com>
+ *         Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/thermal.h>
+#include <linux/reset.h>
+#include <linux/types.h>
+#include <linux/nvmem-consumer.h>
+
+/* AUXADC Registers */
+#define AUXADC_CON0_V		0x000
+#define AUXADC_CON1_V		0x004
+#define AUXADC_CON1_SET_V	0x008
+#define AUXADC_CON1_CLR_V	0x00c
+#define AUXADC_CON2_V		0x010
+#define AUXADC_DATA(channel)	(0x14 + (channel) * 4)
+#define AUXADC_MISC_V		0x094
+
+#define AUXADC_CON1_CHANNEL(x)	BIT(x)
+
+#define APMIXED_SYS_TS_CON1	0x604
+
+/* Thermal Controller Registers */
+#define TEMP_MONCTL0		0x000
+#define TEMP_MONCTL1		0x004
+#define TEMP_MONCTL2		0x008
+#define TEMP_MONIDET0		0x014
+#define TEMP_MONIDET1		0x018
+#define TEMP_MSRCTL0		0x038
+#define TEMP_AHBPOLL		0x040
+#define TEMP_AHBTO		0x044
+#define TEMP_ADCPNP0		0x048
+#define TEMP_ADCPNP1		0x04c
+#define TEMP_ADCPNP2		0x050
+#define TEMP_ADCPNP3		0x0b4
+
+#define TEMP_ADCMUX		0x054
+#define TEMP_ADCEN		0x060
+#define TEMP_PNPMUXADDR		0x064
+#define TEMP_ADCMUXADDR		0x068
+#define TEMP_ADCENADDR		0x074
+#define TEMP_ADCVALIDADDR	0x078
+#define TEMP_ADCVOLTADDR	0x07c
+#define TEMP_RDCTRL		0x080
+#define TEMP_ADCVALIDMASK	0x084
+#define TEMP_ADCVOLTAGESHIFT	0x088
+#define TEMP_ADCWRITECTRL	0x08c
+#define TEMP_MSR0		0x090
+#define TEMP_MSR1		0x094
+#define TEMP_MSR2		0x098
+#define TEMP_MSR3		0x0B8
+
+#define TEMP_SPARE0		0x0f0
+
+#define PTPCORESEL		0x400
+
+#define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
+
+#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
+#define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
+
+#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
+
+#define TEMP_ADCWRITECTRL_ADC_PNP_WRITE		BIT(0)
+#define TEMP_ADCWRITECTRL_ADC_MUX_WRITE		BIT(1)
+
+#define TEMP_ADCVALIDMASK_VALID_HIGH		BIT(5)
+#define TEMP_ADCVALIDMASK_VALID_POS(bit)	(bit)
+
+#define MT8173_TS1	0
+#define MT8173_TS2	1
+#define MT8173_TS3	2
+#define MT8173_TS4	3
+#define MT8173_TSABB	4
+
+/* AUXADC channel 11 is used for the temperature sensors */
+#define MT8173_TEMP_AUXADC_CHANNEL	11
+
+/* The total number of temperature sensors in the MT8173 */
+#define MT8173_NUM_SENSORS		5
+
+/* The number of banks in the MT8173 */
+#define MT8173_NUM_ZONES		4
+
+/* The number of sensing points per bank */
+#define MT8173_NUM_SENSORS_PER_ZONE	4
+
+/* Layout of the fuses providing the calibration data */
+#define MT8173_CALIB_BUF0_VALID		(1 << 0)
+#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
+#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
+#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
+#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
+#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
+#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
+
+#define THERMAL_NAME    "mtk-thermal"
+
+struct mtk_thermal;
+
+struct mtk_thermal_bank {
+	struct mtk_thermal *mt;
+	int id;
+};
+
+struct mtk_thermal {
+	struct device *dev;
+	void __iomem *thermal_base;
+
+	struct clk *clk_peri_therm;
+	struct clk *clk_auxadc;
+
+	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
+
+	struct mutex lock;
+
+	/* Calibration values */
+	s32 adc_ge;
+	s32 degc_cali;
+	s32 o_slope;
+	s32 vts[MT8173_NUM_SENSORS];
+
+	struct thermal_zone_device *tzd;
+};
+
+struct mtk_thermal_bank_cfg {
+	unsigned int num_sensors;
+	unsigned int sensors[MT8173_NUM_SENSORS_PER_ZONE];
+};
+
+static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+
+/*
+ * The MT8173 thermal controller has four banks. Each bank can read up to
+ * four temperature sensors simultaneously. The MT8173 has a total of 5
+ * temperature sensors. We use each bank to measure a certain area of the
+ * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple
+ * areas, hence is used in different banks.
+ *
+ * The thermal core only gets the maximum temperature of all banks, so
+ * the bank concept wouldn't be necessary here. However, the SVS (Smart
+ * Voltage Scaling) unit makes its decisions based on the same bank
+ * data, and this indeed needs the temperatures of the individual banks
+ * for making better decisions.
+ */
+static const struct mtk_thermal_bank_cfg bank_data[] = {
+	{
+		.num_sensors = 2,
+		.sensors = { MT8173_TS2, MT8173_TS3 },
+	}, {
+		.num_sensors = 2,
+		.sensors = { MT8173_TS2, MT8173_TS4 },
+	}, {
+		.num_sensors = 3,
+		.sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
+	}, {
+		.num_sensors = 1,
+		.sensors = { MT8173_TS2 },
+	},
+};
+
+struct mtk_thermal_sense_point {
+	int msr;
+	int adcpnp;
+};
+
+static const struct mtk_thermal_sense_point
+		sensing_points[MT8173_NUM_SENSORS_PER_ZONE] = {
+	{
+		.msr = TEMP_MSR0,
+		.adcpnp = TEMP_ADCPNP0,
+	}, {
+		.msr = TEMP_MSR1,
+		.adcpnp = TEMP_ADCPNP1,
+	}, {
+		.msr = TEMP_MSR2,
+		.adcpnp = TEMP_ADCPNP2,
+	}, {
+		.msr = TEMP_MSR3,
+		.adcpnp = TEMP_ADCPNP3,
+	},
+};
+
+/**
+ * raw_to_mcelsius - convert a raw ADC value to mcelsius
+ * @mt:		The thermal controller
+ * @raw:	raw ADC value
+ *
+ * This converts the raw ADC value to mcelsius using the SoC specific
+ * calibration constants
+ */
+static int raw_to_mcelsius(struct mtk_thermal *mt, int sensno, s32 raw)
+{
+	s32 tmp;
+
+	raw &= 0xfff;
+
+	tmp = 203450520 << 3;
+	tmp /= 165 + mt->o_slope;
+	tmp /= 10000 + mt->adc_ge;
+	tmp *= raw - mt->vts[sensno] - 3350;
+	tmp >>= 3;
+
+	return mt->degc_cali * 500 - tmp;
+}
+
+/**
+ * mtk_thermal_get_bank - get bank
+ * @bank:	The bank
+ *
+ * The bank registers are banked, we have to select a bank in the
+ * PTPCORESEL register to access it.
+ */
+static void mtk_thermal_get_bank(struct mtk_thermal_bank *bank)
+{
+	struct mtk_thermal *mt = bank->mt;
+	u32 val;
+
+	mutex_lock(&mt->lock);
+
+	val = readl(mt->thermal_base + PTPCORESEL);
+	val &= ~0xf;
+	val |= bank->id;
+	writel(val, mt->thermal_base + PTPCORESEL);
+}
+
+/**
+ * mtk_thermal_put_bank - release bank
+ * @bank:	The bank
+ *
+ * release a bank previously taken with mtk_thermal_get_bank,
+ */
+static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
+{
+	struct mtk_thermal *mt = bank->mt;
+
+	mutex_unlock(&mt->lock);
+}
+
+/**
+ * mtk_thermal_bank_temperature - get the temperature of a bank
+ * @bank:	The bank
+ *
+ * The temperature of a bank is considered the maximum temperature of
+ * the sensors associated to the bank.
+ */
+static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
+{
+	struct mtk_thermal *mt = bank->mt;
+	int temp, i, max;
+	u32 raw;
+
+	temp = max = INT_MIN;
+
+	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
+		raw = readl(mt->thermal_base + sensing_points[i].msr);
+
+		temp = raw_to_mcelsius(mt, bank_data[bank->id].sensors[i], raw);
+
+		/*
+		 * The first read of a sensor often contains very high bogus
+		 * temperature value. Filter these out so that the system does
+		 * not immediately shut down.
+		 */
+		if (temp > 200000)
+			temp = 0;
+
+		if (temp > max)
+			max = temp;
+	}
+
+	return max;
+}
+
+static int mtk_read_temp(void *data, int *temperature)
+{
+	struct mtk_thermal *mt = data;
+	int i;
+	int tempmax = INT_MIN;
+
+	for (i = 0; i < MT8173_NUM_ZONES; i++) {
+		struct mtk_thermal_bank *bank = &mt->banks[i];
+
+		mtk_thermal_get_bank(bank);
+
+		tempmax = max(tempmax, mtk_thermal_bank_temperature(bank));
+
+		mtk_thermal_put_bank(bank);
+	}
+
+	*temperature = tempmax;
+
+	return 0;
+}
+
+static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
+	.get_temp = mtk_read_temp,
+};
+
+static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
+		u32 apmixed_phys_base, u32 auxadc_phys_base)
+{
+	struct mtk_thermal_bank *bank = &mt->banks[num];
+	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
+	int i;
+
+	bank->id = num;
+	bank->mt = mt;
+
+	mtk_thermal_get_bank(bank);
+
+	/* bus clock 66M counting unit is 12 * 15.15ns * 256 = 46.540us */
+	writel(TEMP_MONCTL1_PERIOD_UNIT(12), mt->thermal_base + TEMP_MONCTL1);
+
+	/*
+	 * filt interval is 1 * 46.540us = 46.54us,
+	 * sen interval is 429 * 46.540us = 19.96ms
+	 */
+	writel(TEMP_MONCTL2_FILTER_INTERVAL(1) |
+			TEMP_MONCTL2_SENSOR_INTERVAL(429),
+			mt->thermal_base + TEMP_MONCTL2);
+
+	/* poll is set to 10u */
+	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
+			mt->thermal_base + TEMP_AHBPOLL);
+
+	/* temperature sampling control, 1 sample */
+	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
+
+	/* exceed this polling time, IRQ would be inserted */
+	writel(0xffffffff, mt->thermal_base + TEMP_AHBTO);
+
+	/* number of interrupts per event, 1 is enough */
+	writel(0x0, mt->thermal_base + TEMP_MONIDET0);
+	writel(0x0, mt->thermal_base + TEMP_MONIDET1);
+
+	/*
+	 * The MT8173 thermal controller does not have its own ADC. Instead it
+	 * uses AHB bus accesses to control the AUXADC. To do this the thermal
+	 * controller has to be programmed with the physical addresses of the
+	 * AUXADC registers and with the various bit positions in the AUXADC.
+	 * Also the thermal controller controls a mux in the APMIXEDSYS register
+	 * space.
+	 */
+
+	/*
+	 * this value will be stored to TEMP_PNPMUXADDR (TEMP_SPARE0)
+	 * automatically by hw
+	 */
+	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCMUX);
+
+	/* AHB address for auxadc mux selection */
+	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
+			mt->thermal_base + TEMP_ADCMUXADDR);
+
+	/* AHB address for pnp sensor mux selection */
+	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
+			mt->thermal_base + TEMP_PNPMUXADDR);
+
+	/* AHB value for auxadc enable */
+	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
+
+	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
+	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
+			mt->thermal_base + TEMP_ADCENADDR);
+
+	/* AHB address for auxadc valid bit */
+	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
+			mt->thermal_base + TEMP_ADCVALIDADDR);
+
+	/* AHB address for auxadc voltage output */
+	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
+			mt->thermal_base + TEMP_ADCVOLTADDR);
+
+	/* read valid & voltage are at the same register */
+	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
+
+	/* indicate where the valid bit is */
+	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
+			mt->thermal_base + TEMP_ADCVALIDMASK);
+
+	/* no shift */
+	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
+
+	/* enable auxadc mux write transaction */
+	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+			mt->thermal_base + TEMP_ADCWRITECTRL);
+
+	for (i = 0; i < cfg->num_sensors; i++)
+		writel(sensor_mux_values[cfg->sensors[i]],
+				mt->thermal_base + sensing_points[i].adcpnp);
+
+	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
+
+	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+			mt->thermal_base + TEMP_ADCWRITECTRL);
+
+	mtk_thermal_put_bank(bank);
+}
+
+static u64 of_get_phys_base(struct device_node *np)
+{
+	u64 size64;
+	const __be32 *regaddr_p;
+
+	regaddr_p = of_get_address(np, 0, &size64, NULL);
+	if (!regaddr_p)
+		return OF_BAD_ADDR;
+
+	return of_translate_address(np, regaddr_p);
+}
+
+static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
+{
+	struct nvmem_cell *cell;
+	u32 *buf;
+	size_t len;
+	int i, ret = 0;
+
+	/* Start with default values */
+	mt->adc_ge = 512;
+	for (i = 0; i < MT8173_NUM_SENSORS; i++)
+		mt->vts[i] = 260;
+	mt->degc_cali = 40;
+	mt->o_slope = 0;
+
+	cell = nvmem_cell_get(dev, "calibration-data");
+	if (IS_ERR(cell)) {
+		if (PTR_ERR(cell) == -EPROBE_DEFER)
+			return PTR_ERR(cell);
+		return 0;
+	}
+
+	buf = (u32 *)nvmem_cell_read(cell, &len);
+
+	nvmem_cell_put(cell);
+
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
+
+	if (len < 3 * sizeof(u32)) {
+		dev_warn(dev, "invalid calibration data\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (buf[0] & MT8173_CALIB_BUF0_VALID) {
+		mt->adc_ge = MT8173_CALIB_BUF1_ADC_GE(buf[1]);
+		mt->vts[MT8173_TS1] = MT8173_CALIB_BUF0_VTS_TS1(buf[0]);
+		mt->vts[MT8173_TS2] = MT8173_CALIB_BUF0_VTS_TS2(buf[0]);
+		mt->vts[MT8173_TS3] = MT8173_CALIB_BUF1_VTS_TS3(buf[1]);
+		mt->vts[MT8173_TS4] = MT8173_CALIB_BUF2_VTS_TS4(buf[2]);
+		mt->vts[MT8173_TSABB] = MT8173_CALIB_BUF2_VTS_TSABB(buf[2]);
+		mt->degc_cali = MT8173_CALIB_BUF0_DEGC_CALI(buf[0]);
+		mt->o_slope = MT8173_CALIB_BUF0_O_SLOPE(buf[0]);
+	} else {
+		dev_info(dev, "Device not calibrated, using default calibration values\n");
+	}
+
+out:
+	kfree(buf);
+
+	return ret;
+}
+
+static int mtk_thermal_probe(struct platform_device *pdev)
+{
+	int ret, i;
+	struct device_node *auxadc, *apmixedsys, *np = pdev->dev.of_node;
+	struct mtk_thermal *mt;
+	struct resource *res;
+	u64 auxadc_phys_base, apmixed_phys_base;
+
+	mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL);
+	if (!mt)
+		return -ENOMEM;
+
+	mt->clk_peri_therm = devm_clk_get(&pdev->dev, "therm");
+	if (IS_ERR(mt->clk_peri_therm))
+		return PTR_ERR(mt->clk_peri_therm);
+
+	mt->clk_auxadc = devm_clk_get(&pdev->dev, "auxadc");
+	if (IS_ERR(mt->clk_auxadc))
+		return PTR_ERR(mt->clk_auxadc);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mt->thermal_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mt->thermal_base))
+		return PTR_ERR(mt->thermal_base);
+
+	ret = mtk_thermal_get_calibration_data(&pdev->dev, mt);
+	if (ret)
+		return ret;
+
+	mutex_init(&mt->lock);
+
+	mt->dev = &pdev->dev;
+
+	auxadc = of_parse_phandle(np, "mediatek,auxadc", 0);
+	if (!auxadc) {
+		dev_err(&pdev->dev, "missing auxadc node\n");
+		return -ENODEV;
+	}
+
+	auxadc_phys_base = of_get_phys_base(auxadc);
+
+	of_node_put(auxadc);
+
+	if (auxadc_phys_base == OF_BAD_ADDR) {
+		dev_err(&pdev->dev, "Can't get auxadc phys address\n");
+		return -EINVAL;
+	}
+
+	apmixedsys = of_parse_phandle(np, "mediatek,apmixedsys", 0);
+	if (!apmixedsys) {
+		dev_err(&pdev->dev, "missing apmixedsys node\n");
+		return -ENODEV;
+	}
+
+	apmixed_phys_base = of_get_phys_base(apmixedsys);
+
+	of_node_put(apmixedsys);
+
+	if (apmixed_phys_base == OF_BAD_ADDR) {
+		dev_err(&pdev->dev, "Can't get auxadc phys address\n");
+		return -EINVAL;
+	}
+
+	ret = clk_prepare_enable(mt->clk_auxadc);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n", ret);
+		return ret;
+	}
+
+	ret = device_reset(&pdev->dev);
+	if (ret)
+		goto err_disable_clk_auxadc;
+
+	ret = clk_prepare_enable(mt->clk_peri_therm);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't enable peri clk: %d\n", ret);
+		goto err_disable_clk_auxadc;
+	}
+
+	for (i = 0; i < MT8173_NUM_ZONES; i++)
+		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
+
+	platform_set_drvdata(pdev, mt);
+
+	mt->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0, mt,
+				&mtk_thermal_ops);
+	if (IS_ERR(mt->tzd))
+		goto err_register;
+
+	return 0;
+
+err_register:
+	clk_disable_unprepare(mt->clk_peri_therm);
+
+err_disable_clk_auxadc:
+	clk_disable_unprepare(mt->clk_auxadc);
+
+	return ret;
+}
+
+static int mtk_thermal_remove(struct platform_device *pdev)
+{
+	struct mtk_thermal *mt = platform_get_drvdata(pdev);
+
+	thermal_zone_of_sensor_unregister(&pdev->dev, mt->tzd);
+
+	clk_disable_unprepare(mt->clk_peri_therm);
+	clk_disable_unprepare(mt->clk_auxadc);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_thermal_of_match[] = {
+	{
+		.compatible = "mediatek,mt8173-thermal",
+	}, {
+	},
+};
+
+static struct platform_driver mtk_thermal_driver = {
+	.probe = mtk_thermal_probe,
+	.remove = mtk_thermal_remove,
+	.driver = {
+		.name = THERMAL_NAME,
+		.of_match_table = mtk_thermal_of_match,
+	},
+};
+
+module_platform_driver(mtk_thermal_driver);
+
+MODULE_AUTHOR("Sascha Hauer <s.hauer at pengutronix.de");
+MODULE_AUTHOR("Hanyi Wu <hanyi.wu@mediatek.com>");
+MODULE_DESCRIPTION("Mediatek thermal driver");
+MODULE_LICENSE("GPL v2");
-- 
2.6.2

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eduardo Valentin]

Sascha,

Yeah, sorry for the long delay. I was planing on applying this patch for
the next merge window, but it just came across one point, see below.

On Mon, Nov 30, 2015 at 12:42:32PM +0100, Sascha Hauer wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
> +

<big cut>

> +/*
> + * The MT8173 thermal controller has four banks. Each bank can read up to
> + * four temperature sensors simultaneously. The MT8173 has a total of 5
> + * temperature sensors. We use each bank to measure a certain area of the
> + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple
> + * areas, hence is used in different banks.
> + *
> + * The thermal core only gets the maximum temperature of all banks, so
> + * the bank concept wouldn't be necessary here. However, the SVS (Smart
> + * Voltage Scaling) unit makes its decisions based on the same bank
> + * data, and this indeed needs the temperatures of the individual banks
> + * for making better decisions.
> + */
> +static const struct mtk_thermal_bank_cfg bank_data[] = {
> +	{
> +		.num_sensors = 2,
> +		.sensors = { MT8173_TS2, MT8173_TS3 },
> +	}, {
> +		.num_sensors = 2,
> +		.sensors = { MT8173_TS2, MT8173_TS4 },
> +	}, {
> +		.num_sensors = 3,
> +		.sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> +	}, {
> +		.num_sensors = 1,
> +		.sensors = { MT8173_TS2 },
> +	},
> +};

Why can't we expose all these as thermal zones?

That should remove the policy of computing the maximum from this driver.
Please have a look on the work being done [1] to add grouping and
aggregation of thermal zones. With that in place, you should be a matter
of configuring the grouping and selecting max as the aggregation function,
from the thermal core, instead in the driver. Which should give the
system engineer, more flexibility to compose whatever policy based on
the exposed sensors.

BR,

Eduardo Valentin

[1] - https://lkml.org/lkml/2015/11/25/446

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eduardo Valentin]

Sascha,

Yeah, sorry for the long delay. I was planing on applying this patch for
the next merge window, but it just came across one point, see below.

On Mon, Nov 30, 2015 at 12:42:32PM +0100, Sascha Hauer wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
> +

<big cut>

> +/*
> + * The MT8173 thermal controller has four banks. Each bank can read up to
> + * four temperature sensors simultaneously. The MT8173 has a total of 5
> + * temperature sensors. We use each bank to measure a certain area of the
> + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple
> + * areas, hence is used in different banks.
> + *
> + * The thermal core only gets the maximum temperature of all banks, so
> + * the bank concept wouldn't be necessary here. However, the SVS (Smart
> + * Voltage Scaling) unit makes its decisions based on the same bank
> + * data, and this indeed needs the temperatures of the individual banks
> + * for making better decisions.
> + */
> +static const struct mtk_thermal_bank_cfg bank_data[] = {
> +	{
> +		.num_sensors = 2,
> +		.sensors = { MT8173_TS2, MT8173_TS3 },
> +	}, {
> +		.num_sensors = 2,
> +		.sensors = { MT8173_TS2, MT8173_TS4 },
> +	}, {
> +		.num_sensors = 3,
> +		.sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> +	}, {
> +		.num_sensors = 1,
> +		.sensors = { MT8173_TS2 },
> +	},
> +};

Why can't we expose all these as thermal zones?

That should remove the policy of computing the maximum from this driver.
Please have a look on the work being done [1] to add grouping and
aggregation of thermal zones. With that in place, you should be a matter
of configuring the grouping and selecting max as the aggregation function,
from the thermal core, instead in the driver. Which should give the
system engineer, more flexibility to compose whatever policy based on
the exposed sensors.

BR,

Eduardo Valentin

[1] - https://lkml.org/lkml/2015/11/25/446

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Hi Eduardo,

On Thu, Dec 17, 2015 at 11:33:33AM -0800, Eduardo Valentin wrote:
> Sascha,
> 
> Yeah, sorry for the long delay. I was planing on applying this patch for
> the next merge window, but it just came across one point, see below.
> 
> On Mon, Nov 30, 2015 at 12:42:32PM +0100, Sascha Hauer wrote:
> > This adds support for the Mediatek thermal controller found on MT8173
> > +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
> > +
> 
> <big cut>
> 
> > +/*
> > + * The MT8173 thermal controller has four banks. Each bank can read up to
> > + * four temperature sensors simultaneously. The MT8173 has a total of 5
> > + * temperature sensors. We use each bank to measure a certain area of the
> > + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple
> > + * areas, hence is used in different banks.
> > + *
> > + * The thermal core only gets the maximum temperature of all banks, so
> > + * the bank concept wouldn't be necessary here. However, the SVS (Smart
> > + * Voltage Scaling) unit makes its decisions based on the same bank
> > + * data, and this indeed needs the temperatures of the individual banks
> > + * for making better decisions.
> > + */
> > +static const struct mtk_thermal_bank_cfg bank_data[] = {
> > +	{
> > +		.num_sensors = 2,
> > +		.sensors = { MT8173_TS2, MT8173_TS3 },
> > +	}, {
> > +		.num_sensors = 2,
> > +		.sensors = { MT8173_TS2, MT8173_TS4 },
> > +	}, {
> > +		.num_sensors = 3,
> > +		.sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> > +	}, {
> > +		.num_sensors = 1,
> > +		.sensors = { MT8173_TS2 },
> > +	},
> > +};
> 
> Why can't we expose all these as thermal zones?
> 
> That should remove the policy of computing the maximum from this driver.
> Please have a look on the work being done [1] to add grouping and
> aggregation of thermal zones. With that in place, you should be a matter
> of configuring the grouping and selecting max as the aggregation function,
> from the thermal core, instead in the driver. Which should give the
> system engineer, more flexibility to compose whatever policy based on
> the exposed sensors.

I think the aggregation of thermal zones is quite useful when it comes
to putting different chips together to a system. I am not so sure how
useful it is to expose different thermal zones of a single SoC to the
device tree.
Currently the only control knob we have is the CPU frequency. When any
of the sensors on the SoC gets too hot then the only thing we can do is
to decrease the CPU frequency. This does not leave much space for
configuration in the device tree.
What I need to be able is to attach multiple sensors to one thermal
zone. The aggregation patch series only partly solves that and I think
is inconsistent, but I commented on the series directly.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Hi Eduardo,

On Thu, Dec 17, 2015 at 11:33:33AM -0800, Eduardo Valentin wrote:
> Sascha,
> 
> Yeah, sorry for the long delay. I was planing on applying this patch for
> the next merge window, but it just came across one point, see below.
> 
> On Mon, Nov 30, 2015 at 12:42:32PM +0100, Sascha Hauer wrote:
> > This adds support for the Mediatek thermal controller found on MT8173
> > +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
> > +
> 
> <big cut>
> 
> > +/*
> > + * The MT8173 thermal controller has four banks. Each bank can read up to
> > + * four temperature sensors simultaneously. The MT8173 has a total of 5
> > + * temperature sensors. We use each bank to measure a certain area of the
> > + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple
> > + * areas, hence is used in different banks.
> > + *
> > + * The thermal core only gets the maximum temperature of all banks, so
> > + * the bank concept wouldn't be necessary here. However, the SVS (Smart
> > + * Voltage Scaling) unit makes its decisions based on the same bank
> > + * data, and this indeed needs the temperatures of the individual banks
> > + * for making better decisions.
> > + */
> > +static const struct mtk_thermal_bank_cfg bank_data[] = {
> > +	{
> > +		.num_sensors = 2,
> > +		.sensors = { MT8173_TS2, MT8173_TS3 },
> > +	}, {
> > +		.num_sensors = 2,
> > +		.sensors = { MT8173_TS2, MT8173_TS4 },
> > +	}, {
> > +		.num_sensors = 3,
> > +		.sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> > +	}, {
> > +		.num_sensors = 1,
> > +		.sensors = { MT8173_TS2 },
> > +	},
> > +};
> 
> Why can't we expose all these as thermal zones?
> 
> That should remove the policy of computing the maximum from this driver.
> Please have a look on the work being done [1] to add grouping and
> aggregation of thermal zones. With that in place, you should be a matter
> of configuring the grouping and selecting max as the aggregation function,
> from the thermal core, instead in the driver. Which should give the
> system engineer, more flexibility to compose whatever policy based on
> the exposed sensors.

I think the aggregation of thermal zones is quite useful when it comes
to putting different chips together to a system. I am not so sure how
useful it is to expose different thermal zones of a single SoC to the
device tree.
Currently the only control knob we have is the CPU frequency. When any
of the sensors on the SoC gets too hot then the only thing we can do is
to decrease the CPU frequency. This does not leave much space for
configuration in the device tree.
What I need to be able is to attach multiple sensors to one thermal
zone. The aggregation patch series only partly solves that and I think
is inconsistent, but I commented on the series directly.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Eduardo,

On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> Hi Eduardo,
> 
> > 
> > That should remove the policy of computing the maximum from this driver.
> > Please have a look on the work being done [1] to add grouping and
> > aggregation of thermal zones. With that in place, you should be a matter
> > of configuring the grouping and selecting max as the aggregation function,
> > from the thermal core, instead in the driver. Which should give the
> > system engineer, more flexibility to compose whatever policy based on
> > the exposed sensors.
> 
> I think the aggregation of thermal zones is quite useful when it comes
> to putting different chips together to a system. I am not so sure how
> useful it is to expose different thermal zones of a single SoC to the
> device tree.
> Currently the only control knob we have is the CPU frequency. When any
> of the sensors on the SoC gets too hot then the only thing we can do is
> to decrease the CPU frequency. This does not leave much space for
> configuration in the device tree.
> What I need to be able is to attach multiple sensors to one thermal
> zone. The aggregation patch series only partly solves that and I think
> is inconsistent, but I commented on the series directly.

Any input on this? I really like to get this driver upstream as it is
currently blocking other Mediatek drivers.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Eduardo,

On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> Hi Eduardo,
> 
> > 
> > That should remove the policy of computing the maximum from this driver.
> > Please have a look on the work being done [1] to add grouping and
> > aggregation of thermal zones. With that in place, you should be a matter
> > of configuring the grouping and selecting max as the aggregation function,
> > from the thermal core, instead in the driver. Which should give the
> > system engineer, more flexibility to compose whatever policy based on
> > the exposed sensors.
> 
> I think the aggregation of thermal zones is quite useful when it comes
> to putting different chips together to a system. I am not so sure how
> useful it is to expose different thermal zones of a single SoC to the
> device tree.
> Currently the only control knob we have is the CPU frequency. When any
> of the sensors on the SoC gets too hot then the only thing we can do is
> to decrease the CPU frequency. This does not leave much space for
> configuration in the device tree.
> What I need to be able is to attach multiple sensors to one thermal
> zone. The aggregation patch series only partly solves that and I think
> is inconsistent, but I commented on the series directly.

Any input on this? I really like to get this driver upstream as it is
currently blocking other Mediatek drivers.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eddie Huang]

On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> Eduardo,
> 
> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > Hi Eduardo,
> > 
> > > 
> > > That should remove the policy of computing the maximum from this driver.
> > > Please have a look on the work being done [1] to add grouping and
> > > aggregation of thermal zones. With that in place, you should be a matter
> > > of configuring the grouping and selecting max as the aggregation function,
> > > from the thermal core, instead in the driver. Which should give the
> > > system engineer, more flexibility to compose whatever policy based on
> > > the exposed sensors.
> > 
> > I think the aggregation of thermal zones is quite useful when it comes
> > to putting different chips together to a system. I am not so sure how
> > useful it is to expose different thermal zones of a single SoC to the
> > device tree.
> > Currently the only control knob we have is the CPU frequency. When any
> > of the sensors on the SoC gets too hot then the only thing we can do is
> > to decrease the CPU frequency. This does not leave much space for
> > configuration in the device tree.
> > What I need to be able is to attach multiple sensors to one thermal
> > zone. The aggregation patch series only partly solves that and I think
> > is inconsistent, but I commented on the series directly.
> 
> Any input on this? I really like to get this driver upstream as it is
> currently blocking other Mediatek drivers.
> 

Hi Eduardo,

Do you have any comment about Sascha's response ? We really hope get
your comment since Mediatek thermal driver already reviewed in public
over half years, and we have other patches [0] [1] depend on thermal
driver.

[0]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Regards,
Eddie

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eddie Huang]

On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> Eduardo,
> 
> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > Hi Eduardo,
> > 
> > > 
> > > That should remove the policy of computing the maximum from this driver.
> > > Please have a look on the work being done [1] to add grouping and
> > > aggregation of thermal zones. With that in place, you should be a matter
> > > of configuring the grouping and selecting max as the aggregation function,
> > > from the thermal core, instead in the driver. Which should give the
> > > system engineer, more flexibility to compose whatever policy based on
> > > the exposed sensors.
> > 
> > I think the aggregation of thermal zones is quite useful when it comes
> > to putting different chips together to a system. I am not so sure how
> > useful it is to expose different thermal zones of a single SoC to the
> > device tree.
> > Currently the only control knob we have is the CPU frequency. When any
> > of the sensors on the SoC gets too hot then the only thing we can do is
> > to decrease the CPU frequency. This does not leave much space for
> > configuration in the device tree.
> > What I need to be able is to attach multiple sensors to one thermal
> > zone. The aggregation patch series only partly solves that and I think
> > is inconsistent, but I commented on the series directly.
> 
> Any input on this? I really like to get this driver upstream as it is
> currently blocking other Mediatek drivers.
> 

Hi Eduardo,

Do you have any comment about Sascha's response ? We really hope get
your comment since Mediatek thermal driver already reviewed in public
over half years, and we have other patches [0] [1] depend on thermal
driver.

[0]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Regards,
Eddie

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eddie Huang]

On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> Eduardo,
> 
> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > Hi Eduardo,
> > 
> > > 
> > > That should remove the policy of computing the maximum from this driver.
> > > Please have a look on the work being done [1] to add grouping and
> > > aggregation of thermal zones. With that in place, you should be a matter
> > > of configuring the grouping and selecting max as the aggregation function,
> > > from the thermal core, instead in the driver. Which should give the
> > > system engineer, more flexibility to compose whatever policy based on
> > > the exposed sensors.
> > 
> > I think the aggregation of thermal zones is quite useful when it comes
> > to putting different chips together to a system. I am not so sure how
> > useful it is to expose different thermal zones of a single SoC to the
> > device tree.
> > Currently the only control knob we have is the CPU frequency. When any
> > of the sensors on the SoC gets too hot then the only thing we can do is
> > to decrease the CPU frequency. This does not leave much space for
> > configuration in the device tree.
> > What I need to be able is to attach multiple sensors to one thermal
> > zone. The aggregation patch series only partly solves that and I think
> > is inconsistent, but I commented on the series directly.
> 
> Any input on this? I really like to get this driver upstream as it is
> currently blocking other Mediatek drivers.
> 

Hi Eduardo,

Do you have any comment about Sascha's response ? We really hope get
your comment since Mediatek thermal driver already reviewed in public
over half years, and we have other patches [0] [1] depend on thermal
driver.

[0]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Regards,
Eddie

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

Hi Eduardo, Sascha,

On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>
> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> > Eduardo,
> >
> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > > Hi Eduardo,
> > >
> > > >
> > > > That should remove the policy of computing the maximum from this driver.
> > > > Please have a look on the work being done [1] to add grouping and
> > > > aggregation of thermal zones. With that in place, you should be a matter
> > > > of configuring the grouping and selecting max as the aggregation function,
> > > > from the thermal core, instead in the driver. Which should give the
> > > > system engineer, more flexibility to compose whatever policy based on
> > > > the exposed sensors.
> > >
> > > I think the aggregation of thermal zones is quite useful when it comes
> > > to putting different chips together to a system. I am not so sure how
> > > useful it is to expose different thermal zones of a single SoC to the
> > > device tree.
> > > Currently the only control knob we have is the CPU frequency. When any
> > > of the sensors on the SoC gets too hot then the only thing we can do is
> > > to decrease the CPU frequency. This does not leave much space for
> > > configuration in the device tree.
> > > What I need to be able is to attach multiple sensors to one thermal
> > > zone. The aggregation patch series only partly solves that and I think
> > > is inconsistent, but I commented on the series directly.
> >
> > Any input on this? I really like to get this driver upstream as it is
> > currently blocking other Mediatek drivers.
> >
>
> Hi Eduardo,
>
> Do you have any comment about Sascha's response ? We really hope get
> your comment since Mediatek thermal driver already reviewed in public
> over half years, and we have other patches [0] [1] depend on thermal
> driver.
>
> [0]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Friendly ping on the Mediatek thermal driver.
The "EFUSE" dependency has now landed in v4.5-rc4.
So, AFAICT, the only thing left that may be blocking landing Mediatek
thermal driver is resolution of this discussion about thermal zones.
Can we kindly resolve this soon so we have a chance to land it in v4.6.

Thanks,
-Dan

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

Hi Eduardo, Sascha,

On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>
> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> > Eduardo,
> >
> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > > Hi Eduardo,
> > >
> > > >
> > > > That should remove the policy of computing the maximum from this driver.
> > > > Please have a look on the work being done [1] to add grouping and
> > > > aggregation of thermal zones. With that in place, you should be a matter
> > > > of configuring the grouping and selecting max as the aggregation function,
> > > > from the thermal core, instead in the driver. Which should give the
> > > > system engineer, more flexibility to compose whatever policy based on
> > > > the exposed sensors.
> > >
> > > I think the aggregation of thermal zones is quite useful when it comes
> > > to putting different chips together to a system. I am not so sure how
> > > useful it is to expose different thermal zones of a single SoC to the
> > > device tree.
> > > Currently the only control knob we have is the CPU frequency. When any
> > > of the sensors on the SoC gets too hot then the only thing we can do is
> > > to decrease the CPU frequency. This does not leave much space for
> > > configuration in the device tree.
> > > What I need to be able is to attach multiple sensors to one thermal
> > > zone. The aggregation patch series only partly solves that and I think
> > > is inconsistent, but I commented on the series directly.
> >
> > Any input on this? I really like to get this driver upstream as it is
> > currently blocking other Mediatek drivers.
> >
>
> Hi Eduardo,
>
> Do you have any comment about Sascha's response ? We really hope get
> your comment since Mediatek thermal driver already reviewed in public
> over half years, and we have other patches [0] [1] depend on thermal
> driver.
>
> [0]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Friendly ping on the Mediatek thermal driver.
The "EFUSE" dependency has now landed in v4.5-rc4.
So, AFAICT, the only thing left that may be blocking landing Mediatek
thermal driver is resolution of this discussion about thermal zones.
Can we kindly resolve this soon so we have a chance to land it in v4.6.

Thanks,
-Dan

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

Hi Eduardo, Sascha,

On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>
> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> > Eduardo,
> >
> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > > Hi Eduardo,
> > >
> > > >
> > > > That should remove the policy of computing the maximum from this driver.
> > > > Please have a look on the work being done [1] to add grouping and
> > > > aggregation of thermal zones. With that in place, you should be a matter
> > > > of configuring the grouping and selecting max as the aggregation function,
> > > > from the thermal core, instead in the driver. Which should give the
> > > > system engineer, more flexibility to compose whatever policy based on
> > > > the exposed sensors.
> > >
> > > I think the aggregation of thermal zones is quite useful when it comes
> > > to putting different chips together to a system. I am not so sure how
> > > useful it is to expose different thermal zones of a single SoC to the
> > > device tree.
> > > Currently the only control knob we have is the CPU frequency. When any
> > > of the sensors on the SoC gets too hot then the only thing we can do is
> > > to decrease the CPU frequency. This does not leave much space for
> > > configuration in the device tree.
> > > What I need to be able is to attach multiple sensors to one thermal
> > > zone. The aggregation patch series only partly solves that and I think
> > > is inconsistent, but I commented on the series directly.
> >
> > Any input on this? I really like to get this driver upstream as it is
> > currently blocking other Mediatek drivers.
> >
>
> Hi Eduardo,
>
> Do you have any comment about Sascha's response ? We really hope get
> your comment since Mediatek thermal driver already reviewed in public
> over half years, and we have other patches [0] [1] depend on thermal
> driver.
>
> [0]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Friendly ping on the Mediatek thermal driver.
The "EFUSE" dependency has now landed in v4.5-rc4.
So, AFAICT, the only thing left that may be blocking landing Mediatek
thermal driver is resolution of this discussion about thermal zones.
Can we kindly resolve this soon so we have a chance to land it in v4.6.

Thanks,
-Dan

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Hi Eduardo, Sascha,
>
> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>
>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>> > Eduardo,
>> >
>> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>> > > Hi Eduardo,
>> > >
>> > > >
>> > > > That should remove the policy of computing the maximum from this driver.
>> > > > Please have a look on the work being done [1] to add grouping and
>> > > > aggregation of thermal zones. With that in place, you should be a matter
>> > > > of configuring the grouping and selecting max as the aggregation function,
>> > > > from the thermal core, instead in the driver. Which should give the
>> > > > system engineer, more flexibility to compose whatever policy based on
>> > > > the exposed sensors.
>> > >
>> > > I think the aggregation of thermal zones is quite useful when it comes
>> > > to putting different chips together to a system. I am not so sure how
>> > > useful it is to expose different thermal zones of a single SoC to the
>> > > device tree.
>> > > Currently the only control knob we have is the CPU frequency. When any
>> > > of the sensors on the SoC gets too hot then the only thing we can do is
>> > > to decrease the CPU frequency. This does not leave much space for
>> > > configuration in the device tree.
>> > > What I need to be able is to attach multiple sensors to one thermal
>> > > zone. The aggregation patch series only partly solves that and I think
>> > > is inconsistent, but I commented on the series directly.
>> >
>> > Any input on this? I really like to get this driver upstream as it is
>> > currently blocking other Mediatek drivers.
>> >
>>
>> Hi Eduardo,
>>
>> Do you have any comment about Sascha's response ? We really hope get
>> your comment since Mediatek thermal driver already reviewed in public
>> over half years, and we have other patches [0] [1] depend on thermal
>> driver.
>>
>> [0]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>> [1]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>
> Friendly ping on the Mediatek thermal driver.
> The "EFUSE" dependency has now landed in v4.5-rc4.

Actually, it landed in char-misc-next, not v4.5-rc4.

> So, AFAICT, the only thing left that may be blocking landing Mediatek
> thermal driver is resolution of this discussion about thermal zones.
> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>
> Thanks,
> -Dan

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Hi Eduardo, Sascha,
>
> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>
>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>> > Eduardo,
>> >
>> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>> > > Hi Eduardo,
>> > >
>> > > >
>> > > > That should remove the policy of computing the maximum from this driver.
>> > > > Please have a look on the work being done [1] to add grouping and
>> > > > aggregation of thermal zones. With that in place, you should be a matter
>> > > > of configuring the grouping and selecting max as the aggregation function,
>> > > > from the thermal core, instead in the driver. Which should give the
>> > > > system engineer, more flexibility to compose whatever policy based on
>> > > > the exposed sensors.
>> > >
>> > > I think the aggregation of thermal zones is quite useful when it comes
>> > > to putting different chips together to a system. I am not so sure how
>> > > useful it is to expose different thermal zones of a single SoC to the
>> > > device tree.
>> > > Currently the only control knob we have is the CPU frequency. When any
>> > > of the sensors on the SoC gets too hot then the only thing we can do is
>> > > to decrease the CPU frequency. This does not leave much space for
>> > > configuration in the device tree.
>> > > What I need to be able is to attach multiple sensors to one thermal
>> > > zone. The aggregation patch series only partly solves that and I think
>> > > is inconsistent, but I commented on the series directly.
>> >
>> > Any input on this? I really like to get this driver upstream as it is
>> > currently blocking other Mediatek drivers.
>> >
>>
>> Hi Eduardo,
>>
>> Do you have any comment about Sascha's response ? We really hope get
>> your comment since Mediatek thermal driver already reviewed in public
>> over half years, and we have other patches [0] [1] depend on thermal
>> driver.
>>
>> [0]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>> [1]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>
> Friendly ping on the Mediatek thermal driver.
> The "EFUSE" dependency has now landed in v4.5-rc4.

Actually, it landed in char-misc-next, not v4.5-rc4.

> So, AFAICT, the only thing left that may be blocking landing Mediatek
> thermal driver is resolution of this discussion about thermal zones.
> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>
> Thanks,
> -Dan

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Hi Eduardo, Sascha,
>
> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>
>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>> > Eduardo,
>> >
>> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>> > > Hi Eduardo,
>> > >
>> > > >
>> > > > That should remove the policy of computing the maximum from this driver.
>> > > > Please have a look on the work being done [1] to add grouping and
>> > > > aggregation of thermal zones. With that in place, you should be a matter
>> > > > of configuring the grouping and selecting max as the aggregation function,
>> > > > from the thermal core, instead in the driver. Which should give the
>> > > > system engineer, more flexibility to compose whatever policy based on
>> > > > the exposed sensors.
>> > >
>> > > I think the aggregation of thermal zones is quite useful when it comes
>> > > to putting different chips together to a system. I am not so sure how
>> > > useful it is to expose different thermal zones of a single SoC to the
>> > > device tree.
>> > > Currently the only control knob we have is the CPU frequency. When any
>> > > of the sensors on the SoC gets too hot then the only thing we can do is
>> > > to decrease the CPU frequency. This does not leave much space for
>> > > configuration in the device tree.
>> > > What I need to be able is to attach multiple sensors to one thermal
>> > > zone. The aggregation patch series only partly solves that and I think
>> > > is inconsistent, but I commented on the series directly.
>> >
>> > Any input on this? I really like to get this driver upstream as it is
>> > currently blocking other Mediatek drivers.
>> >
>>
>> Hi Eduardo,
>>
>> Do you have any comment about Sascha's response ? We really hope get
>> your comment since Mediatek thermal driver already reviewed in public
>> over half years, and we have other patches [0] [1] depend on thermal
>> driver.
>>
>> [0]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>> [1]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>
> Friendly ping on the Mediatek thermal driver.
> The "EFUSE" dependency has now landed in v4.5-rc4.

Actually, it landed in char-misc-next, not v4.5-rc4.

> So, AFAICT, the only thing left that may be blocking landing Mediatek
> thermal driver is resolution of this discussion about thermal zones.
> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>
> Thanks,
> -Dan

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Matthias Brugger]

On 15/02/16 03:14, Daniel Kurtz wrote:
> On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> Hi Eduardo, Sascha,
>>
>> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>>
>>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>>>> Eduardo,
>>>>
>>>> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>>>>> Hi Eduardo,
>>>>>
>>>>>>
>>>>>> That should remove the policy of computing the maximum from this driver.
>>>>>> Please have a look on the work being done [1] to add grouping and
>>>>>> aggregation of thermal zones. With that in place, you should be a matter
>>>>>> of configuring the grouping and selecting max as the aggregation function,
>>>>>> from the thermal core, instead in the driver. Which should give the
>>>>>> system engineer, more flexibility to compose whatever policy based on
>>>>>> the exposed sensors.
>>>>>
>>>>> I think the aggregation of thermal zones is quite useful when it comes
>>>>> to putting different chips together to a system. I am not so sure how
>>>>> useful it is to expose different thermal zones of a single SoC to the
>>>>> device tree.
>>>>> Currently the only control knob we have is the CPU frequency. When any
>>>>> of the sensors on the SoC gets too hot then the only thing we can do is
>>>>> to decrease the CPU frequency. This does not leave much space for
>>>>> configuration in the device tree.
>>>>> What I need to be able is to attach multiple sensors to one thermal
>>>>> zone. The aggregation patch series only partly solves that and I think
>>>>> is inconsistent, but I commented on the series directly.
>>>>
>>>> Any input on this? I really like to get this driver upstream as it is
>>>> currently blocking other Mediatek drivers.
>>>>
>>>
>>> Hi Eduardo,
>>>
>>> Do you have any comment about Sascha's response ? We really hope get
>>> your comment since Mediatek thermal driver already reviewed in public
>>> over half years, and we have other patches [0] [1] depend on thermal
>>> driver.
>>>
>>> [0]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>>> [1]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>>
>> Friendly ping on the Mediatek thermal driver.
>> The "EFUSE" dependency has now landed in v4.5-rc4.
>
> Actually, it landed in char-misc-next, not v4.5-rc4.
>
>> So, AFAICT, the only thing left that may be blocking landing Mediatek
>> thermal driver is resolution of this discussion about thermal zones.
>> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>>


I think the problem is, that Eduardo wants to see the hierachical 
thermal zones being used. But there is still a discussion ongoing [1].

[1] https://patchwork.kernel.org/patch/7699971/

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Matthias Brugger]

On 15/02/16 03:14, Daniel Kurtz wrote:
> On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> Hi Eduardo, Sascha,
>>
>> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>>
>>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>>>> Eduardo,
>>>>
>>>> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>>>>> Hi Eduardo,
>>>>>
>>>>>>
>>>>>> That should remove the policy of computing the maximum from this driver.
>>>>>> Please have a look on the work being done [1] to add grouping and
>>>>>> aggregation of thermal zones. With that in place, you should be a matter
>>>>>> of configuring the grouping and selecting max as the aggregation function,
>>>>>> from the thermal core, instead in the driver. Which should give the
>>>>>> system engineer, more flexibility to compose whatever policy based on
>>>>>> the exposed sensors.
>>>>>
>>>>> I think the aggregation of thermal zones is quite useful when it comes
>>>>> to putting different chips together to a system. I am not so sure how
>>>>> useful it is to expose different thermal zones of a single SoC to the
>>>>> device tree.
>>>>> Currently the only control knob we have is the CPU frequency. When any
>>>>> of the sensors on the SoC gets too hot then the only thing we can do is
>>>>> to decrease the CPU frequency. This does not leave much space for
>>>>> configuration in the device tree.
>>>>> What I need to be able is to attach multiple sensors to one thermal
>>>>> zone. The aggregation patch series only partly solves that and I think
>>>>> is inconsistent, but I commented on the series directly.
>>>>
>>>> Any input on this? I really like to get this driver upstream as it is
>>>> currently blocking other Mediatek drivers.
>>>>
>>>
>>> Hi Eduardo,
>>>
>>> Do you have any comment about Sascha's response ? We really hope get
>>> your comment since Mediatek thermal driver already reviewed in public
>>> over half years, and we have other patches [0] [1] depend on thermal
>>> driver.
>>>
>>> [0]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>>> [1]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>>
>> Friendly ping on the Mediatek thermal driver.
>> The "EFUSE" dependency has now landed in v4.5-rc4.
>
> Actually, it landed in char-misc-next, not v4.5-rc4.
>
>> So, AFAICT, the only thing left that may be blocking landing Mediatek
>> thermal driver is resolution of this discussion about thermal zones.
>> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>>


I think the problem is, that Eduardo wants to see the hierachical 
thermal zones being used. But there is still a discussion ongoing [1].

[1] https://patchwork.kernel.org/patch/7699971/

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Matthias Brugger]

On 15/02/16 03:14, Daniel Kurtz wrote:
> On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> Hi Eduardo, Sascha,
>>
>> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>>
>>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>>>> Eduardo,
>>>>
>>>> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>>>>> Hi Eduardo,
>>>>>
>>>>>>
>>>>>> That should remove the policy of computing the maximum from this driver.
>>>>>> Please have a look on the work being done [1] to add grouping and
>>>>>> aggregation of thermal zones. With that in place, you should be a matter
>>>>>> of configuring the grouping and selecting max as the aggregation function,
>>>>>> from the thermal core, instead in the driver. Which should give the
>>>>>> system engineer, more flexibility to compose whatever policy based on
>>>>>> the exposed sensors.
>>>>>
>>>>> I think the aggregation of thermal zones is quite useful when it comes
>>>>> to putting different chips together to a system. I am not so sure how
>>>>> useful it is to expose different thermal zones of a single SoC to the
>>>>> device tree.
>>>>> Currently the only control knob we have is the CPU frequency. When any
>>>>> of the sensors on the SoC gets too hot then the only thing we can do is
>>>>> to decrease the CPU frequency. This does not leave much space for
>>>>> configuration in the device tree.
>>>>> What I need to be able is to attach multiple sensors to one thermal
>>>>> zone. The aggregation patch series only partly solves that and I think
>>>>> is inconsistent, but I commented on the series directly.
>>>>
>>>> Any input on this? I really like to get this driver upstream as it is
>>>> currently blocking other Mediatek drivers.
>>>>
>>>
>>> Hi Eduardo,
>>>
>>> Do you have any comment about Sascha's response ? We really hope get
>>> your comment since Mediatek thermal driver already reviewed in public
>>> over half years, and we have other patches [0] [1] depend on thermal
>>> driver.
>>>
>>> [0]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>>> [1]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>>
>> Friendly ping on the Mediatek thermal driver.
>> The "EFUSE" dependency has now landed in v4.5-rc4.
>
> Actually, it landed in char-misc-next, not v4.5-rc4.
>
>> So, AFAICT, the only thing left that may be blocking landing Mediatek
>> thermal driver is resolution of this discussion about thermal zones.
>> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>>


I think the problem is, that Eduardo wants to see the hierachical 
thermal zones being used. But there is still a discussion ongoing [1].

[1] https://patchwork.kernel.org/patch/7699971/

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> 
> 
> On 15/02/16 03:14, Daniel Kurtz wrote:
> >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> >>Hi Eduardo, Sascha,
> >>
> >>>>Any input on this? I really like to get this driver upstream as it is
> >>>>currently blocking other Mediatek drivers.
> >>>>
> >>>
> >>>Hi Eduardo,
> >>>
> >>>Do you have any comment about Sascha's response ? We really hope get
> >>>your comment since Mediatek thermal driver already reviewed in public
> >>>over half years, and we have other patches [0] [1] depend on thermal
> >>>driver.
> >>>
> >>>[0]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> >>>[1]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> >>
> >>Friendly ping on the Mediatek thermal driver.
> >>The "EFUSE" dependency has now landed in v4.5-rc4.
> >
> >Actually, it landed in char-misc-next, not v4.5-rc4.
> >
> >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> >>thermal driver is resolution of this discussion about thermal zones.
> >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> >>
> 
> 
> I think the problem is, that Eduardo wants to see the hierachical thermal
> zones being used. But there is still a discussion ongoing [1].

It seems the original Author lost interest in the hierarchical thermal
zones. I am not convinced that we need hierarchical thermal zones for
the Mediatek driver since from the five sensors we only need the maximum
temperature (If this ever changes we could still rework it).

Given the current speed of communication I am not willing to add
another, possibly controversal, dependency to an otherwise simple
driver. I am even less willing when concerns like these come after *v12*
of this series.

Eduardo, it would really help to get a word from you.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> 
> 
> On 15/02/16 03:14, Daniel Kurtz wrote:
> >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> >>Hi Eduardo, Sascha,
> >>
> >>>>Any input on this? I really like to get this driver upstream as it is
> >>>>currently blocking other Mediatek drivers.
> >>>>
> >>>
> >>>Hi Eduardo,
> >>>
> >>>Do you have any comment about Sascha's response ? We really hope get
> >>>your comment since Mediatek thermal driver already reviewed in public
> >>>over half years, and we have other patches [0] [1] depend on thermal
> >>>driver.
> >>>
> >>>[0]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> >>>[1]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> >>
> >>Friendly ping on the Mediatek thermal driver.
> >>The "EFUSE" dependency has now landed in v4.5-rc4.
> >
> >Actually, it landed in char-misc-next, not v4.5-rc4.
> >
> >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> >>thermal driver is resolution of this discussion about thermal zones.
> >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> >>
> 
> 
> I think the problem is, that Eduardo wants to see the hierachical thermal
> zones being used. But there is still a discussion ongoing [1].

It seems the original Author lost interest in the hierarchical thermal
zones. I am not convinced that we need hierarchical thermal zones for
the Mediatek driver since from the five sensors we only need the maximum
temperature (If this ever changes we could still rework it).

Given the current speed of communication I am not willing to add
another, possibly controversal, dependency to an otherwise simple
driver. I am even less willing when concerns like these come after *v12*
of this series.

Eduardo, it would really help to get a word from you.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> 
> 
> On 15/02/16 03:14, Daniel Kurtz wrote:
> >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> >>Hi Eduardo, Sascha,
> >>
> >>>>Any input on this? I really like to get this driver upstream as it is
> >>>>currently blocking other Mediatek drivers.
> >>>>
> >>>
> >>>Hi Eduardo,
> >>>
> >>>Do you have any comment about Sascha's response ? We really hope get
> >>>your comment since Mediatek thermal driver already reviewed in public
> >>>over half years, and we have other patches [0] [1] depend on thermal
> >>>driver.
> >>>
> >>>[0]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> >>>[1]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> >>
> >>Friendly ping on the Mediatek thermal driver.
> >>The "EFUSE" dependency has now landed in v4.5-rc4.
> >
> >Actually, it landed in char-misc-next, not v4.5-rc4.
> >
> >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> >>thermal driver is resolution of this discussion about thermal zones.
> >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> >>
> 
> 
> I think the problem is, that Eduardo wants to see the hierachical thermal
> zones being used. But there is still a discussion ongoing [1].

It seems the original Author lost interest in the hierarchical thermal
zones. I am not convinced that we need hierarchical thermal zones for
the Mediatek driver since from the five sensors we only need the maximum
temperature (If this ever changes we could still rework it).

Given the current speed of communication I am not willing to add
another, possibly controversal, dependency to an otherwise simple
driver. I am even less willing when concerns like these come after *v12*
of this series.

Eduardo, it would really help to get a word from you.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Javi Merino]

Hi Sascha,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).

I guess that "the original Author" refers to me.  I haven't lost
interest in the hierarchical thermal zones, I just don't have time to
work on it currently.  I'd like to address your review at some point
in the future and continue working on it.
 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.

I agree.  I don't think we should make this driver depend on the
hierarchical thermal zones series.  When hierarchical thermal zones
get merged we can consider to change the driver to use them but
there's no point in waiting for that to happen.

Cheers,
Javi

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Javi Merino]

Hi Sascha,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).

I guess that "the original Author" refers to me.  I haven't lost
interest in the hierarchical thermal zones, I just don't have time to
work on it currently.  I'd like to address your review at some point
in the future and continue working on it.
 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.

I agree.  I don't think we should make this driver depend on the
hierarchical thermal zones series.  When hierarchical thermal zones
get merged we can consider to change the driver to use them but
there's no point in waiting for that to happen.

Cheers,
Javi

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Javi Merino]

Hi Sascha,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).

I guess that "the original Author" refers to me.  I haven't lost
interest in the hierarchical thermal zones, I just don't have time to
work on it currently.  I'd like to address your review at some point
in the future and continue working on it.
 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.

I agree.  I don't think we should make this driver depend on the
hierarchical thermal zones series.  When hierarchical thermal zones
get merged we can consider to change the driver to use them but
there's no point in waiting for that to happen.

Cheers,
Javi

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eduardo Valentin]

Folks,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > 
> > 
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).
> 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.
> 
> Eduardo, it would really help to get a word from you.

Apologize for the long delays here. In fact I want the hierarchical
support on this driver. But given that it is not really a strong
dependency and the hierarchical support is still an ongoing development,
I don't see why we should not merge this driver.

I also have had the chance to try it out in a board, and seams to work
for me. I am adding to my tree.

Thanks for the perseverance. :-)

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eduardo Valentin]

Folks,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > 
> > 
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).
> 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.
> 
> Eduardo, it would really help to get a word from you.

Apologize for the long delays here. In fact I want the hierarchical
support on this driver. But given that it is not really a strong
dependency and the hierarchical support is still an ongoing development,
I don't see why we should not merge this driver.

I also have had the chance to try it out in a board, and seams to work
for me. I am adding to my tree.

Thanks for the perseverance. :-)

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Eduardo Valentin]

Folks,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > 
> > 
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).
> 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.
> 
> Eduardo, it would really help to get a word from you.

Apologize for the long delays here. In fact I want the hierarchical
support on this driver. But given that it is not really a strong
dependency and the hierarchical support is still an ongoing development,
I don't see why we should not merge this driver.

I also have had the chance to try it out in a board, and seams to work
for me. I am adding to my tree.

Thanks for the perseverance. :-)

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

Hi Sascha,

One nit below that can be fixed up later, or now if you don't plan to
spin this driver to
address Eduardo's feedback...

On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

[snip]

> +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> +{
> +       struct nvmem_cell *cell;
> +       u32 *buf;
> +       size_t len;
> +       int i, ret = 0;
> +
> +       /* Start with default values */
> +       mt->adc_ge = 512;
> +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
> +               mt->vts[i] = 260;
> +       mt->degc_cali = 40;
> +       mt->o_slope = 0;
> +
> +       cell = nvmem_cell_get(dev, "calibration-data");
> +       if (IS_ERR(cell)) {
> +               if (PTR_ERR(cell) == -EPROBE_DEFER)

It is useful to know why the thermal driver is being probe defered, so
I suggest here:
dev_warn(dev, "Waiting for calibration data.\n");

> +                       return PTR_ERR(cell);
> +               return 0;
> +       }

Thanks,
-Dan

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

Hi Sascha,

One nit below that can be fixed up later, or now if you don't plan to
spin this driver to
address Eduardo's feedback...

On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

[snip]

> +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> +{
> +       struct nvmem_cell *cell;
> +       u32 *buf;
> +       size_t len;
> +       int i, ret = 0;
> +
> +       /* Start with default values */
> +       mt->adc_ge = 512;
> +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
> +               mt->vts[i] = 260;
> +       mt->degc_cali = 40;
> +       mt->o_slope = 0;
> +
> +       cell = nvmem_cell_get(dev, "calibration-data");
> +       if (IS_ERR(cell)) {
> +               if (PTR_ERR(cell) == -EPROBE_DEFER)

It is useful to know why the thermal driver is being probe defered, so
I suggest here:
dev_warn(dev, "Waiting for calibration data.\n");

> +                       return PTR_ERR(cell);
> +               return 0;
> +       }

Thanks,
-Dan

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

Hi Sascha,

One nit below that can be fixed up later, or now if you don't plan to
spin this driver to
address Eduardo's feedback...

On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

[snip]

> +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> +{
> +       struct nvmem_cell *cell;
> +       u32 *buf;
> +       size_t len;
> +       int i, ret = 0;
> +
> +       /* Start with default values */
> +       mt->adc_ge = 512;
> +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
> +               mt->vts[i] = 260;
> +       mt->degc_cali = 40;
> +       mt->o_slope = 0;
> +
> +       cell = nvmem_cell_get(dev, "calibration-data");
> +       if (IS_ERR(cell)) {
> +               if (PTR_ERR(cell) == -EPROBE_DEFER)

It is useful to know why the thermal driver is being probe defered, so
I suggest here:
dev_warn(dev, "Waiting for calibration data.\n");

> +                       return PTR_ERR(cell);
> +               return 0;
> +       }

Thanks,
-Dan

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote:
> Hi Sascha,
> 
> One nit below that can be fixed up later, or now if you don't plan to
> spin this driver to
> address Eduardo's feedback...
> 
> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > This adds support for the Mediatek thermal controller found on MT8173
> > and likely other SoCs.
> > The controller is a bit special. It does not have its own ADC, instead
> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> > we need the physical address of the AUXADC. Also it controls a mux
> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> [snip]
> 
> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> > +{
> > +       struct nvmem_cell *cell;
> > +       u32 *buf;
> > +       size_t len;
> > +       int i, ret = 0;
> > +
> > +       /* Start with default values */
> > +       mt->adc_ge = 512;
> > +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
> > +               mt->vts[i] = 260;
> > +       mt->degc_cali = 40;
> > +       mt->o_slope = 0;
> > +
> > +       cell = nvmem_cell_get(dev, "calibration-data");
> > +       if (IS_ERR(cell)) {
> > +               if (PTR_ERR(cell) == -EPROBE_DEFER)
> 
> It is useful to know why the thermal driver is being probe defered, so
> I suggest here:
> dev_warn(dev, "Waiting for calibration data.\n");

The problem with that is that this message is not shown once but
possibly many times and may not even show a problem because in the end
the device may be probed successfully. In this case the last thing you
see from the device is "Waiting for calibration data." and get annoyed
by all this useless noise from the driver.

Of course I agree that this information may be useful in the case you
wonder why your device doesn't show up...

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote:
> Hi Sascha,
> 
> One nit below that can be fixed up later, or now if you don't plan to
> spin this driver to
> address Eduardo's feedback...
> 
> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > This adds support for the Mediatek thermal controller found on MT8173
> > and likely other SoCs.
> > The controller is a bit special. It does not have its own ADC, instead
> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> > we need the physical address of the AUXADC. Also it controls a mux
> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> [snip]
> 
> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> > +{
> > +       struct nvmem_cell *cell;
> > +       u32 *buf;
> > +       size_t len;
> > +       int i, ret = 0;
> > +
> > +       /* Start with default values */
> > +       mt->adc_ge = 512;
> > +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
> > +               mt->vts[i] = 260;
> > +       mt->degc_cali = 40;
> > +       mt->o_slope = 0;
> > +
> > +       cell = nvmem_cell_get(dev, "calibration-data");
> > +       if (IS_ERR(cell)) {
> > +               if (PTR_ERR(cell) == -EPROBE_DEFER)
> 
> It is useful to know why the thermal driver is being probe defered, so
> I suggest here:
> dev_warn(dev, "Waiting for calibration data.\n");

The problem with that is that this message is not shown once but
possibly many times and may not even show a problem because in the end
the device may be probed successfully. In this case the last thing you
see from the device is "Waiting for calibration data." and get annoyed
by all this useless noise from the driver.

Of course I agree that this information may be useful in the case you
wonder why your device doesn't show up...

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote:
> Hi Sascha,
> 
> One nit below that can be fixed up later, or now if you don't plan to
> spin this driver to
> address Eduardo's feedback...
> 
> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > This adds support for the Mediatek thermal controller found on MT8173
> > and likely other SoCs.
> > The controller is a bit special. It does not have its own ADC, instead
> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> > we need the physical address of the AUXADC. Also it controls a mux
> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> [snip]
> 
> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> > +{
> > +       struct nvmem_cell *cell;
> > +       u32 *buf;
> > +       size_t len;
> > +       int i, ret = 0;
> > +
> > +       /* Start with default values */
> > +       mt->adc_ge = 512;
> > +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
> > +               mt->vts[i] = 260;
> > +       mt->degc_cali = 40;
> > +       mt->o_slope = 0;
> > +
> > +       cell = nvmem_cell_get(dev, "calibration-data");
> > +       if (IS_ERR(cell)) {
> > +               if (PTR_ERR(cell) == -EPROBE_DEFER)
> 
> It is useful to know why the thermal driver is being probe defered, so
> I suggest here:
> dev_warn(dev, "Waiting for calibration data.\n");

The problem with that is that this message is not shown once but
possibly many times and may not even show a problem because in the end
the device may be probed successfully. In this case the last thing you
see from the device is "Waiting for calibration data." and get annoyed
by all this useless noise from the driver.

Of course I agree that this information may be useful in the case you
wonder why your device doesn't show up...

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Mon, Jan 4, 2016 at 10:31 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote:
>> Hi Sascha,
>>
>> One nit below that can be fixed up later, or now if you don't plan to
>> spin this driver to
>> address Eduardo's feedback...
>>
>> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > This adds support for the Mediatek thermal controller found on MT8173
>> > and likely other SoCs.
>> > The controller is a bit special. It does not have its own ADC, instead
>> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
>> > we need the physical address of the AUXADC. Also it controls a mux
>> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>> >
>> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> [snip]
>>
>> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
>> > +{
>> > +       struct nvmem_cell *cell;
>> > +       u32 *buf;
>> > +       size_t len;
>> > +       int i, ret = 0;
>> > +
>> > +       /* Start with default values */
>> > +       mt->adc_ge = 512;
>> > +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
>> > +               mt->vts[i] = 260;
>> > +       mt->degc_cali = 40;
>> > +       mt->o_slope = 0;
>> > +
>> > +       cell = nvmem_cell_get(dev, "calibration-data");
>> > +       if (IS_ERR(cell)) {
>> > +               if (PTR_ERR(cell) == -EPROBE_DEFER)
>>
>> It is useful to know why the thermal driver is being probe defered, so
>> I suggest here:
>> dev_warn(dev, "Waiting for calibration data.\n");
>
> The problem with that is that this message is not shown once but
> possibly many times and may not even show a problem because in the end
> the device may be probed successfully. In this case the last thing you
> see from the device is "Waiting for calibration data." and get annoyed
> by all this useless noise from the driver.
>
> Of course I agree that this information may be useful in the case you
> wonder why your device doesn't show up...

The solution for this, then, is:
 dev_dbg()

[PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Mon, Jan 4, 2016 at 10:31 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote:
>> Hi Sascha,
>>
>> One nit below that can be fixed up later, or now if you don't plan to
>> spin this driver to
>> address Eduardo's feedback...
>>
>> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > This adds support for the Mediatek thermal controller found on MT8173
>> > and likely other SoCs.
>> > The controller is a bit special. It does not have its own ADC, instead
>> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
>> > we need the physical address of the AUXADC. Also it controls a mux
>> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>> >
>> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> [snip]
>>
>> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
>> > +{
>> > +       struct nvmem_cell *cell;
>> > +       u32 *buf;
>> > +       size_t len;
>> > +       int i, ret = 0;
>> > +
>> > +       /* Start with default values */
>> > +       mt->adc_ge = 512;
>> > +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
>> > +               mt->vts[i] = 260;
>> > +       mt->degc_cali = 40;
>> > +       mt->o_slope = 0;
>> > +
>> > +       cell = nvmem_cell_get(dev, "calibration-data");
>> > +       if (IS_ERR(cell)) {
>> > +               if (PTR_ERR(cell) == -EPROBE_DEFER)
>>
>> It is useful to know why the thermal driver is being probe defered, so
>> I suggest here:
>> dev_warn(dev, "Waiting for calibration data.\n");
>
> The problem with that is that this message is not shown once but
> possibly many times and may not even show a problem because in the end
> the device may be probed successfully. In this case the last thing you
> see from the device is "Waiting for calibration data." and get annoyed
> by all this useless noise from the driver.
>
> Of course I agree that this information may be useful in the case you
> wonder why your device doesn't show up...

The solution for this, then, is:
 dev_dbg()

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Mon, Jan 4, 2016 at 10:31 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote:
>> Hi Sascha,
>>
>> One nit below that can be fixed up later, or now if you don't plan to
>> spin this driver to
>> address Eduardo's feedback...
>>
>> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > This adds support for the Mediatek thermal controller found on MT8173
>> > and likely other SoCs.
>> > The controller is a bit special. It does not have its own ADC, instead
>> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
>> > we need the physical address of the AUXADC. Also it controls a mux
>> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>> >
>> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> [snip]
>>
>> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
>> > +{
>> > +       struct nvmem_cell *cell;
>> > +       u32 *buf;
>> > +       size_t len;
>> > +       int i, ret = 0;
>> > +
>> > +       /* Start with default values */
>> > +       mt->adc_ge = 512;
>> > +       for (i = 0; i < MT8173_NUM_SENSORS; i++)
>> > +               mt->vts[i] = 260;
>> > +       mt->degc_cali = 40;
>> > +       mt->o_slope = 0;
>> > +
>> > +       cell = nvmem_cell_get(dev, "calibration-data");
>> > +       if (IS_ERR(cell)) {
>> > +               if (PTR_ERR(cell) == -EPROBE_DEFER)
>>
>> It is useful to know why the thermal driver is being probe defered, so
>> I suggest here:
>> dev_warn(dev, "Waiting for calibration data.\n");
>
> The problem with that is that this message is not shown once but
> possibly many times and may not even show a problem because in the end
> the device may be probed successfully. In this case the last thing you
> see from the device is "Waiting for calibration data." and get annoyed
> by all this useless noise from the driver.
>
> Of course I agree that this information may be useful in the case you
> wonder why your device doesn't show up...

The solution for this, then, is:
 dev_dbg()

[PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Sascha Hauer]

This adds the thermal controller and auxadc nodes to the Mediatek MT8173
dtsi file.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 06a1564..e2ddd03 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -277,6 +277,11 @@
 				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
 
+		auxadc: auxadc@11001000 {
+			compatible = "mediatek,mt8173-auxadc";
+			reg = <0 0x11001000 0 0x1000>;
+		};
+
 		uart0: serial@11002000 {
 			compatible = "mediatek,mt8173-uart",
 				     "mediatek,mt6577-uart";
@@ -487,6 +492,18 @@
 			clock-names = "source", "hclk";
 			status = "disabled";
 		};
+
+		thermal: thermal@1100b000 {
+			#thermal-sensor-cells = <0>;
+			compatible = "mediatek,mt8173-thermal";
+			reg = <0 0x1100b000 0 0x1000>;
+			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+			clock-names = "therm", "auxadc";
+			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
+			mediatek,auxadc = <&auxadc>;
+			mediatek,apmixedsys = <&apmixedsys>;
+		};
 	};
 };
 
-- 
2.6.2

[PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Sascha Hauer]

This adds the thermal controller and auxadc nodes to the Mediatek MT8173
dtsi file.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 06a1564..e2ddd03 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -277,6 +277,11 @@
 				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
 
+		auxadc: auxadc at 11001000 {
+			compatible = "mediatek,mt8173-auxadc";
+			reg = <0 0x11001000 0 0x1000>;
+		};
+
 		uart0: serial at 11002000 {
 			compatible = "mediatek,mt8173-uart",
 				     "mediatek,mt6577-uart";
@@ -487,6 +492,18 @@
 			clock-names = "source", "hclk";
 			status = "disabled";
 		};
+
+		thermal: thermal at 1100b000 {
+			#thermal-sensor-cells = <0>;
+			compatible = "mediatek,mt8173-thermal";
+			reg = <0 0x1100b000 0 0x1000>;
+			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+			clock-names = "therm", "auxadc";
+			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
+			mediatek,auxadc = <&auxadc>;
+			mediatek,apmixedsys = <&apmixedsys>;
+		};
 	};
 };
 
-- 
2.6.2

Re: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Matthias Brugger]

Hi Sascha,

On 30/11/15 12:42, Sascha Hauer wrote:
> This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> dtsi file.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 06a1564..e2ddd03 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -277,6 +277,11 @@
>   				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>   		};
>
> +		auxadc: auxadc@11001000 {
> +			compatible = "mediatek,mt8173-auxadc";

Can you please write a small Documentation about the binding.
I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

I can't do it my self, as my datasheet lacks the auxadc registers.

Thanks,
Matthias

> +			reg = <0 0x11001000 0 0x1000>;
> +		};
> +
>   		uart0: serial@11002000 {
>   			compatible = "mediatek,mt8173-uart",
>   				     "mediatek,mt6577-uart";
> @@ -487,6 +492,18 @@
>   			clock-names = "source", "hclk";
>   			status = "disabled";
>   		};
> +
> +		thermal: thermal@1100b000 {
> +			#thermal-sensor-cells = <0>;
> +			compatible = "mediatek,mt8173-thermal";
> +			reg = <0 0x1100b000 0 0x1000>;
> +			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +			clock-names = "therm", "auxadc";
> +			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +			mediatek,auxadc = <&auxadc>;
> +			mediatek,apmixedsys = <&apmixedsys>;
> +		};
>   	};
>   };
>
>

[PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Matthias Brugger]

Hi Sascha,

On 30/11/15 12:42, Sascha Hauer wrote:
> This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> dtsi file.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 06a1564..e2ddd03 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -277,6 +277,11 @@
>   				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>   		};
>
> +		auxadc: auxadc at 11001000 {
> +			compatible = "mediatek,mt8173-auxadc";

Can you please write a small Documentation about the binding.
I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

I can't do it my self, as my datasheet lacks the auxadc registers.

Thanks,
Matthias

> +			reg = <0 0x11001000 0 0x1000>;
> +		};
> +
>   		uart0: serial at 11002000 {
>   			compatible = "mediatek,mt8173-uart",
>   				     "mediatek,mt6577-uart";
> @@ -487,6 +492,18 @@
>   			clock-names = "source", "hclk";
>   			status = "disabled";
>   		};
> +
> +		thermal: thermal at 1100b000 {
> +			#thermal-sensor-cells = <0>;
> +			compatible = "mediatek,mt8173-thermal";
> +			reg = <0 0x1100b000 0 0x1000>;
> +			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +			clock-names = "therm", "auxadc";
> +			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +			mediatek,auxadc = <&auxadc>;
> +			mediatek,apmixedsys = <&apmixedsys>;
> +		};
>   	};
>   };
>
>

Re: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Sascha Hauer]

Hi Matthias,

On Thu, Feb 18, 2016 at 05:18:49PM +0100, Matthias Brugger wrote:
> Hi Sascha,
> 
> On 30/11/15 12:42, Sascha Hauer wrote:
> >This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> >dtsi file.
> >
> >Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> >---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >index 06a1564..e2ddd03 100644
> >--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >@@ -277,6 +277,11 @@
> >  				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >  		};
> >
> >+		auxadc: auxadc@11001000 {
> >+			compatible = "mediatek,mt8173-auxadc";
> 
> Can you please write a small Documentation about the binding.
> I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

Just did that.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Sascha Hauer]

Hi Matthias,

On Thu, Feb 18, 2016 at 05:18:49PM +0100, Matthias Brugger wrote:
> Hi Sascha,
> 
> On 30/11/15 12:42, Sascha Hauer wrote:
> >This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> >dtsi file.
> >
> >Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> >---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >index 06a1564..e2ddd03 100644
> >--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >@@ -277,6 +277,11 @@
> >  				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >  		};
> >
> >+		auxadc: auxadc at 11001000 {
> >+			compatible = "mediatek,mt8173-auxadc";
> 
> Can you please write a small Documentation about the binding.
> I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

Just did that.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Matthias Brugger]

On 30/11/15 12:42, Sascha Hauer wrote:
> This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> dtsi file.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 06a1564..e2ddd03 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -277,6 +277,11 @@
>   				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>   		};
>
> +		auxadc: auxadc@11001000 {
> +			compatible = "mediatek,mt8173-auxadc";
> +			reg = <0 0x11001000 0 0x1000>;
> +		};
> +
>   		uart0: serial@11002000 {
>   			compatible = "mediatek,mt8173-uart",
>   				     "mediatek,mt6577-uart";
> @@ -487,6 +492,18 @@
>   			clock-names = "source", "hclk";
>   			status = "disabled";
>   		};
> +
> +		thermal: thermal@1100b000 {
> +			#thermal-sensor-cells = <0>;
> +			compatible = "mediatek,mt8173-thermal";
> +			reg = <0 0x1100b000 0 0x1000>;
> +			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +			clock-names = "therm", "auxadc";
> +			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +			mediatek,auxadc = <&auxadc>;
> +			mediatek,apmixedsys = <&apmixedsys>;
> +		};
>   	};
>   };
>
>

Applied with the ACK from Eduardo.
Thanks.

[PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Matthias Brugger]

On 30/11/15 12:42, Sascha Hauer wrote:
> This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> dtsi file.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 06a1564..e2ddd03 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -277,6 +277,11 @@
>   				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>   		};
>
> +		auxadc: auxadc at 11001000 {
> +			compatible = "mediatek,mt8173-auxadc";
> +			reg = <0 0x11001000 0 0x1000>;
> +		};
> +
>   		uart0: serial at 11002000 {
>   			compatible = "mediatek,mt8173-uart",
>   				     "mediatek,mt6577-uart";
> @@ -487,6 +492,18 @@
>   			clock-names = "source", "hclk";
>   			status = "disabled";
>   		};
> +
> +		thermal: thermal at 1100b000 {
> +			#thermal-sensor-cells = <0>;
> +			compatible = "mediatek,mt8173-thermal";
> +			reg = <0 0x1100b000 0 0x1000>;
> +			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +			clock-names = "therm", "auxadc";
> +			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +			mediatek,auxadc = <&auxadc>;
> +			mediatek,apmixedsys = <&apmixedsys>;
> +		};
>   	};
>   };
>
>

Applied with the ACK from Eduardo.
Thanks.

Re: [PATCH v12] Add Mediatek thermal support

[Sascha Hauer]

Eduardo,

Ok, to apply this? There seem to be no further comments.

Sascha

On Mon, Nov 30, 2015 at 12:42:30PM +0100, Sascha Hauer wrote:
> This series adds support for the thermal sensors included in the
> MT8173 SoC. Currently only basic temperature reading is supported
> without any interrupt support.
> 
> The cpufreq driver for MT8173 is currently under review, so there's no
> real cooling device available in mainline. Until this is available the
> thermal driver can be tested with the following dts snippet. It creates
> a fake gpio fan and a fake trip point which is so low that it can easily
> be reached with a "cat /dev/zero > /dev/null" on the command line.
> 
> Sascha
> 
> Changes since v11:
> - Fix usage of uninitialized variable gcc didn't warn about
> 
> changes since v10:
> - Some style cleanup
> - Add comment to make clear why we use the sensors in banks even if we
>   currently only use the maximum of all banks
> 
> changes since v9:
> - rebase on v4.3
> - Add support for reading the calibration values from nvmem fuses
> - Only register a single thermal zone instead of four as it seems
>   that's everything needed
> 
> changes since v8:
> - Add commit description to binding patch
> - rebase on v4.3-rc2
> 
> changes since v7:
> - re-add some used defines removed in v5
> - Use MT8173_THERMAL_ZONE_* defines as array indices in static initializers
> 
> changes since v6:
> - remove dot in Hanyi Wus name
> 
> changes since v5:
> - update copyright
> - remove unused defines
> 
> Changes since v4:
> - give calibration constants more meaningful names (offset, slope)
> - Use define instead of 0x00c for register access.
> 
> Changes since v3:
> - add include/dt-bindings/thermal/mt8173.h for to be able to use sensor names
>   in dts files
> - fix disabling wrong clock in error path
> - remove now unused reset-names property from binding document
> - rename MT8173_NUM_BANKS -> MT8173_NUM_ZONES
> - rename MT8173_NUM_SENSING_POINTS -> MT8173_NUM_SENSORS_PER_ZONE
> - rename struct thermal_zone_device *tz -> struct thermal_zone_device *tzd
> 
> Changes since v2:
> - sort #includes alphabetically
> - Add prefix to register defines
> - drop some members from struct mtk_thermal
> - simplify raw_to_mcelsius()
> - add and use more register bit defines
> - use device_reset() instead of devm_reset_control_get()/reset_control_reset()
> - misc other stuff
> 
> Changes since v1:
> - Use "mediatek," prefix for custom properties
> - Drop "thermal: consistently use int for temperatures" dependency
> 
> -------------
> 
> 	fan: gpio_fan {
> 		compatible = "gpio-fan";
> 		gpios = <&pio 24 0>;
> 		gpio-fan,speed-map = <0    0
> 				      4500 1>;
> 		#cooling-cells = <2>;
> 	};
> 
> 	thermal-zones {
> 			cpu_thermal: cpu_thermal {
> 			polling-delay-passive = <1000>; /* milliseconds */
> 			polling-delay = <1000>; /* milliseconds */
> 
> 			thermal-sensors = <&thermal>;
> 
> 			trips {
> 				cpu_passive: cpu_passive {
> 					temperature = <47000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "passive";
> 				};
> 
> 				cpu_crit {
> 					temperature = <90000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "critical";
> 				};
> 			};
> 
> 			cooling-maps {
> 				map0 {
> 					trip = <&cpu_passive>;
> 					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 				};
> 			};
> 		};
> 	};
> 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH v12] Add Mediatek thermal support

[Sascha Hauer]

Eduardo,

Ok, to apply this? There seem to be no further comments.

Sascha

On Mon, Nov 30, 2015 at 12:42:30PM +0100, Sascha Hauer wrote:
> This series adds support for the thermal sensors included in the
> MT8173 SoC. Currently only basic temperature reading is supported
> without any interrupt support.
> 
> The cpufreq driver for MT8173 is currently under review, so there's no
> real cooling device available in mainline. Until this is available the
> thermal driver can be tested with the following dts snippet. It creates
> a fake gpio fan and a fake trip point which is so low that it can easily
> be reached with a "cat /dev/zero > /dev/null" on the command line.
> 
> Sascha
> 
> Changes since v11:
> - Fix usage of uninitialized variable gcc didn't warn about
> 
> changes since v10:
> - Some style cleanup
> - Add comment to make clear why we use the sensors in banks even if we
>   currently only use the maximum of all banks
> 
> changes since v9:
> - rebase on v4.3
> - Add support for reading the calibration values from nvmem fuses
> - Only register a single thermal zone instead of four as it seems
>   that's everything needed
> 
> changes since v8:
> - Add commit description to binding patch
> - rebase on v4.3-rc2
> 
> changes since v7:
> - re-add some used defines removed in v5
> - Use MT8173_THERMAL_ZONE_* defines as array indices in static initializers
> 
> changes since v6:
> - remove dot in Hanyi Wus name
> 
> changes since v5:
> - update copyright
> - remove unused defines
> 
> Changes since v4:
> - give calibration constants more meaningful names (offset, slope)
> - Use define instead of 0x00c for register access.
> 
> Changes since v3:
> - add include/dt-bindings/thermal/mt8173.h for to be able to use sensor names
>   in dts files
> - fix disabling wrong clock in error path
> - remove now unused reset-names property from binding document
> - rename MT8173_NUM_BANKS -> MT8173_NUM_ZONES
> - rename MT8173_NUM_SENSING_POINTS -> MT8173_NUM_SENSORS_PER_ZONE
> - rename struct thermal_zone_device *tz -> struct thermal_zone_device *tzd
> 
> Changes since v2:
> - sort #includes alphabetically
> - Add prefix to register defines
> - drop some members from struct mtk_thermal
> - simplify raw_to_mcelsius()
> - add and use more register bit defines
> - use device_reset() instead of devm_reset_control_get()/reset_control_reset()
> - misc other stuff
> 
> Changes since v1:
> - Use "mediatek," prefix for custom properties
> - Drop "thermal: consistently use int for temperatures" dependency
> 
> -------------
> 
> 	fan: gpio_fan {
> 		compatible = "gpio-fan";
> 		gpios = <&pio 24 0>;
> 		gpio-fan,speed-map = <0    0
> 				      4500 1>;
> 		#cooling-cells = <2>;
> 	};
> 
> 	thermal-zones {
> 			cpu_thermal: cpu_thermal {
> 			polling-delay-passive = <1000>; /* milliseconds */
> 			polling-delay = <1000>; /* milliseconds */
> 
> 			thermal-sensors = <&thermal>;
> 
> 			trips {
> 				cpu_passive: cpu_passive {
> 					temperature = <47000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "passive";
> 				};
> 
> 				cpu_crit {
> 					temperature = <90000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "critical";
> 				};
> 			};
> 
> 			cooling-maps {
> 				map0 {
> 					trip = <&cpu_passive>;
> 					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 				};
> 			};
> 		};
> 	};
> 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v12] Add Mediatek thermal support

[Sascha Hauer]

Eduardo,

Ok, to apply this? There seem to be no further comments.

Sascha

On Mon, Nov 30, 2015 at 12:42:30PM +0100, Sascha Hauer wrote:
> This series adds support for the thermal sensors included in the
> MT8173 SoC. Currently only basic temperature reading is supported
> without any interrupt support.
> 
> The cpufreq driver for MT8173 is currently under review, so there's no
> real cooling device available in mainline. Until this is available the
> thermal driver can be tested with the following dts snippet. It creates
> a fake gpio fan and a fake trip point which is so low that it can easily
> be reached with a "cat /dev/zero > /dev/null" on the command line.
> 
> Sascha
> 
> Changes since v11:
> - Fix usage of uninitialized variable gcc didn't warn about
> 
> changes since v10:
> - Some style cleanup
> - Add comment to make clear why we use the sensors in banks even if we
>   currently only use the maximum of all banks
> 
> changes since v9:
> - rebase on v4.3
> - Add support for reading the calibration values from nvmem fuses
> - Only register a single thermal zone instead of four as it seems
>   that's everything needed
> 
> changes since v8:
> - Add commit description to binding patch
> - rebase on v4.3-rc2
> 
> changes since v7:
> - re-add some used defines removed in v5
> - Use MT8173_THERMAL_ZONE_* defines as array indices in static initializers
> 
> changes since v6:
> - remove dot in Hanyi Wus name
> 
> changes since v5:
> - update copyright
> - remove unused defines
> 
> Changes since v4:
> - give calibration constants more meaningful names (offset, slope)
> - Use define instead of 0x00c for register access.
> 
> Changes since v3:
> - add include/dt-bindings/thermal/mt8173.h for to be able to use sensor names
>   in dts files
> - fix disabling wrong clock in error path
> - remove now unused reset-names property from binding document
> - rename MT8173_NUM_BANKS -> MT8173_NUM_ZONES
> - rename MT8173_NUM_SENSING_POINTS -> MT8173_NUM_SENSORS_PER_ZONE
> - rename struct thermal_zone_device *tz -> struct thermal_zone_device *tzd
> 
> Changes since v2:
> - sort #includes alphabetically
> - Add prefix to register defines
> - drop some members from struct mtk_thermal
> - simplify raw_to_mcelsius()
> - add and use more register bit defines
> - use device_reset() instead of devm_reset_control_get()/reset_control_reset()
> - misc other stuff
> 
> Changes since v1:
> - Use "mediatek," prefix for custom properties
> - Drop "thermal: consistently use int for temperatures" dependency
> 
> -------------
> 
> 	fan: gpio_fan {
> 		compatible = "gpio-fan";
> 		gpios = <&pio 24 0>;
> 		gpio-fan,speed-map = <0    0
> 				      4500 1>;
> 		#cooling-cells = <2>;
> 	};
> 
> 	thermal-zones {
> 			cpu_thermal: cpu_thermal {
> 			polling-delay-passive = <1000>; /* milliseconds */
> 			polling-delay = <1000>; /* milliseconds */
> 
> 			thermal-sensors = <&thermal>;
> 
> 			trips {
> 				cpu_passive: cpu_passive {
> 					temperature = <47000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "passive";
> 				};
> 
> 				cpu_crit {
> 					temperature = <90000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "critical";
> 				};
> 			};
> 
> 			cooling-maps {
> 				map0 {
> 					trip = <&cpu_passive>;
> 					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 				};
> 			};
> 		};
> 	};
> 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v12] Add Mediatek thermal support

[Eduardo Valentin]

On Mon, Dec 14, 2015 at 11:37:39AM +0100, Sascha Hauer wrote:
> Eduardo,
> 
> Ok, to apply this? There seem to be no further comments.

Yeah, sorry for the delay. I will do one more review round, but I dont
see much. So, hopefully should be applied in the coming days.


BR

[PATCH v12] Add Mediatek thermal support

[Eduardo Valentin]

On Mon, Dec 14, 2015 at 11:37:39AM +0100, Sascha Hauer wrote:
> Eduardo,
> 
> Ok, to apply this? There seem to be no further comments.

Yeah, sorry for the delay. I will do one more review round, but I dont
see much. So, hopefully should be applied in the coming days.


BR

[PATCH 1/1] thermal: small style cleanup in mtk_thermal

[Eduardo Valentin]

Remove all checkpatch.pl --strict errors, checks, and warnings.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
---
Sascha,

Add your v12 in my forlinus branch. But also, on top of it
I cleaned the patch further with the following patch.

BR,

Eduardo

 drivers/thermal/mtk_thermal.c | 56 ++++++++++++++++++++++---------------------
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 589a138..3d93b1c 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -78,7 +78,7 @@
 
 #define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
 
-#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
+#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff) << 16)
 #define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
 
 #define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
@@ -108,15 +108,15 @@
 #define MT8173_NUM_SENSORS_PER_ZONE	4
 
 /* Layout of the fuses providing the calibration data */
-#define MT8173_CALIB_BUF0_VALID		(1 << 0)
-#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
-#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
-#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
-#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
-#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
-#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
+#define MT8173_CALIB_BUF0_VALID		BIT(0)
+#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22) & 0x3ff)
+#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17) & 0x1ff)
+#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8) & 0x1ff)
+#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14) & 0x1ff)
+#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1) & 0x3f)
+#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26) & 0x3f)
 
 #define THERMAL_NAME    "mtk-thermal"
 
@@ -136,6 +136,7 @@ struct mtk_thermal {
 
 	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
 
+	/* lock: for getting and putting banks */
 	struct mutex lock;
 
 	/* Calibration values */
@@ -271,11 +272,9 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
 static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
 {
 	struct mtk_thermal *mt = bank->mt;
-	int temp, i, max;
+	int i, temp = INT_MIN, max = INT_MIN;
 	u32 raw;
 
-	temp = max = INT_MIN;
-
 	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
 		raw = readl(mt->thermal_base + sensing_points[i].msr);
 
@@ -322,7 +321,7 @@ static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
 };
 
 static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
-		u32 apmixed_phys_base, u32 auxadc_phys_base)
+				  u32 apmixed_phys_base, u32 auxadc_phys_base)
 {
 	struct mtk_thermal_bank *bank = &mt->banks[num];
 	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
@@ -346,7 +345,7 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
 
 	/* poll is set to 10u */
 	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
-			mt->thermal_base + TEMP_AHBPOLL);
+	       mt->thermal_base + TEMP_AHBPOLL);
 
 	/* temperature sampling control, 1 sample */
 	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
@@ -375,49 +374,50 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
 
 	/* AHB address for auxadc mux selection */
 	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
-			mt->thermal_base + TEMP_ADCMUXADDR);
+	       mt->thermal_base + TEMP_ADCMUXADDR);
 
 	/* AHB address for pnp sensor mux selection */
 	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
-			mt->thermal_base + TEMP_PNPMUXADDR);
+	       mt->thermal_base + TEMP_PNPMUXADDR);
 
 	/* AHB value for auxadc enable */
 	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
 
 	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
 	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
-			mt->thermal_base + TEMP_ADCENADDR);
+	       mt->thermal_base + TEMP_ADCENADDR);
 
 	/* AHB address for auxadc valid bit */
 	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
-			mt->thermal_base + TEMP_ADCVALIDADDR);
+	       mt->thermal_base + TEMP_ADCVALIDADDR);
 
 	/* AHB address for auxadc voltage output */
 	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
-			mt->thermal_base + TEMP_ADCVOLTADDR);
+	       mt->thermal_base + TEMP_ADCVOLTADDR);
 
 	/* read valid & voltage are at the same register */
 	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
 
 	/* indicate where the valid bit is */
 	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
-			mt->thermal_base + TEMP_ADCVALIDMASK);
+	       mt->thermal_base + TEMP_ADCVALIDMASK);
 
 	/* no shift */
 	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
 
 	/* enable auxadc mux write transaction */
 	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
-			mt->thermal_base + TEMP_ADCWRITECTRL);
+	       mt->thermal_base + TEMP_ADCWRITECTRL);
 
 	for (i = 0; i < cfg->num_sensors; i++)
 		writel(sensor_mux_values[cfg->sensors[i]],
-				mt->thermal_base + sensing_points[i].adcpnp);
+		       mt->thermal_base + sensing_points[i].adcpnp);
 
 	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
 
-	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
-			mt->thermal_base + TEMP_ADCWRITECTRL);
+	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE |
+	       TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+	       mt->thermal_base + TEMP_ADCWRITECTRL);
 
 	mtk_thermal_put_bank(bank);
 }
@@ -434,7 +434,8 @@ static u64 of_get_phys_base(struct device_node *np)
 	return of_translate_address(np, regaddr_p);
 }
 
-static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
+static int mtk_thermal_get_calibration_data(struct device *dev,
+					    struct mtk_thermal *mt)
 {
 	struct nvmem_cell *cell;
 	u32 *buf;
@@ -567,7 +568,8 @@ static int mtk_thermal_probe(struct platform_device *pdev)
 	}
 
 	for (i = 0; i < MT8173_NUM_ZONES; i++)
-		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
+		mtk_thermal_init_bank(mt, i, apmixed_phys_base,
+				      auxadc_phys_base);
 
 	platform_set_drvdata(pdev, mt);
 
-- 
2.1.4

[PATCH 1/1] thermal: small style cleanup in mtk_thermal

[Eduardo Valentin]

Remove all checkpatch.pl --strict errors, checks, and warnings.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-pm at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mediatek at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
---
Sascha,

Add your v12 in my forlinus branch. But also, on top of it
I cleaned the patch further with the following patch.

BR,

Eduardo

 drivers/thermal/mtk_thermal.c | 56 ++++++++++++++++++++++---------------------
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 589a138..3d93b1c 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -78,7 +78,7 @@
 
 #define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
 
-#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
+#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff) << 16)
 #define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
 
 #define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
@@ -108,15 +108,15 @@
 #define MT8173_NUM_SENSORS_PER_ZONE	4
 
 /* Layout of the fuses providing the calibration data */
-#define MT8173_CALIB_BUF0_VALID		(1 << 0)
-#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
-#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
-#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
-#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
-#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
-#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
+#define MT8173_CALIB_BUF0_VALID		BIT(0)
+#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22) & 0x3ff)
+#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17) & 0x1ff)
+#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8) & 0x1ff)
+#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14) & 0x1ff)
+#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1) & 0x3f)
+#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26) & 0x3f)
 
 #define THERMAL_NAME    "mtk-thermal"
 
@@ -136,6 +136,7 @@ struct mtk_thermal {
 
 	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
 
+	/* lock: for getting and putting banks */
 	struct mutex lock;
 
 	/* Calibration values */
@@ -271,11 +272,9 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
 static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
 {
 	struct mtk_thermal *mt = bank->mt;
-	int temp, i, max;
+	int i, temp = INT_MIN, max = INT_MIN;
 	u32 raw;
 
-	temp = max = INT_MIN;
-
 	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
 		raw = readl(mt->thermal_base + sensing_points[i].msr);
 
@@ -322,7 +321,7 @@ static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
 };
 
 static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
-		u32 apmixed_phys_base, u32 auxadc_phys_base)
+				  u32 apmixed_phys_base, u32 auxadc_phys_base)
 {
 	struct mtk_thermal_bank *bank = &mt->banks[num];
 	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
@@ -346,7 +345,7 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
 
 	/* poll is set to 10u */
 	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
-			mt->thermal_base + TEMP_AHBPOLL);
+	       mt->thermal_base + TEMP_AHBPOLL);
 
 	/* temperature sampling control, 1 sample */
 	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
@@ -375,49 +374,50 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
 
 	/* AHB address for auxadc mux selection */
 	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
-			mt->thermal_base + TEMP_ADCMUXADDR);
+	       mt->thermal_base + TEMP_ADCMUXADDR);
 
 	/* AHB address for pnp sensor mux selection */
 	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
-			mt->thermal_base + TEMP_PNPMUXADDR);
+	       mt->thermal_base + TEMP_PNPMUXADDR);
 
 	/* AHB value for auxadc enable */
 	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
 
 	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
 	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
-			mt->thermal_base + TEMP_ADCENADDR);
+	       mt->thermal_base + TEMP_ADCENADDR);
 
 	/* AHB address for auxadc valid bit */
 	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
-			mt->thermal_base + TEMP_ADCVALIDADDR);
+	       mt->thermal_base + TEMP_ADCVALIDADDR);
 
 	/* AHB address for auxadc voltage output */
 	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
-			mt->thermal_base + TEMP_ADCVOLTADDR);
+	       mt->thermal_base + TEMP_ADCVOLTADDR);
 
 	/* read valid & voltage are at the same register */
 	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
 
 	/* indicate where the valid bit is */
 	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
-			mt->thermal_base + TEMP_ADCVALIDMASK);
+	       mt->thermal_base + TEMP_ADCVALIDMASK);
 
 	/* no shift */
 	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
 
 	/* enable auxadc mux write transaction */
 	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
-			mt->thermal_base + TEMP_ADCWRITECTRL);
+	       mt->thermal_base + TEMP_ADCWRITECTRL);
 
 	for (i = 0; i < cfg->num_sensors; i++)
 		writel(sensor_mux_values[cfg->sensors[i]],
-				mt->thermal_base + sensing_points[i].adcpnp);
+		       mt->thermal_base + sensing_points[i].adcpnp);
 
 	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
 
-	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
-			mt->thermal_base + TEMP_ADCWRITECTRL);
+	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE |
+	       TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+	       mt->thermal_base + TEMP_ADCWRITECTRL);
 
 	mtk_thermal_put_bank(bank);
 }
@@ -434,7 +434,8 @@ static u64 of_get_phys_base(struct device_node *np)
 	return of_translate_address(np, regaddr_p);
 }
 
-static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
+static int mtk_thermal_get_calibration_data(struct device *dev,
+					    struct mtk_thermal *mt)
 {
 	struct nvmem_cell *cell;
 	u32 *buf;
@@ -567,7 +568,8 @@ static int mtk_thermal_probe(struct platform_device *pdev)
 	}
 
 	for (i = 0; i < MT8173_NUM_ZONES; i++)
-		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
+		mtk_thermal_init_bank(mt, i, apmixed_phys_base,
+				      auxadc_phys_base);
 
 	platform_set_drvdata(pdev, mt);
 
-- 
2.1.4

Re: [PATCH 1/1] thermal: small style cleanup in mtk_thermal

[Matthias Brugger]

On 18/02/16 16:50, Eduardo Valentin wrote:
> Remove all checkpatch.pl --strict errors, checks, and warnings.
>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
> ---

Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>

> Sascha,
>
> Add your v12 in my forlinus branch. But also, on top of it
> I cleaned the patch further with the following patch.
>
> BR,
>
> Eduardo
>
>   drivers/thermal/mtk_thermal.c | 56 ++++++++++++++++++++++---------------------
>   1 file changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 589a138..3d93b1c 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -78,7 +78,7 @@
>
>   #define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
>
> -#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
> +#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff) << 16)
>   #define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
>
>   #define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
> @@ -108,15 +108,15 @@
>   #define MT8173_NUM_SENSORS_PER_ZONE	4
>
>   /* Layout of the fuses providing the calibration data */
> -#define MT8173_CALIB_BUF0_VALID		(1 << 0)
> -#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
> -#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
> -#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
> -#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
> -#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
> -#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
> -#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
> -#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
> +#define MT8173_CALIB_BUF0_VALID		BIT(0)
> +#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22) & 0x3ff)
> +#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17) & 0x1ff)
> +#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8) & 0x1ff)
> +#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0) & 0x1ff)
> +#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23) & 0x1ff)
> +#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14) & 0x1ff)
> +#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1) & 0x3f)
> +#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26) & 0x3f)
>
>   #define THERMAL_NAME    "mtk-thermal"
>
> @@ -136,6 +136,7 @@ struct mtk_thermal {
>
>   	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
>
> +	/* lock: for getting and putting banks */
>   	struct mutex lock;
>
>   	/* Calibration values */
> @@ -271,11 +272,9 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>   static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>   {
>   	struct mtk_thermal *mt = bank->mt;
> -	int temp, i, max;
> +	int i, temp = INT_MIN, max = INT_MIN;
>   	u32 raw;
>
> -	temp = max = INT_MIN;
> -
>   	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
>   		raw = readl(mt->thermal_base + sensing_points[i].msr);
>
> @@ -322,7 +321,7 @@ static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
>   };
>
>   static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
> -		u32 apmixed_phys_base, u32 auxadc_phys_base)
> +				  u32 apmixed_phys_base, u32 auxadc_phys_base)
>   {
>   	struct mtk_thermal_bank *bank = &mt->banks[num];
>   	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
> @@ -346,7 +345,7 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>
>   	/* poll is set to 10u */
>   	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
> -			mt->thermal_base + TEMP_AHBPOLL);
> +	       mt->thermal_base + TEMP_AHBPOLL);
>
>   	/* temperature sampling control, 1 sample */
>   	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
> @@ -375,49 +374,50 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>
>   	/* AHB address for auxadc mux selection */
>   	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
> -			mt->thermal_base + TEMP_ADCMUXADDR);
> +	       mt->thermal_base + TEMP_ADCMUXADDR);
>
>   	/* AHB address for pnp sensor mux selection */
>   	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
> -			mt->thermal_base + TEMP_PNPMUXADDR);
> +	       mt->thermal_base + TEMP_PNPMUXADDR);
>
>   	/* AHB value for auxadc enable */
>   	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
>
>   	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
>   	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
> -			mt->thermal_base + TEMP_ADCENADDR);
> +	       mt->thermal_base + TEMP_ADCENADDR);
>
>   	/* AHB address for auxadc valid bit */
>   	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
> -			mt->thermal_base + TEMP_ADCVALIDADDR);
> +	       mt->thermal_base + TEMP_ADCVALIDADDR);
>
>   	/* AHB address for auxadc voltage output */
>   	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
> -			mt->thermal_base + TEMP_ADCVOLTADDR);
> +	       mt->thermal_base + TEMP_ADCVOLTADDR);
>
>   	/* read valid & voltage are at the same register */
>   	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
>
>   	/* indicate where the valid bit is */
>   	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
> -			mt->thermal_base + TEMP_ADCVALIDMASK);
> +	       mt->thermal_base + TEMP_ADCVALIDMASK);
>
>   	/* no shift */
>   	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
>
>   	/* enable auxadc mux write transaction */
>   	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> -			mt->thermal_base + TEMP_ADCWRITECTRL);
> +	       mt->thermal_base + TEMP_ADCWRITECTRL);
>
>   	for (i = 0; i < cfg->num_sensors; i++)
>   		writel(sensor_mux_values[cfg->sensors[i]],
> -				mt->thermal_base + sensing_points[i].adcpnp);
> +		       mt->thermal_base + sensing_points[i].adcpnp);
>
>   	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
>
> -	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> -			mt->thermal_base + TEMP_ADCWRITECTRL);
> +	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE |
> +	       TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> +	       mt->thermal_base + TEMP_ADCWRITECTRL);
>
>   	mtk_thermal_put_bank(bank);
>   }
> @@ -434,7 +434,8 @@ static u64 of_get_phys_base(struct device_node *np)
>   	return of_translate_address(np, regaddr_p);
>   }
>
> -static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> +static int mtk_thermal_get_calibration_data(struct device *dev,
> +					    struct mtk_thermal *mt)
>   {
>   	struct nvmem_cell *cell;
>   	u32 *buf;
> @@ -567,7 +568,8 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>   	}
>
>   	for (i = 0; i < MT8173_NUM_ZONES; i++)
> -		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
> +		mtk_thermal_init_bank(mt, i, apmixed_phys_base,
> +				      auxadc_phys_base);
>
>   	platform_set_drvdata(pdev, mt);
>
>

[PATCH 1/1] thermal: small style cleanup in mtk_thermal

[Matthias Brugger]

On 18/02/16 16:50, Eduardo Valentin wrote:
> Remove all checkpatch.pl --strict errors, checks, and warnings.
>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: linux-pm at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mediatek at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
> ---

Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>

> Sascha,
>
> Add your v12 in my forlinus branch. But also, on top of it
> I cleaned the patch further with the following patch.
>
> BR,
>
> Eduardo
>
>   drivers/thermal/mtk_thermal.c | 56 ++++++++++++++++++++++---------------------
>   1 file changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 589a138..3d93b1c 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -78,7 +78,7 @@
>
>   #define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
>
> -#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
> +#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff) << 16)
>   #define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
>
>   #define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
> @@ -108,15 +108,15 @@
>   #define MT8173_NUM_SENSORS_PER_ZONE	4
>
>   /* Layout of the fuses providing the calibration data */
> -#define MT8173_CALIB_BUF0_VALID		(1 << 0)
> -#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
> -#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
> -#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
> -#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
> -#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
> -#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
> -#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
> -#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
> +#define MT8173_CALIB_BUF0_VALID		BIT(0)
> +#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22) & 0x3ff)
> +#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17) & 0x1ff)
> +#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8) & 0x1ff)
> +#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0) & 0x1ff)
> +#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23) & 0x1ff)
> +#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14) & 0x1ff)
> +#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1) & 0x3f)
> +#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26) & 0x3f)
>
>   #define THERMAL_NAME    "mtk-thermal"
>
> @@ -136,6 +136,7 @@ struct mtk_thermal {
>
>   	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
>
> +	/* lock: for getting and putting banks */
>   	struct mutex lock;
>
>   	/* Calibration values */
> @@ -271,11 +272,9 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>   static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>   {
>   	struct mtk_thermal *mt = bank->mt;
> -	int temp, i, max;
> +	int i, temp = INT_MIN, max = INT_MIN;
>   	u32 raw;
>
> -	temp = max = INT_MIN;
> -
>   	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
>   		raw = readl(mt->thermal_base + sensing_points[i].msr);
>
> @@ -322,7 +321,7 @@ static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
>   };
>
>   static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
> -		u32 apmixed_phys_base, u32 auxadc_phys_base)
> +				  u32 apmixed_phys_base, u32 auxadc_phys_base)
>   {
>   	struct mtk_thermal_bank *bank = &mt->banks[num];
>   	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
> @@ -346,7 +345,7 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>
>   	/* poll is set to 10u */
>   	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
> -			mt->thermal_base + TEMP_AHBPOLL);
> +	       mt->thermal_base + TEMP_AHBPOLL);
>
>   	/* temperature sampling control, 1 sample */
>   	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
> @@ -375,49 +374,50 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>
>   	/* AHB address for auxadc mux selection */
>   	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
> -			mt->thermal_base + TEMP_ADCMUXADDR);
> +	       mt->thermal_base + TEMP_ADCMUXADDR);
>
>   	/* AHB address for pnp sensor mux selection */
>   	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
> -			mt->thermal_base + TEMP_PNPMUXADDR);
> +	       mt->thermal_base + TEMP_PNPMUXADDR);
>
>   	/* AHB value for auxadc enable */
>   	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
>
>   	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
>   	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
> -			mt->thermal_base + TEMP_ADCENADDR);
> +	       mt->thermal_base + TEMP_ADCENADDR);
>
>   	/* AHB address for auxadc valid bit */
>   	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
> -			mt->thermal_base + TEMP_ADCVALIDADDR);
> +	       mt->thermal_base + TEMP_ADCVALIDADDR);
>
>   	/* AHB address for auxadc voltage output */
>   	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
> -			mt->thermal_base + TEMP_ADCVOLTADDR);
> +	       mt->thermal_base + TEMP_ADCVOLTADDR);
>
>   	/* read valid & voltage are at the same register */
>   	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
>
>   	/* indicate where the valid bit is */
>   	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
> -			mt->thermal_base + TEMP_ADCVALIDMASK);
> +	       mt->thermal_base + TEMP_ADCVALIDMASK);
>
>   	/* no shift */
>   	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
>
>   	/* enable auxadc mux write transaction */
>   	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> -			mt->thermal_base + TEMP_ADCWRITECTRL);
> +	       mt->thermal_base + TEMP_ADCWRITECTRL);
>
>   	for (i = 0; i < cfg->num_sensors; i++)
>   		writel(sensor_mux_values[cfg->sensors[i]],
> -				mt->thermal_base + sensing_points[i].adcpnp);
> +		       mt->thermal_base + sensing_points[i].adcpnp);
>
>   	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
>
> -	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> -			mt->thermal_base + TEMP_ADCWRITECTRL);
> +	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE |
> +	       TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> +	       mt->thermal_base + TEMP_ADCWRITECTRL);
>
>   	mtk_thermal_put_bank(bank);
>   }
> @@ -434,7 +434,8 @@ static u64 of_get_phys_base(struct device_node *np)
>   	return of_translate_address(np, regaddr_p);
>   }
>
> -static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> +static int mtk_thermal_get_calibration_data(struct device *dev,
> +					    struct mtk_thermal *mt)
>   {
>   	struct nvmem_cell *cell;
>   	u32 *buf;
> @@ -567,7 +568,8 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>   	}
>
>   	for (i = 0; i < MT8173_NUM_ZONES; i++)
> -		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
> +		mtk_thermal_init_bank(mt, i, apmixed_phys_base,
> +				      auxadc_phys_base);
>
>   	platform_set_drvdata(pdev, mt);
>
>

Re: [PATCH v12] Add Mediatek thermal support

[Eduardo Valentin]

On Mon, Nov 30, 2015 at 12:42:30PM +0100, Sascha Hauer wrote:
> This series adds support for the thermal sensors included in the
> MT8173 SoC. Currently only basic temperature reading is supported
> without any interrupt support.
> 

Merged v12.

> 
> 	fan: gpio_fan {
> 		compatible = "gpio-fan";
> 		gpios = <&pio 24 0>;
> 		gpio-fan,speed-map = <0    0
> 				      4500 1>;
> 		#cooling-cells = <2>;
> 	};
> 
> 	thermal-zones {
> 			cpu_thermal: cpu_thermal {
> 			polling-delay-passive = <1000>; /* milliseconds */
> 			polling-delay = <1000>; /* milliseconds */
> 
> 			thermal-sensors = <&thermal>;
> 
> 			trips {
> 				cpu_passive: cpu_passive {
> 					temperature = <47000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "passive";
> 				};
> 
> 				cpu_crit {
> 					temperature = <90000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "critical";
> 				};
> 			};
> 
> 			cooling-maps {
> 				map0 {
> 					trip = <&cpu_passive>;
> 					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 				};
> 			};
> 		};
> 	};

But, as usual, the dt changes go via your machine tree.

You may add my 
Acked-by: Eduardo Valentin <edubezval@gmail.com>

in your DT patch.

> 

[PATCH v12] Add Mediatek thermal support

[Eduardo Valentin]

On Mon, Nov 30, 2015 at 12:42:30PM +0100, Sascha Hauer wrote:
> This series adds support for the thermal sensors included in the
> MT8173 SoC. Currently only basic temperature reading is supported
> without any interrupt support.
> 

Merged v12.

> 
> 	fan: gpio_fan {
> 		compatible = "gpio-fan";
> 		gpios = <&pio 24 0>;
> 		gpio-fan,speed-map = <0    0
> 				      4500 1>;
> 		#cooling-cells = <2>;
> 	};
> 
> 	thermal-zones {
> 			cpu_thermal: cpu_thermal {
> 			polling-delay-passive = <1000>; /* milliseconds */
> 			polling-delay = <1000>; /* milliseconds */
> 
> 			thermal-sensors = <&thermal>;
> 
> 			trips {
> 				cpu_passive: cpu_passive {
> 					temperature = <47000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "passive";
> 				};
> 
> 				cpu_crit {
> 					temperature = <90000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "critical";
> 				};
> 			};
> 
> 			cooling-maps {
> 				map0 {
> 					trip = <&cpu_passive>;
> 					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 				};
> 			};
> 		};
> 	};

But, as usual, the dt changes go via your machine tree.

You may add my 
Acked-by: Eduardo Valentin <edubezval@gmail.com>

in your DT patch.

>