da9061: DA9061 driver submission

From: Steve Twiss <[email protected]>

Extend existing DA9062 binding information to include the DA9061 PMIC for MFD core and regulators.

Add a da9062-onkey link to the existing onkey binding file.

Add a da9062-thermal link to the new temperature monitoring binding file.

Delete the da9062-watchdog section and replace it with a link to the new DA9061/62 binding information file.

Acked-by Rob Herring <[email protected]>

Signed-off-by Steve Twiss <[email protected]>

---
This patch applies against linux-next and v4.11-rc3

v6 -> v7
- NO CODE CHANGE

v5 -> v6
- NO CODE CHANGE
- Rebased from v4.9 to v4.11-rc3

v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9

v3 -> v4
- Patch renamed from [PATCH V3 4/9] to [PATCH V4 3/8]
- Remove double newline spacing in text file
- Added Acked-by Rob Herring

v2 -> v3
- Patch renamed from [PATCH V2 04/10] to [PATCH V3 4/9]
- Ensure binding description concentrates on the device not the device driver
- Separate the DA9061 and DA9062 sub-device tables to distinguish the difference between the two devices
- Update the commit message to describe this change
- Add e-mail information about associated patches from this set without describing them as being explicitly dependent on this binding

v1 -> v2
- Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these changes were made to fix checkpatch warnings caused by the patch set dependency order

Hi,

Added an Ack from Rob Herring for the PATCH V3 version.

As previously:
Other information:
The device driver from this patch set (associated with this binding) is

- [PATCH V5 4/8] mfd: da9061: MFD core support

and also the following binding file changes:

- Binding for onkey (already applied by Dmitry Torokhov)
- [PATCH V5 1/8] Binding for watchdog
- [PATCH V5 2/8] Binding for thermal

Regards,
Steve Twiss, Dialog Semiconductor

 Documentation/devicetree/bindings/mfd/da9062.txt | 49 +++++++++++++++++-------
 1 file changed, 36 insertions(+), 13 deletions(-)

Documentation/devicetree/bindings/mfd/da9062.txt +36 -13

index 38802b5..c0a418c 100644
@@ -1,22 +1,39 @@
 * Dialog DA9062 Power Management Integrated Circuit (PMIC)
 
-DA9062 consists of a large and varied group of sub-devices:
+Product information for the DA9062 and DA9061 devices can be found here:
+- http://www.dialog-semiconductor.com/products/da9062
+- http://www.dialog-semiconductor.com/products/da9061
+
+The DA9062 PMIC consists of:
 
 Device                   Supply Names    Description
 ------                   ------------    -----------
 da9062-regulator        :               : LDOs & BUCKs
 da9062-rtc              :               : Real-Time Clock
+da9062-onkey            :               : On Key
+da9062-watchdog         :               : Watchdog Timer
+da9062-thermal          :               : Thermal
+
+The DA9061 PMIC consists of:
+
+Device                   Supply Names    Description
+------                   ------------    -----------
+da9062-regulator        :               : LDOs & BUCKs
+da9062-onkey            :               : On Key
 da9062-watchdog         :               : Watchdog Timer
+da9062-thermal          :               : Thermal
 
 ======
 
 Required properties:
 
-- compatible : Should be "dlg,da9062".
+- compatible : Should be
+    "dlg,da9062" for DA9062
+    "dlg,da9061" for DA9061
 - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
   modified to match the chip's OTP settings).
 - interrupt-parent : Specifies the reference to the interrupt controller for
-  the DA9062.
+  the DA9062 or DA9061.
 - interrupts : IRQ line information.
 - interrupt-controller
 

@@ -25,8 +42,8 @@ further information on IRQ bindings.
 
 Sub-nodes:
 
-- regulators : This node defines the settings for the LDOs and BUCKs. The
-  DA9062 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+  The DA9062 regulators are bound using their names listed below:
 
     buck1    : BUCK_1
     buck2    : BUCK_2

@@ -37,19 +54,29 @@ Sub-nodes:
     ldo3     : LDO_3
     ldo4     : LDO_4
 
+  The DA9061 regulators are bound using their names listed below:
+
+    buck1    : BUCK_1
+    buck2    : BUCK_2
+    buck3    : BUCK_3
+    ldo1     : LDO_1
+    ldo2     : LDO_2
+    ldo3     : LDO_3
+    ldo4     : LDO_4
+
   The component follows the standard regulator framework and the bindings
   details of individual regulator device can be found in:
   Documentation/devicetree/bindings/regulator/regulator.txt
 
-
 - rtc : This node defines settings required for the Real-Time Clock associated
   with the DA9062. There are currently no entries in this binding, however
   compatible = "dlg,da9062-rtc" should be added if a node is created.
 
-- watchdog: This node defines the settings for the watchdog driver associated
-  with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
-  if a node is created.
+- onkey : See ../input/da9062-onkey.txt
+
+- watchdog: See ../watchdog/da9062-watchdog.txt
 
+- thermal : See ../thermal/da9062-thermal.txt
 
 Example:
 

@@ -64,10 +91,6 @@ Example:
 			compatible = "dlg,da9062-rtc";
 		};
 
-		watchdog {
-			compatible = "dlg,da9062-watchdog";
-		};
-
 		regulators {
 			DA9062_BUCK1: buck1 {
 				regulator-name = "BUCK1";

From: Steve Twiss <[email protected]>

MFD support for DA9061 is provided as part of the DA9062 device driver.

The registers header file adds two new chip variant IDs defined in DA9061 and DA9062 hardware. The core header file adds new software enumerations for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration for distinguishing between DA9061/62 devices in software.

The core source code adds a new .compatible of_device_id entry. This is extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The .data entry now holds a reference to the enumerated device type.

A new regmap_irq_chip model is added for DA9061 and this supports the new list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the new sub system components for DA9061. Support is added for a new DA9061 regmap_config which lists the correct readable, writable and volatile ranges for this chip.

The probe function uses the device tree compatible string to switch on the da9062_compatible_types and configure the correct mfd cells, irq chip and regmap config.

Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.

Signed-off-by Steve Twiss <[email protected]>

---

Acked-for-mfd-by Lee Jones <[email protected]>

Hi Lee, that Ack was from your earlier posting:
https://lkml.org/lkml/2017/1/4/328 this was
Regards, Steve.

This patch applies against linux-next and v4.11-rc3

v6 -> v7
- Remove compilation warning when casting a void * to an integer on ARCH=x86_64 using -Wpointer-to-int-cast.
- Recommendation uintptr_t cast: https://lkml.org/lkml/2017/3/28/292
- Compile tested ARCH=x86_64

v5 -> v6
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
- Fixed "braces {} should be used on all arms" checkpatch warning

v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9

v3 -> v4
- Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
- Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced them with DEFINE_RES_IRQ_NAMED().
- Removed whitespace
- Reverted change for badly defined mfd_cell da9062_devs of_compatible string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"

v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]

v1 -> v2
- Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these changes were made to fix checkpatch warnings caused by the patch set dependency order
- Fixed typo in the commit message "readble" to "readable"
- Removed the explicit cross-check to decide if there is a conflict between the device tree compatible string and the hardware definition. This patch assumes the device tree is correctly written and therefore removes the need for a hardware/DT sanity check.
- Removed extra semicolon in drivers/mfd/da9062-core.c:877
- Re-write compatible entries into numerical order

Lee,

Changes as described in the version history above.

As previously:
This patch adds support for the DA9061 PMIC. This is done as part of the existing DA9062 device driver by extending the of_device_id match table. This in turn allows new MFD cells, irq chip and regmap definitions to support DA9061.

Regards,
Steve Twiss, Dialog Semiconductor

 drivers/mfd/Kconfig                  |   5 +-
 drivers/mfd/da9062-core.c            | 427 +++++++++++++++++++++++++++++++++--
 include/linux/mfd/da9062/core.h      |  29 ++-
 include/linux/mfd/da9062/registers.h |   5 +-
 4 files changed, 443 insertions(+), 23 deletions(-)

drivers/mfd/Kconfig +3 -2

index 55ecdfb..29cc11a 100644
@@ -263,13 +263,14 @@ config MFD_DA9055
 	  called "da9055"
 
 config MFD_DA9062
-	tristate "Dialog Semiconductor DA9062 PMIC Support"
+	tristate "Dialog Semiconductor DA9062/61 PMIC Support"
 	select MFD_CORE
 	select REGMAP_I2C
 	select REGMAP_IRQ
 	depends on I2C
 	help
-	  Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+	  Say yes here for support for the Dialog Semiconductor DA9061 and
+	  DA9062 PMICs.
 	  This includes the I2C driver and core APIs.
 	  Additional drivers must be enabled in order to use the functionality
 	  of the device.

drivers/mfd/da9062-core.c +0 -0

index 8f873866..78ab3f4 100644

drivers/mfd/da9062-core.c +16 -0

+		cell = da9061_devs;
+		cell_num = ARRAY_SIZE(da9061_devs);
+		irq_chip = &da9061_irq_chip;
+		config = &da9061_regmap_config;
+		break;
+	case(COMPAT_TYPE_DA9062):
+		cell = da9062_devs;
+		cell_num = ARRAY_SIZE(da9062_devs);
+		irq_chip = &da9062_irq_chip;
+		config = &da9062_regmap_config;
+		break;
+	default:
+		dev_err(chip->dev, "Unrecognised chip type\n");
+		return -ENODEV;
+	}
+

drivers/mfd/da9062-core.c static int da9062_i2c_probe(struct i2c_client *i2c, · line 859

Quoted 7 lines

drivers/mfd/da9062-core.c +2 -1

@@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
 		return -EINVAL;
 	}
 
-	chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+	switch (chip->chip_type) {
+	case(COMPAT_TYPE_DA9061):

Brackets around the case value?

That's a new one on me.

Quoted 10 lines · Lee Jones

drivers/mfd/da9062-core.c static int da9062_i2c_probe(struct i2c_client *i2c, · line 859

Quoted 7 lines

drivers/mfd/da9062-core.c +2 -1

@@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
 		return -EINVAL;
 	}
 
-	chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+	switch (chip->chip_type) {
+	case(COMPAT_TYPE_DA9061):

Brackets around the case value?

Quoted 1 line

That's a new one on me.

Hm. Do you want me to resend it without braces?

Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support

Quoted 12 lines · Steve Twiss

Quoted 10 lines · Lee Jones

drivers/mfd/da9062-core.c static int da9062_i2c_probe(struct i2c_client *i2c, · line 859

Quoted 7 lines

drivers/mfd/da9062-core.c +2 -1

@@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
 		return -EINVAL;
 	}
 
-	chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+	switch (chip->chip_type) {
+	case(COMPAT_TYPE_DA9061):

Brackets around the case value?

Quoted 3 lines

Quoted 1 line

That's a new one on me.

Hm. Do you want me to resend it without braces?

Yes please. And a space after the 'case'.

Quoted 19 lines · Lee Jones

Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support

Quoted 15 lines · Steve Twiss

Quoted 11 lines · Lee Jones

drivers/mfd/da9062-core.c static int da9062_i2c_probe(struct i2c_client *i2c, · line 859

Quoted 7 lines

drivers/mfd/da9062-core.c +2 -1

@@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
 		return -EINVAL;
 	}
 
-	chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+	switch (chip->chip_type) {
+	case(COMPAT_TYPE_DA9061):

Brackets around the case value?

That's a new one on me.

Hm. Do you want me to resend it without braces?

Quoted 1 line

Yes please. And a space after the 'case'.

Hi Lee,

I have resent PATCH V7 to change "case(X):" to be "case X:".
- Removed brackets surrounding case statements for

    case COMPAT_TYPE_DA9061:
    case COMPAT_TYPE_DA9062:

New patch is here:
https://lkml.org/lkml/2017/4/3/462

The patch it is called by the same title "[PATCH V7 4/7] mfd: da9061: MFD core support". I've not updated the whole patch-set or changed the patch version number from V7.

From: Steve Twiss <[email protected]>

Add junction temperature monitoring supervisor device driver, compatible with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.

If the PMIC's internal junction temperature rises above T_WARN (125 degC) an interrupt is issued. This T_WARN level is defined as the THERMAL_TRIP_HOT trip-wire inside the device driver.

The thermal triggering mechanism is interrupt based and happens when the temperature rises above a given threshold level. The component cannot return an exact temperature, it only has knowledge if the temperature is above or below a given threshold value. A status bit must be polled to detect when the temperature falls below that threshold level again. A kernel work queue is configured to repeatedly poll and detect when the temperature falls below this trip-wire, between 1 and 10 second intervals (defaulting at 3 seconds).

This scheme is provided as an example. It would be expected that any final implementation will also include a notify() function and any of these settings could be altered to match the application where appropriate.

When over-temperature is reached, the interrupt from the DA9061/2 will be repeatedly triggered. The IRQ is therefore disabled when the first over-temperature event happens and the status bit is polled using a work-queue until it becomes false.

This strategy is designed to allow the periodic transmission of uevents (HOT trip point) as the first level of temperature supervision method. It is intended for non-invasive temperature control, where the necessary measures for cooling the system down are left to the host software. Once the temperature falls again, the IRQ is re-enabled so a new critical over-temperature event can be detected.

Reviewed-by Lukasz Luba <[email protected]>

Signed-off-by Steve Twiss <[email protected]>

---
This patch applies against linux-next and v4.11-rc3

v6 -> v7
- NO CODE CHANGE
- Compile tested ARCH=x86_64

v5 -> v6
- Patch renamed from [PATCH V5 7/8] to [PATCH V6 6/7]
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
- Various checkpatch warnings (from --strict) have been fixed
- Added COMPILE_TEST to Kconfig

v4 -> v5
- Rebased from v4.8 to v4.9
- Updates from comments by Eduardo Valentin
- Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard thermal core polling-delay-passive as part of the device tree initialisation
- Change to the commit message content and device driver source code to include an explanation of the repeated uevent strategy for monitoring over-temperature
- Rename warning threshold name from TEMP_WARN to T_WARN to match the latest datasheet naming convention
- Added reviewed-by Lukasz Luba to commit message

v3 -> v4
- Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
- Reordering of cancel_delayed_work_sync() in remove function
- dev_warn() message for out-of-range polling period requests
- Explanatory comment for expected values defined for DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and MIN_POLLING_MS_PERIOD

v2 -> v3
- Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions

v1 -> v2
- Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these changes were made to fix checkpatch warnings caused by the patch set dependency order
- List the header files in alphabetical order
- Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the copyright "GNU Public License v2 or later" option in the header comment for this file. See the allowed identifiers in the file include/linux/module.h +170
- Remove notify function "da9062_thermal_notify" function.
- MODULE_AUTHOR() macros removes Company Name and just gives Name in accordance with include/linux/module.h +200
- Remove the compatible "dlg,da9061-thermal" option in the of_device_id struct table. This patch now assumes the use of a DA9062 fallback compatible string in the DTS when using the DA9061 thermal component of the DA9061 device.
- Re-ordered some assignments earlier in the probe() for thermal->hw, thermal->polling_period, thermal->mode, thermal->dev
- Added further information in the patch description to explain the use of the device driver's built-in work-queue.

Regards,
Steve Twiss, Dialog Semiconductor

 drivers/thermal/Kconfig          |  10 ++
 drivers/thermal/Makefile         |   1 +
 drivers/thermal/da9062-thermal.c | 315 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 326 insertions(+)
 create mode 100644 drivers/thermal/da9062-thermal.c

drivers/thermal/Kconfig +10 -0

index 776b3439..a784b02 100644
@@ -303,6 +303,16 @@ config DB8500_CPUFREQ_COOLING
 	  bound cpufreq cooling device turns active to set CPU frequency low to
 	  cool down the CPU.
 
+config DA9062_THERMAL
+	tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+	depends on MFD_DA9062 || COMPILE_TEST
+	depends on OF
+	help
+	  Enable this for the Dialog Semiconductor thermal sensor driver.
+	  This will report PMIC junction over-temperature for one thermal trip
+	  zone.
+	  Compatible with the DA9062 and DA9061 PMICs.
+
 config INTEL_POWERCLAMP
 	tristate "Intel PowerClamp idle injection driver"
 	depends on THERMAL

drivers/thermal/Makefile +1 -0

index 7adae20..297849e 100644
@@ -42,6 +42,7 @@ obj-$(CONFIG_IMX_THERMAL)	+= imx_thermal.o
 obj-$(CONFIG_MAX77620_THERMAL)	+= max77620_thermal.o
 obj-$(CONFIG_QORIQ_THERMAL)	+= qoriq_thermal.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)	+= db8500_cpufreq_cooling.o
+obj-$(CONFIG_DA9062_THERMAL)	+= da9062-thermal.o
 obj-$(CONFIG_INTEL_POWERCLAMP)	+= intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL)	+= x86_pkg_temp_thermal.o
 obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE)	+= intel_soc_dts_iosf.o

drivers/thermal/da9062-thermal.c new file +315 -0

new file mode 100644
index 0000000..dd8dd94
@@ -0,0 +1,315 @@
+/*
+ * Thermal device driver for DA9062 and DA9061
+ * Copyright (C) 2017  Dialog Semiconductor
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * 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.
+ */
+
+/* When over-temperature is reached, an interrupt from the device will be
+ * triggered. Following this event the interrupt will be disabled and
+ * periodic transmission of uevents (HOT trip point) should define the
+ * first level of temperature supervision. It is expected that any final
+ * implementation of the thermal driver will include a .notify() function
+ * to implement these uevents to userspace.
+ *
+ * These uevents are intended to indicate non-invasive temperature control
+ * of the system, where the necessary measures for cooling are the
+ * responsibility of the host software. Once the temperature falls again,
+ * the IRQ is re-enabled so the start of a new over-temperature event can
+ * be detected without constant software monitoring.
+ */
+
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+#include <linux/workqueue.h>
+
+#include <linux/mfd/da9062/core.h>
+#include <linux/mfd/da9062/registers.h>
+
+/* Minimum, maximum and default polling millisecond periods are provided
+ * here as an example. It is expected that any final implementation to also
+ * include a modification of these settings to match the required
+ * application.
+ */
+#define DA9062_DEFAULT_POLLING_MS_PERIOD	3000
+#define DA9062_MAX_POLLING_MS_PERIOD		10000
+#define DA9062_MIN_POLLING_MS_PERIOD		1000
+
+#define DA9062_MILLI_CELSIUS(t)			((t) * 1000)
+
+struct da9062_thermal_config {
+	const char *name;
+};
+
+struct da9062_thermal {
+	struct da9062 *hw;
+	struct delayed_work work;
+	struct thermal_zone_device *zone;
+	enum thermal_device_mode mode;
+	struct mutex lock; /* protection for da9062_thermal temperature */
+	int temperature;
+	int irq;
+	const struct da9062_thermal_config *config;
+	struct device *dev;
+};
+
+static void da9062_thermal_poll_on(struct work_struct *work)
+{
+	struct da9062_thermal *thermal = container_of(work,
+						struct da9062_thermal,
+						work.work);
+	unsigned long delay;
+	unsigned int val;
+	int ret;
+
+	/* clear E_TEMP */
+	ret = regmap_write(thermal->hw->regmap,
+			   DA9062AA_EVENT_B,
+			   DA9062AA_E_TEMP_MASK);
+	if (ret < 0) {
+		dev_err(thermal->dev,
+			"Cannot clear the TJUNC temperature status\n");
+		goto err_enable_irq;
+	}
+
+	/* Now read E_TEMP again: it is acting like a status bit.
+	 * If over-temperature, then this status will be true.
+	 * If not over-temperature, this status will be false.
+	 */
+	ret = regmap_read(thermal->hw->regmap,
+			  DA9062AA_EVENT_B,
+			  &val);
+	if (ret < 0) {
+		dev_err(thermal->dev,
+			"Cannot check the TJUNC temperature status\n");
+		goto err_enable_irq;
+	}
+
+	if (val & DA9062AA_E_TEMP_MASK) {
+		mutex_lock(&thermal->lock);
+		thermal->temperature = DA9062_MILLI_CELSIUS(125);
+		mutex_unlock(&thermal->lock);
+		thermal_zone_device_update(thermal->zone,
+					   THERMAL_EVENT_UNSPECIFIED);
+
+		delay = msecs_to_jiffies(thermal->zone->passive_delay);
+		schedule_delayed_work(&thermal->work, delay);
+		return;
+	}
+
+	mutex_lock(&thermal->lock);
+	thermal->temperature = DA9062_MILLI_CELSIUS(0);
+	mutex_unlock(&thermal->lock);
+	thermal_zone_device_update(thermal->zone,
+				   THERMAL_EVENT_UNSPECIFIED);
+
+err_enable_irq:
+	enable_irq(thermal->irq);
+}
+
+static irqreturn_t da9062_thermal_irq_handler(int irq, void *data)
+{
+	struct da9062_thermal *thermal = data;
+
+	disable_irq_nosync(thermal->irq);
+	schedule_delayed_work(&thermal->work, 0);
+
+	return IRQ_HANDLED;
+}
+
+static int da9062_thermal_get_mode(struct thermal_zone_device *z,
+				   enum thermal_device_mode *mode)
+{
+	struct da9062_thermal *thermal = z->devdata;
+	*mode = thermal->mode;
+	return 0;
+}
+
+static int da9062_thermal_get_trip_type(struct thermal_zone_device *z,
+					int trip,
+					enum thermal_trip_type *type)
+{
+	struct da9062_thermal *thermal = z->devdata;
+
+	switch (trip) {
+	case 0:
+		*type = THERMAL_TRIP_HOT;
+		break;
+	default:
+		dev_err(thermal->dev,
+			"Driver does not support more than 1 trip-wire\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int da9062_thermal_get_trip_temp(struct thermal_zone_device *z,
+					int trip,
+					int *temp)
+{
+	struct da9062_thermal *thermal = z->devdata;
+
+	switch (trip) {
+	case 0:
+		*temp = DA9062_MILLI_CELSIUS(125);
+		break;
+	default:
+		dev_err(thermal->dev,
+			"Driver does not support more than 1 trip-wire\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int da9062_thermal_get_temp(struct thermal_zone_device *z,
+				   int *temp)
+{
+	struct da9062_thermal *thermal = z->devdata;
+
+	mutex_lock(&thermal->lock);
+	*temp = thermal->temperature;
+	mutex_unlock(&thermal->lock);
+
+	return 0;
+}
+
+static struct thermal_zone_device_ops da9062_thermal_ops = {
+	.get_temp	= da9062_thermal_get_temp,
+	.get_mode	= da9062_thermal_get_mode,
+	.get_trip_type	= da9062_thermal_get_trip_type,
+	.get_trip_temp	= da9062_thermal_get_trip_temp,
+};
+
+static const struct da9062_thermal_config da9062_config = {
+	.name = "da9062-thermal",
+};
+
+static const struct of_device_id da9062_compatible_reg_id_table[] = {
+	{ .compatible = "dlg,da9062-thermal", .data = &da9062_config },
+	{ },
+};
+
+MODULE_DEVICE_TABLE(of, da9062_compatible_reg_id_table);
+
+static int da9062_thermal_probe(struct platform_device *pdev)
+{
+	struct da9062 *chip = dev_get_drvdata(pdev->dev.parent);
+	struct da9062_thermal *thermal;
+	unsigned int pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+	const struct of_device_id *match;
+	int ret = 0;
+
+	match = of_match_node(da9062_compatible_reg_id_table,
+			      pdev->dev.of_node);
+	if (!match)
+		return -ENXIO;
+
+	if (pdev->dev.of_node) {
+		if (!of_property_read_u32(pdev->dev.of_node,
+					  "polling-delay-passive",
+					  &pp_tmp)) {
+			if (pp_tmp < DA9062_MIN_POLLING_MS_PERIOD ||
+			    pp_tmp > DA9062_MAX_POLLING_MS_PERIOD) {
+				dev_warn(&pdev->dev,
+					 "Out-of-range polling period %d ms\n",
+					 pp_tmp);
+				pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+			}
+		}
+	}
+
+	thermal = devm_kzalloc(&pdev->dev, sizeof(struct da9062_thermal),
+			       GFP_KERNEL);
+	if (!thermal) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	thermal->config = match->data;
+	thermal->hw = chip;
+	thermal->mode = THERMAL_DEVICE_ENABLED;
+	thermal->dev = &pdev->dev;
+
+	INIT_DELAYED_WORK(&thermal->work, da9062_thermal_poll_on);
+	mutex_init(&thermal->lock);
+
+	thermal->zone = thermal_zone_device_register(thermal->config->name,
+					1, 0, thermal,
+					&da9062_thermal_ops, NULL, pp_tmp,
+					0);
+	if (IS_ERR(thermal->zone)) {
+		dev_err(&pdev->dev, "Cannot register thermal zone device\n");
+		ret = PTR_ERR(thermal->zone);
+		goto err;
+	}
+
+	dev_dbg(&pdev->dev,
+		"TJUNC temperature polling period set at %d ms\n",
+		thermal->zone->passive_delay);
+
+	ret = platform_get_irq_byname(pdev, "THERMAL");
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to get platform IRQ.\n");
+		goto err_zone;
+	}
+	thermal->irq = ret;
+
+	ret = request_threaded_irq(thermal->irq, NULL,
+				   da9062_thermal_irq_handler,
+				   IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+				   "THERMAL", thermal);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to request thermal device IRQ.\n");
+		goto err_zone;
+	}
+
+	platform_set_drvdata(pdev, thermal);
+	return 0;
+
+err_zone:
+	thermal_zone_device_unregister(thermal->zone);
+err:
+	return ret;
+}
+
+static int da9062_thermal_remove(struct platform_device *pdev)
+{
+	struct	da9062_thermal *thermal = platform_get_drvdata(pdev);
+
+	free_irq(thermal->irq, thermal);
+	cancel_delayed_work_sync(&thermal->work);
+	thermal_zone_device_unregister(thermal->zone);
+	return 0;
+}
+
+static struct platform_driver da9062_thermal_driver = {
+	.probe	= da9062_thermal_probe,
+	.remove	= da9062_thermal_remove,
+	.driver	= {
+		.name	= "da9062-thermal",
+		.of_match_table = da9062_compatible_reg_id_table,
+	},
+};
+
+module_platform_driver(da9062_thermal_driver);
+
+MODULE_AUTHOR("Steve Twiss");
+MODULE_DESCRIPTION("Thermal TJUNC device driver for Dialog DA9062 and DA9061");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:da9062-thermal");

Signature · 1 line

end-of-patch for PATCH V7

Subject: Re: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver

Quoted 34 lines · Steve Twiss

From: Steve Twiss <[email protected]>

Add junction temperature monitoring supervisor device driver, compatible with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.

If the PMIC's internal junction temperature rises above T_WARN (125 degC) an interrupt is issued. This T_WARN level is defined as the THERMAL_TRIP_HOT trip-wire inside the device driver.

The thermal triggering mechanism is interrupt based and happens when the temperature rises above a given threshold level. The component cannot return an exact temperature, it only has knowledge if the temperature is above or below a given threshold value. A status bit must be polled to detect when the temperature falls below that threshold level again. A kernel work queue is configured to repeatedly poll and detect when the temperature falls below this trip-wire, between 1 and 10 second intervals (defaulting at 3 seconds).

This scheme is provided as an example. It would be expected that any final implementation will also include a notify() function and any of these settings could be altered to match the application where appropriate.

When over-temperature is reached, the interrupt from the DA9061/2 will be repeatedly triggered. The IRQ is therefore disabled when the first over-temperature event happens and the status bit is polled using a work-queue until it becomes false.

This strategy is designed to allow the periodic transmission of uevents (HOT trip point) as the first level of temperature supervision method. It is intended for non-invasive temperature control, where the necessary measures for cooling the system down are left to the host software. Once the temperature falls again, the IRQ is re-enabled so a new critical over-temperature event can be detected.

Quoted 2 lines

Reviewed-by Lukasz Luba <[email protected]>

Signed-off-by Steve Twiss <[email protected]>

I have had a look on the history of this driver on its previous versions, and I do not think I have any other point to request on it.

Obviously, I still need to state that I do not like its oddness as it is not really benefiting much of the thermal control implemented on the thermal subsystem.

What is the plan for this series? Am I expected to get this driver through thermal tree ? Or is this series going into a one shot?

If option 1 is the expected, would the driver need to get its mfd parent merged first?

From: Steve Twiss <[email protected]>

This patch set adds support for the Dialog DA9061 Power Management IC. Support is made by altering the existing DA9062 device driver, where appropriate.

Hello,

Previously, there were only minor changes for v6. The patch v7 introduces a compile test for x86 64-bit.