| Message ID | faf9c3e5f970b9609073c4c191a7af03d647ea51.1500041281.git.leonard.crestez@nxp.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Delegated to: | Zhang Rui |
| Headers | show |
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>
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
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 >
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
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 >
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 > >
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
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
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 */
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(-)