[v2,3/5] thermal: imx: Add support for reading OCOTP through nvmem
diff mbox

Message ID faf9c3e5f970b9609073c4c191a7af03d647ea51.1500041281.git.leonard.crestez@nxp.com
State Accepted, archived
Delegated to: Zhang Rui
Headers show

Commit Message

Leonard Crestez July 14, 2017, 2:11 p.m. UTC
On newer imx SOCs accessing OCOTP directly is wrong because the ocotp clock
needs to be enabled first. Add support for reading those same values through
the nvmem API instead.

The older path is preserved for compatibility with older dts and because it
works correctly on imx6qdl chips.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/thermal/imx_thermal.c | 103 ++++++++++++++++++++++++++++++------------
 1 file changed, 73 insertions(+), 30 deletions(-)

Comments

Shawn Guo July 25, 2017, 8:08 a.m. UTC | #1
On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> On newer imx SOCs accessing OCOTP directly is wrong because the ocotp clock
> needs to be enabled first. Add support for reading those same values through
> the nvmem API instead.
> 
> The older path is preserved for compatibility with older dts and because it
> works correctly on imx6qdl chips.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Acked-by: Shawn Guo <shawnguo@kernel.org>
Zhang Rui Aug. 8, 2017, 7:21 a.m. UTC | #2
On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> > 
> > On newer imx SOCs accessing OCOTP directly is wrong because the
> > ocotp clock
> > needs to be enabled first. Add support for reading those same
> > values through
> > the nvmem API instead.
> > 
> > The older path is preserved for compatibility with older dts and
> > because it
> > works correctly on imx6qdl chips.
> > 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> Acked-by: Shawn Guo <shawnguo@kernel.org>

I'm okay with the thermal change.
We still need ACK for the nvmem changes in this patch series.

thanks,
rui
Srinivas Kandagatla Aug. 8, 2017, 11 a.m. UTC | #3
On 08/08/17 08:21, Zhang Rui wrote:
> On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
>> On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
>>>
>>> On newer imx SOCs accessing OCOTP directly is wrong because the
>>> ocotp clock
>>> needs to be enabled first. Add support for reading those same
>>> values through
>>> the nvmem API instead.
>>>
>>> The older path is preserved for compatibility with older dts and
>>> because it
>>> works correctly on imx6qdl chips.
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Acked-by: Shawn Guo <shawnguo@kernel.org>
> 
> I'm okay with the thermal change.
> We still need ACK for the nvmem changes in this patch series.
NVMEM changes are already sent to Greg K H with other patches 
(https://lkml.org/lkml/2017/7/26/164), should appear in next.


> 
> thanks,
> rui
>
Leonard Crestez Aug. 8, 2017, 11:38 a.m. UTC | #4
On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> On 08/08/17 08:21, Zhang Rui wrote:
> > On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> > > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:

> > > > On newer imx SOCs accessing OCOTP directly is wrong because the
> > > > ocotp clock
> > > > needs to be enabled first. Add support for reading those same
> > > > values through
> > > > the nvmem API instead.
> > > > 
> > > > The older path is preserved for compatibility with older dts and
> > > > because it
> > > > works correctly on imx6qdl chips.
> > > > 
> > > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > > Acked-by: Shawn Guo <shawnguo@kernel.org>

> > I'm okay with the thermal change.
> > We still need ACK for the nvmem changes in this patch series.

> NVMEM changes are already sent to Greg K H with other patches 
> (https://lkml.org/lkml/2017/7/26/164), should appear in next.

These patches have a compile-time dependency on each other. Wouldn't it
make more sense for the whole series to go through a single maintainer
tree, atomically? Most of the changes are in driver/thermal.

I'm really very confused about how series that touch multiple areas are
applied. It seems to be a mostly ad-hoc process.

--
Regards,
Leonard
Srinivas Kandagatla Aug. 8, 2017, 11:44 a.m. UTC | #5
On 08/08/17 12:38, Leonard Crestez wrote:
> On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
>> On 08/08/17 08:21, Zhang Rui wrote:
>>> On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
>>>> On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> 
>>>>> On newer imx SOCs accessing OCOTP directly is wrong because the
>>>>> ocotp clock
>>>>> needs to be enabled first. Add support for reading those same
>>>>> values through
>>>>> the nvmem API instead.
>>>>>
>>>>> The older path is preserved for compatibility with older dts and
>>>>> because it
>>>>> works correctly on imx6qdl chips.
>>>>>
>>>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>>> Acked-by: Shawn Guo <shawnguo@kernel.org>
> 
>>> I'm okay with the thermal change.
>>> We still need ACK for the nvmem changes in this patch series.
> 
>> NVMEM changes are already sent to Greg K H with other patches
>> (https://lkml.org/lkml/2017/7/26/164), should appear in next.
> 
> These patches have a compile-time dependency on each other. Wouldn't it
> make more sense for the whole series to go through a single maintainer
> tree, atomically? Most of the changes are in driver/thermal.

I was expecting that the nvmem change go in as fix in a rc release so 
that you could apply the other patches after that.

Let me ping Greg about this!!
> 
> I'm really very confused about how series that touch multiple areas are
> applied. It seems to be a mostly ad-hoc process.
> 
> --
> Regards,
> Leonard
>
Zhang Rui Aug. 8, 2017, 12:58 p.m. UTC | #6
On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > 


> 
> On 08/08/17 12:38, Leonard Crestez wrote:
> > 
> > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 08:21, Zhang Rui wrote:
> > > > 
> > > > On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> > > > > 
> > > > > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez
> > > > > wrote:
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > On newer imx SOCs accessing OCOTP directly is wrong because
> > > > > > the
> > > > > > ocotp clock
> > > > > > needs to be enabled first. Add support for reading those
> > > > > > same
> > > > > > values through
> > > > > > the nvmem API instead.
> > > > > > 
> > > > > > The older path is preserved for compatibility with older
> > > > > > dts and
> > > > > > because it
> > > > > > works correctly on imx6qdl chips.
> > > > > > 
> > > > > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > > > > Acked-by: Shawn Guo <shawnguo@kernel.org>
> > > 
> > > > 
> > > > I'm okay with the thermal change.
> > > > We still need ACK for the nvmem changes in this patch series.
> > > 
> > > NVMEM changes are already sent to Greg K H with other patches
> > > (https://lkml.org/lkml/2017/7/26/164), should appear in next.
> > These patches have a compile-time dependency on each other.
> > Wouldn't it
> > make more sense for the whole series to go through a single
> > maintainer
> > tree, atomically? Most of the changes are in driver/thermal.
> I was expecting that the nvmem change go in as fix in a rc release
> so 
> that you could apply the other patches after that.
> 
> Let me ping Greg about this!!

As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch 1/5,
3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I can
queue the full patch set for 4.14, with Srinivas' ACK.

thanks,
rui
> > 
> > I'm really very confused about how series that touch multiple areas
> > are
> > applied. It seems to be a mostly ad-hoc process.
> > 
> > --
> > Regards,
> > Leonard
> >
Leonard Crestez Aug. 16, 2017, 3:33 p.m. UTC | #7
On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > On 08/08/17 12:38, Leonard Crestez wrote:
> > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > On 08/08/17 08:21, Zhang Rui wrote:

> > > > > I'm okay with the thermal change.
> > > > > We still need ACK for the nvmem changes in this patch series.

> > > > NVMEM changes are already sent to Greg K H with other patches
> > > > https://lkml.org/lkml/2017/8/8/436, should appear in next.

> > > These patches have a compile-time dependency on each other.
> > > Wouldn't it make more sense for the whole series to go through a single
> > > maintainer tree, atomically? Most of the changes are in driver/thermal.

> > I was expecting that the nvmem change go in as fix in a rc release
> > so that you could apply the other patches after that.
> > 
> > Let me ping Greg about this!!

> As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch 1/5,
> 3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I can
> queue the full patch set for 4.14, with Srinivas' ACK.

It's been a week since the last email and it seems that nothing
happened. I can't find any of these patches in either torvalds/master
or linux-next. It seems to me that the nvmem series linked above was
not picked up after all?

It's not clear how to proceed. It's been more a month since the series
was sent so maybe I should resend it but it's not clear who would pick
it up.

--
Regards,
Leonard
Zhang Rui Aug. 25, 2017, 2:20 a.m. UTC | #8
On Wed, 2017-08-16 at 18:33 +0300, Leonard Crestez wrote:
> On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> > 
> > On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 12:38, Leonard Crestez wrote:
> > > > 
> > > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > > 
> > > > > On 08/08/17 08:21, Zhang Rui wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > I'm okay with the thermal change.
> > > > > > We still need ACK for the nvmem changes in this patch
> > > > > > series.
> > 
> > > 
> > > > 
> > > > > 
> > > > > NVMEM changes are already sent to Greg K H with other patches
> > > > > https://lkml.org/lkml/2017/8/8/436, should appear in next.
> > 
> > > 
> > > > 
> > > > These patches have a compile-time dependency on each other.
> > > > Wouldn't it make more sense for the whole series to go through
> > > > a single
> > > > maintainer tree, atomically? Most of the changes are in
> > > > driver/thermal.
> > 
> > > 
> > > I was expecting that the nvmem change go in as fix in a rc
> > > release
> > > so that you could apply the other patches after that.
> > > 
> > > Let me ping Greg about this!!
> > 

Srinivas,

Will you take patch 2/5?
Only after that, we can push the other changes.

thanks,
rui

> > As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch
> > 1/5,
> > 3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I
> > can
> > queue the full patch set for 4.14, with Srinivas' ACK.
> It's been a week since the last email and it seems that nothing
> happened. I can't find any of these patches in either torvalds/master
> or linux-next. It seems to me that the nvmem series linked above was
> not picked up after all?
> 
> It's not clear how to proceed. It's been more a month since the
> series
> was sent so maybe I should resend it but it's not clear who would
> pick
> it up.
> 
> --
> Regards,
> Leonard

Patch
diff mbox

diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index fb648a4..130405c 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -24,6 +24,7 @@ 
 #include <linux/slab.h>
 #include <linux/thermal.h>
 #include <linux/types.h>
+#include <linux/nvmem-consumer.h>
 
 #define REG_SET		0x4
 #define REG_CLR		0x8
@@ -92,7 +93,7 @@  struct imx_thermal_data {
 	struct thermal_cooling_device *cdev;
 	enum thermal_device_mode mode;
 	struct regmap *tempmon;
-	u32 c1, c2; /* See formula in imx_get_sensor_data() */
+	u32 c1, c2; /* See formula in imx_init_calib() */
 	int temp_passive;
 	int temp_critical;
 	int temp_max;
@@ -175,7 +176,7 @@  static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
 
 	n_meas = (val & TEMPSENSE0_TEMP_CNT_MASK) >> TEMPSENSE0_TEMP_CNT_SHIFT;
 
-	/* See imx_get_sensor_data() for formula derivation */
+	/* See imx_init_calib() for formula derivation */
 	*temp = data->c2 - n_meas * data->c1;
 
 	/* Update alarm value to next higher trip point for TEMPMON_IMX6Q */
@@ -344,29 +345,12 @@  static struct thermal_zone_device_ops imx_tz_ops = {
 	.set_trip_temp = imx_set_trip_temp,
 };
 
-static int imx_get_sensor_data(struct platform_device *pdev)
+static int imx_init_calib(struct platform_device *pdev, u32 val)
 {
 	struct imx_thermal_data *data = platform_get_drvdata(pdev);
-	struct regmap *map;
 	int t1, n1;
-	int ret;
-	u32 val;
 	u64 temp64;
 
-	map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
-					      "fsl,tempmon-data");
-	if (IS_ERR(map)) {
-		ret = PTR_ERR(map);
-		dev_err(&pdev->dev, "failed to get sensor regmap: %d\n", ret);
-		return ret;
-	}
-
-	ret = regmap_read(map, OCOTP_ANA1, &val);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to read sensor data: %d\n", ret);
-		return ret;
-	}
-
 	if (val == 0 || val == ~0) {
 		dev_err(&pdev->dev, "invalid sensor calibration data\n");
 		return -EINVAL;
@@ -403,12 +387,12 @@  static int imx_get_sensor_data(struct platform_device *pdev)
 	data->c1 = temp64;
 	data->c2 = n1 * data->c1 + 1000 * t1;
 
-	/* use OTP for thermal grade */
-	ret = regmap_read(map, OCOTP_MEM0, &val);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to read temp grade: %d\n", ret);
-		return ret;
-	}
+	return 0;
+}
+
+static void imx_init_temp_grade(struct platform_device *pdev, u32 val)
+{
+	struct imx_thermal_data *data = platform_get_drvdata(pdev);
 
 	/* The maximum die temp is specified by the Temperature Grade */
 	switch ((val >> 6) & 0x3) {
@@ -436,6 +420,55 @@  static int imx_get_sensor_data(struct platform_device *pdev)
 	 */
 	data->temp_critical = data->temp_max - (1000 * 5);
 	data->temp_passive = data->temp_max - (1000 * 10);
+}
+
+static int imx_init_from_tempmon_data(struct platform_device *pdev)
+{
+	struct regmap *map;
+	int ret;
+	u32 val;
+
+	map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+					      "fsl,tempmon-data");
+	if (IS_ERR(map)) {
+		ret = PTR_ERR(map);
+		dev_err(&pdev->dev, "failed to get sensor regmap: %d\n", ret);
+		return ret;
+	}
+
+	ret = regmap_read(map, OCOTP_ANA1, &val);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to read sensor data: %d\n", ret);
+		return ret;
+	}
+	ret = imx_init_calib(pdev, val);
+	if (ret)
+		return ret;
+
+	ret = regmap_read(map, OCOTP_MEM0, &val);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to read sensor data: %d\n", ret);
+		return ret;
+	}
+	imx_init_temp_grade(pdev, val);
+
+	return 0;
+}
+
+static int imx_init_from_nvmem_cells(struct platform_device *pdev)
+{
+	int ret;
+	u32 val;
+
+	ret = nvmem_cell_read_u32(&pdev->dev, "calib", &val);
+	if (ret)
+		return ret;
+	imx_init_calib(pdev, val);
+
+	ret = nvmem_cell_read_u32(&pdev->dev, "temp_grade", &val);
+	if (ret)
+		return ret;
+	imx_init_temp_grade(pdev, val);
 
 	return 0;
 }
@@ -512,10 +545,20 @@  static int imx_thermal_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, data);
 
-	ret = imx_get_sensor_data(pdev);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to get sensor data\n");
-		return ret;
+	if (of_find_property(pdev->dev.of_node, "nvmem-cells", NULL)) {
+		ret = imx_init_from_nvmem_cells(pdev);
+		if (ret == -EPROBE_DEFER)
+			return ret;
+		if (ret) {
+			dev_err(&pdev->dev, "failed to init from nvmem: %d\n", ret);
+			return ret;
+		}
+	} else {
+		ret = imx_init_from_tempmon_data(pdev);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to init from from fsl,tempmon-data\n");
+			return ret;
+		}
 	}
 
 	/* Make sure sensor is in known good state for measurements */