Re: [PATCH 2/5] thermal: exynos: Fix first temperature read after registering sensor
Hi Alim,
> Hello,
>
> On Thu, Oct 8, 2015 at 11:04 AM, Krzysztof Kozlowski
> wrote:
> > Thermal core could not read the temperature after registering the
> > thermal sensor with thermal_zone_of_sensor_register() because the
> > driver was not yet initialized.
> >
> > The call trace looked like:
> > exynos_tmu_probe()
> > thermal_zone_of_sensor_register()
> > of_thermal_set_mode()
> > thermal_zone_device_update()
> > exynos_get_temp()
> > if (!data->tmu_read) return -EINVAL;
> > exynos_map_dt_data()
> > data->tmu_read = ...
> >
> > This produced an error in dmesg:
> > thermal thermal_zone0: failed to read out thermal zone (-22)
> >
> > Register the thermal_zone_device later, after parsing Device Tree
> > and enabling necessary clocks, but before calling
> > exynos_tmu_initialize() which uses the registered
> > thermal_zone_device.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > Fixes: 3b6a1a805f34 ("thermal: samsung: core: Exynos TMU rework to
> > use device tree for configuration") ---
> Patch looks good to me.
>
> Before this patch I was getting below on exynos5800 board:
> [2.648629] thermal thermal_zone0: failed to read out thermal zone
> (-22) [2.653906] 1006.tmu supply vtmu not found, using dummy
> regulator [2.660521] thermal thermal_zone1: failed to read out
> thermal zone (-22) [2.666985] 10064000.tmu supply vtmu not found,
> using dummy regulator [2.673658] thermal thermal_zone2: failed to
> read out thermal zone (-22) [2.680093] 10068000.tmu supply vtmu
> not found, using dummy regulator [2.686901] thermal
> thermal_zone3: failed to read out thermal zone (-22) [2.693187]
> 1006c000.tmu supply vtmu not found, using dummy regulator
> [2.699914] thermal thermal_zone4: failed to read out thermal zone
> (-22) [2.706332] 100a.tmu supply vtmu not found, using dummy
> regulator
>
>
> Reviewed-by: Alim Akhtar
>
> Tested on exynos5800 peach board, so
> Tested-by: Alim Akhtar
>
>
> > drivers/thermal/samsung/exynos_tmu.c | 27 +
> --
> > 1 file changed, 17 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c index
> > 23f4320f8ef7..bc71a61f0c4a 100644 ---
> > a/drivers/thermal/samsung/exynos_tmu.c +++
> > b/drivers/thermal/samsung/exynos_tmu.c @@ -1289,13 +1289,6 @@
> > static int exynos_tmu_probe(struct platform_device *pdev)
> > platform_set_drvdata(pdev, data); mutex_init(&data->lock);
> >
> > - data->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0,
> > data,
> > -
> > &exynos_sensor_ops);
> > - if (IS_ERR(data->tzd)) {
> > - pr_err("thermal: tz: %p ERROR\n", data->tzd);
> > - return PTR_ERR(data->tzd);
> > - }
> > -
> > /*
> > * Try enabling the regulator if found
> > * TODO: Add regulator as an SOC feature, so that regulator
> > enable @@ -1365,21 +1358,36 @@ static int exynos_tmu_probe(struct
> > platform_device *pdev) break;
> > };
> >
> > + /*
> > +* data->tzd must be registered before calling
> > exynos_tmu_initialize(),
> > +* requesting irq and calling exynos_tmu_control().
> > +*/
> > + data->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0,
> > data,
> > +
> > &exynos_sensor_ops);
> > + if (IS_ERR(data->tzd)) {
> > + ret = PTR_ERR(data->tzd);
> > + dev_err(&pdev->dev, "Failed to register sensor:
> > %d\n", ret);
> > + goto err_sclk;
> > + }
> > +
> > ret = exynos_tmu_initialize(pdev);
> > if (ret) {
> > dev_err(&pdev->dev, "Failed to initialize TMU\n");
> > - goto err_sclk;
> > + goto err_thermal;
> > }
> >
> > ret = devm_request_irq(&pdev->dev, data->irq,
> > exynos_tmu_irq, IRQF_TRIGGER_RISING | IRQF_SHARED,
> > dev_name(&pdev->dev), data); if (ret) {
> > dev_err(&pdev->dev, "Failed to request irq: %d\n",
> > data->irq);
> > - goto err_sclk;
> > + goto err_thermal;
> > }
> >
> > exynos_tmu
Re: [PATCH 3/5] thermal: exynos: Use IS_ERR() because regulator cannot be NULL
Hi Alim, > Hello, > > On Thu, Oct 8, 2015 at 11:04 AM, Krzysztof Kozlowski > wrote: > > The NULL check in probe's error path is not needed because in that > > time the regulator cannot be NULL (regulator_get() returns valid > > pointer or ERR_PTR). > > > > Signed-off-by: Krzysztof Kozlowski > > --- > Reviewed-by: Alim Akhtar > > > drivers/thermal/samsung/exynos_tmu.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/thermal/samsung/exynos_tmu.c > > b/drivers/thermal/samsung/exynos_tmu.c index > > bc71a61f0c4a..eac6aebf82f3 100644 --- > > a/drivers/thermal/samsung/exynos_tmu.c +++ > > b/drivers/thermal/samsung/exynos_tmu.c @@ -1396,7 +1396,7 @@ > > err_clk_sec: if (!IS_ERR(data->clk_sec)) > > clk_unprepare(data->clk_sec); > > err_sensor: > > - if (!IS_ERR_OR_NULL(data->regulator)) > > + if (!IS_ERR(data->regulator)) > > regulator_disable(data->regulator); > > > > return ret; > > -- > > 1.9.1 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-samsung-soc" in the body of a message to > > majord...@vger.kernel.org More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > > Acked-by: Lukasz Majewski Tested-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] thermal: exynos: Directly return 0 instead of using local ret variable
Hi Alim,
> Hello,
>
> On Thu, Oct 8, 2015 at 11:04 AM, Krzysztof Kozlowski
> wrote:
> > The 'ret' variable in exynos5440_tmu_initialize() is initialized to
> > 0 and returned as is. Replace it with direct return statement. This
> > also fixes coccinelle warning:
> > drivers/thermal/samsung/exynos_tmu.c:611:5-8: Unneeded variable:
> > "ret". Return "0" on line 654
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> Reviewed-by: Alim Akhtar
>
> > drivers/thermal/samsung/exynos_tmu.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c index
> > 1af7ea8dda71..f340e6edcb49 100644 ---
> > a/drivers/thermal/samsung/exynos_tmu.c +++
> > b/drivers/thermal/samsung/exynos_tmu.c @@ -608,7 +608,7 @@ static
> > int exynos5440_tmu_initialize(struct platform_device *pdev) {
> > struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> > unsigned int trim_info = 0, con, rising_threshold;
> > - int ret = 0, threshold_code;
> > + int threshold_code;
> > int crit_temp = 0;
> >
> > /*
> > @@ -651,7 +651,8 @@ static int exynos5440_tmu_initialize(struct
> > platform_device *pdev) /* Clear the PMIN in the common TMU register
> > */ if (!data->id)
> > writel(0, data->base_second + EXYNOS5440_TMU_PMIN);
> > - return ret;
> > +
> > + return 0;
> > }
> >
> > static int exynos7_tmu_initialize(struct platform_device *pdev)
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-samsung-soc" in the body of a message to
> > majord...@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
>
>
Acked-by: Lukasz Majewski
Tested-by: Lukasz Majewski
Test HW: Odroid XU3 - Exynos5433
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] thermal: exynos: Fix unbalanced regulator disable on probe failure
Hi Alim,
> Hello,
>
> On Fri, Oct 9, 2015 at 4:28 PM, Krzysztof Kozlowski
> wrote:
> > W dniu 09.10.2015 o 01:45, Alim Akhtar pisze:
> >> Hello,
> >>
> >> On Thu, Oct 8, 2015 at 11:04 AM, Krzysztof Kozlowski
> >> wrote:
> >>> During probe if the regulator could not be enabled, the error
> >>> exit path would still disable it. This could lead to unbalanced
> >>> counter of regulator enable/disable.
> >>>
> >> Do you see a regulator unbalanced reported here during boot? You
> >> may want to add that to commit message.
> >
> > I did not see the warning/error message about unbalanced disable. It
> > would happen in certain condition only - no other enables of
> > regulator and count going below 0.
> >
> > I would have to simulate this error to get the warning message. I
> > don't think it is worth the effort.
> >
> Ok, looking at code, it does looks to be calling regulator disable in
> case regulator enable fails.
> Feel free to add
> Reviewed-by: Alim Akhtar
> Thanks!!
>
> > Best regards,
> > Krzysztof
> >
> >>
> >>> The patch moves code for getting and enabling the regulator from
> >>> exynos_map_dt_data() to probe function because it is really not a
> >>> part of getting Device Tree properties.
> >>>
> >>> Signed-off-by: Krzysztof Kozlowski
> >>> Fixes: 5f09a5cbd14a ("thermal: exynos: Disable the regulator on
> >>> probe failure") Cc:
> >>> ---
> >>> drivers/thermal/samsung/exynos_tmu.c | 34
> >>> +- 1 file changed, 17
> >>> insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >>> b/drivers/thermal/samsung/exynos_tmu.c index
> >>> 0bae8cc6c23a..23f4320f8ef7 100644 ---
> >>> a/drivers/thermal/samsung/exynos_tmu.c +++
> >>> b/drivers/thermal/samsung/exynos_tmu.c @@ -1168,27 +1168,10 @@
> >>> static int exynos_map_dt_data(struct platform_device *pdev)
> >>> struct exynos_tmu_data *data = platform_get_drvdata(pdev); struct
> >>> exynos_tmu_platform_data *pdata; struct resource res;
> >>> - int ret;
> >>>
> >>> if (!data || !pdev->dev.of_node)
> >>> return -ENODEV;
> >>>
> >>> - /*
> >>> -* Try enabling the regulator if found
> >>> -* TODO: Add regulator as an SOC feature, so that
> >>> regulator enable
> >>> -* is a compulsory call.
> >>> -*/
> >>> - data->regulator = devm_regulator_get(&pdev->dev, "vtmu");
> >>> - if (!IS_ERR(data->regulator)) {
> >>> - ret = regulator_enable(data->regulator);
> >>> - if (ret) {
> >>> - dev_err(&pdev->dev, "failed to enable
> >>> vtmu\n");
> >>> - return ret;
> >>> - }
> >>> - } else {
> >>> - dev_info(&pdev->dev, "Regulator node (vtmu) not
> >>> found\n");
> >>> - }
> >>> -
> >>> data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
> >>> if (data->id < 0)
> >>> data->id = 0;
> >>> @@ -1312,6 +1295,23 @@ static int exynos_tmu_probe(struct
> >>> platform_device *pdev) pr_err("thermal: tz: %p ERROR\n",
> >>> data->tzd); return PTR_ERR(data->tzd);
> >>> }
> >>> +
> >>> + /*
> >>> +* Try enabling the regulator if found
> >>> +* TODO: Add regulator as an SOC feature, so that
> >>> regulator enable
> >>> +* is a compulsory call.
> >>> +*/
> >>> + data->regulator = devm_regulator_get(&pdev->dev, "vtmu");
> >>> + if (!IS_ERR(data->regulator)) {
> >>> + ret = regulator_enable(data->regulator);
> >>> + if (ret) {
> >>> + dev_err(&pdev->dev, "failed to enable
> >>> vtmu\n");
> >>> + return ret;
> >>> + }
> >>> + } else {
> >>> + dev_info(&pdev->dev, "Regulator node (vtmu) not
> >>> found\n");
> >>> + }
> >>> +
> >>> ret = exynos_map_dt_data(pdev);
> >>> if (ret)
> >>> goto err_sensor;
> >>> --
> >>> 1.9.1
> >>>
> >>>
> >>> ___
> >>> linux-arm-kernel mailing list
> >>> linux-arm-ker...@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
> >>
> >>
> >
>
>
>
Acked-by: Lukasz Majewski
Tested-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] thermal: exynos: Remove unneeded semicolon
Hi Krzysztof, > Remove semicolons after switch statement. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/thermal/samsung/exynos_tmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/thermal/samsung/exynos_tmu.c > b/drivers/thermal/samsung/exynos_tmu.c index > eac6aebf82f3..1af7ea8dda71 100644 --- > a/drivers/thermal/samsung/exynos_tmu.c +++ > b/drivers/thermal/samsung/exynos_tmu.c @@ -548,7 +548,7 @@ static int > exynos5433_tmu_initialize(struct platform_device *pdev) default: > pdata->cal_type = TYPE_ONE_POINT_TRIMMING; > break; > - }; > + } > > dev_info(&pdev->dev, "Calibration type is %d-point > calibration\n", cal_type ? 2 : 1); > @@ -1356,7 +1356,7 @@ static int exynos_tmu_probe(struct > platform_device *pdev) break; > default: > break; > - }; > + } > > /* >* data->tzd must be registered before calling > exynos_tmu_initialize(), Acked-by: Lukasz Majewski Tested-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: exynos: fix register read in TMU
Hi Krzysztof,
> 2015-10-08 23:21 GMT+09:00 Sudip Mukherjee
> :
> > On Fri, Oct 02, 2015 at 08:43:52AM +0900, Krzysztof Kozlowski wrote:
> >> 2015-10-01 23:12 GMT+09:00 Sudip Mukherjee
> >> :
> >> > On Thu, Oct 01, 2015 at 10:18:57PM +0900, Krzysztof Kozlowski
> >> > wrote:
> >> >> 2015-10-01 20:39 GMT+09:00 Sudip Mukherjee
> >> >> :
> >> >> > The value of emul_con was getting overwritten if the selected
> >> >> > soc is SOC_ARCH_EXYNOS5260. And so as a result we were
> >> >> > reading from the wrong register in the case of
> >> >> > SOC_ARCH_EXYNOS5260.
> >> >>
> >> >> How the value is overwritten if the soc is Exynos5260? I can't
> >> >> see it (although the "else if" is still more obvious than "if"
> >> >> but how does the description match the code?).
> >> > The code here is:
> >> > if (data->soc == SOC_ARCH_EXYNOS5260)
> >> > emul_con = EXYNOS5260_EMUL_CON;
> >> > if (data->soc == SOC_ARCH_EXYNOS5433)
> >> > emul_con = EXYNOS5433_TMU_EMUL_CON;
> >> > else if (data->soc == SOC_ARCH_EXYNOS7)
> >> > emul_con = EXYNOS7_TMU_REG_EMUL_CON;
> >> > else
> >> > emul_con = EXYNOS_EMUL_CON;
> >> >
> >> > So if data->soc is SOC_ARCH_EXYNOS5260 , then emul_con becomes
> >> > EXYNOS5260_EMUL_CON. But again for the else part it will become
> >> > EXYNOS_EMUL_CON.
> >>
> >> Indeed!
> >>
> >> Fixes: 488c7455d74c ("thermal: exynos: Add the support for
> >> Exynos5433 TMU")
> >>
> >> Reviewed-by: Krzysztof Kozlowski
> >
> > Hi Krzysztof,
> > Who will pick this one up? I still do not see it in linux-next.
>
> Hi!
>
> I guess it is a patch for Lukasz.
>
> Lukasz,
> Do you plan to pick it up or maybe this should go through samsung-soc
> tree?
This is the only one patch, which is waiting in my queue. Since no more
fixes available, please feel free to grab this patch to samsung-soc.
Acked-by: Lukasz Majewski
>
> Best regards,
> Krzysztof
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 3/3] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = <&pwm 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+trip = <&cpu_alert2>;
+cooling-device = <&cpu0 13 13>;
+ };
+ map2 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+ };
+ map3 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+ };
+ map4 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 2/3] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
Signed-off-by: Lukasz Majewski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 1 0>;
+ };
+};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
&usb3503 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 0/3] dts: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. This patch is a resend of previously send series: https://lkml.org/lkml/2015/3/4/726 The "hwmon" part of this series has been already added to upstream. Unfortunately, the DTS files for Odroid U3 device have NOT been added to mainline repository. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: kernel_samsung -> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git kernel_samsung/for-next (Linux v4.2-rc1) SHA1: 366c21fdd7b1e71a47a6fa969f2e9a014c981aff Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (2): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 .../devicetree/bindings/hwmon/pwm-fan.txt | 29 ++- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ 2 files changed, 70 insertions(+), 2 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 1/3] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 29 --
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..c6d5332 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
- status = "okay";
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
pwms = <&pwm 0 1 0>;
+ cooling-levels = <0 102 170 230>;
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+thermal-sensors = <&tmu 0>;
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <10>; /*
millicelsius */
+ hysteresis = <2000>; /*
millicelsius */
+ type = "passive";
+ };
+};
+cooling-maps {
+ map0 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&fan0 0
1>;
+ };
+};
+ };
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] thermal: exynos: Fix minor issue
Hi Chanwoo, > This patch fixes the two minor issue. The first patch add the > CONFIG_THERMAL_OF dependency and second patch removes the unused code. > > Chanwoo Choi (2): > thermal: exynos: Add the dependency of CONFIG_THERMAL_OF instead of > CONFIG_OF thermal: exynos: Remove unused code related to > platform_data on probe() > > drivers/thermal/samsung/Kconfig | 2 +- > drivers/thermal/samsung/exynos_tmu.c | 3 --- > 2 files changed, 1 insertion(+), 4 deletions(-) > Thanks for your work. Applied to my tree: linux-samusng-thermal/fixes -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: exynos: Disable the regulator on probe failure
Hi Krzysztof,
> 2015-06-09 1:14 GMT+09:00 Lukasz Majewski :
> > Hi Krzysztof,
> >
> >> During probe the regulator (if present) was enabled but not
> >> disabled in case of failure. So an unsuccessful probe lead to
> >> enabling the regulator which was actually not needed because the
> >> device was not enabled.
> >>
> >> Additionally each deferred probe lead to increase of regulator
> >> enable count so it would not be effectively disabled during
> >> removal of the device.
> >
> > Thanks for catching this.
> >
> >>
> >> Signed-off-by: Krzysztof Kozlowski
> >> Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator
> >> defined at device tree") Cc:
> >>
> >> ---
> >>
> >> I am not entirely convinced that this should go to stable. Leaving
> >> a regulator enabled in case of probe failure (no exynos TMU
> >> device) or after deferred probe (regulator won't be disabled
> >> during device removal) is not a critical issue, just leaks power.
> >> ---
> >> drivers/thermal/samsung/exynos_tmu.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >> b/drivers/thermal/samsung/exynos_tmu.c index
> >> 531f4b179871..13c3aceed19d 100644 ---
> >> a/drivers/thermal/samsung/exynos_tmu.c +++
> >> b/drivers/thermal/samsung/exynos_tmu.c @@ -1392,6 +1392,8 @@
> >> err_clk_sec: if (!IS_ERR(data->clk_sec))
> >> clk_unprepare(data->clk_sec);
> >> err_sensor:
> >> + if (!IS_ERR_OR_NULL(data->regulator))
> >> + regulator_disable(data->regulator);
> >> thermal_zone_of_sensor_unregister(&pdev->dev, data->tzd);
> >>
> >> return ret;
> >
> > Acked-by: Lukasz Majewski
> >
> > I will test it and afterwards add to samsung-thermal tree.
>
> Hi Łukasz,
>
> I can't find this patch in v4.2-rc1 or your tree. What happened?
>
> Best regards,
> Krzysztof
Applied to linux-samsung-thermal.git
Thanks for fix and sorry for the delay.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Hi Sascha, > The thermal code uses int, long and unsigned long for temperatures > in different places. > > Using an unsigned type limits the thermal framework to positive > temperatures without need. Also several drivers currently will report > temperatures near UINT_MAX for temperatures below 0°C. This will > probably immediately shut the machine down due to overtemperature if > started below 0°C. > > 'long' is 64bit on several architectures. This is not needed since > INT_MAX °mC is above the melting point of all known materials. > > Consistently use a plain 'int' for temperatures throughout the > thermal code and the drivers. This only changes the places in the > drivers where the temperature is passed around as pointer, when > drivers internally use another type this is not changed. > > Signed-off-by: Sascha Hauer Sascha, thanks for this cleanup work. Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: exynos: Disable the regulator on probe failure
Hi Krzysztof,
> 2015-06-09 1:14 GMT+09:00 Lukasz Majewski :
> > Hi Krzysztof,
> >
> >> During probe the regulator (if present) was enabled but not
> >> disabled in case of failure. So an unsuccessful probe lead to
> >> enabling the regulator which was actually not needed because the
> >> device was not enabled.
> >>
> >> Additionally each deferred probe lead to increase of regulator
> >> enable count so it would not be effectively disabled during
> >> removal of the device.
> >
> > Thanks for catching this.
> >
> >>
> >> Signed-off-by: Krzysztof Kozlowski
> >> Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator
> >> defined at device tree") Cc:
> >>
> >> ---
> >>
> >> I am not entirely convinced that this should go to stable. Leaving
> >> a regulator enabled in case of probe failure (no exynos TMU
> >> device) or after deferred probe (regulator won't be disabled
> >> during device removal) is not a critical issue, just leaks power.
> >> ---
> >> drivers/thermal/samsung/exynos_tmu.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >> b/drivers/thermal/samsung/exynos_tmu.c index
> >> 531f4b179871..13c3aceed19d 100644 ---
> >> a/drivers/thermal/samsung/exynos_tmu.c +++
> >> b/drivers/thermal/samsung/exynos_tmu.c @@ -1392,6 +1392,8 @@
> >> err_clk_sec: if (!IS_ERR(data->clk_sec))
> >> clk_unprepare(data->clk_sec);
> >> err_sensor:
> >> + if (!IS_ERR_OR_NULL(data->regulator))
> >> + regulator_disable(data->regulator);
> >> thermal_zone_of_sensor_unregister(&pdev->dev, data->tzd);
> >>
> >> return ret;
> >
> > Acked-by: Lukasz Majewski
> >
> > I will test it and afterwards add to samsung-thermal tree.
>
> Hi Łukasz,
>
> I can't find this patch in v4.2-rc1 or your tree. What happened?
I will got together with Chanowoo patches. I will send PR today to
Eduardo.
>
> Best regards,
> Krzysztof
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
Hi Rafael,
> On Monday, June 08, 2015 10:31:00 AM Lukasz Majewski wrote:
> > Hi Viresh,
> >
> > > On 25-05-15, 07:39, Shailendra Verma wrote:
> > > > During probe free the memory allocated to "exynos_info" in case
> > > > of unknown SOC type.
> > > >
> > > > Signed-off-by: Shailendra Verma
> > > > ---
> > > > drivers/cpufreq/exynos-cpufreq.c |6 --
> > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > > > b/drivers/cpufreq/exynos-cpufreq.c index 82d2fbb..8682378 100644
> > > > --- a/drivers/cpufreq/exynos-cpufreq.c
> > > > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > > > @@ -182,7 +182,7 @@ static int exynos_cpufreq_probe(struct
> > > > platform_device *pdev) ret =
> > > > exynos5250_cpufreq_init(exynos_info); } else {
> > > > pr_err("%s: Unknown SoC type\n", __func__);
> > > > - return -ENODEV;
> > > > + ret = -ENODEV;
> > > > }
> > > >
> > > > if (ret)
> > > > @@ -190,12 +190,14 @@ static int exynos_cpufreq_probe(struct
> > > > platform_device *pdev)
> > > > if (exynos_info->set_freq == NULL) {
> > > > dev_err(&pdev->dev, "No set_freq function
> > > > (ERR)\n");
> > > > + ret = -EINVAL;
> > > > goto err_vdd_arm;
> > > > }
> > > >
> > > > arm_regulator = regulator_get(NULL, "vdd_arm");
> > > > if (IS_ERR(arm_regulator)) {
> > > > dev_err(&pdev->dev, "failed to get resource
> > > > vdd_arm\n");
> > > > + ret = -EINVAL;
> > > > goto err_vdd_arm;
> > > > }
> > > >
> > > > @@ -227,7 +229,7 @@ err_cpufreq_reg:
> > > > regulator_put(arm_regulator);
> > > > err_vdd_arm:
> > > > kfree(exynos_info);
> > > > - return -EINVAL;
> > > > + return ret;
> > > > }
> > > >
> > > > static struct platform_driver exynos_cpufreq_platdrv = {
> > >
> > > Acked-by: Viresh Kumar
> > >
> >
> > Acked-by: Lukasz Majewski
>
> I'm assuming that it will go it through the Samsung tree.
>
>
That would be the easiest way to proceed.
Krzystof would you like to grab this patch?
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: exynos: Disable the regulator on probe failure
Hi Krzysztof,
> During probe the regulator (if present) was enabled but not disabled
> in case of failure. So an unsuccessful probe lead to enabling the
> regulator which was actually not needed because the device was not
> enabled.
>
> Additionally each deferred probe lead to increase of regulator enable
> count so it would not be effectively disabled during removal of the
> device.
Thanks for catching this.
>
> Signed-off-by: Krzysztof Kozlowski
> Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator
> defined at device tree") Cc:
>
> ---
>
> I am not entirely convinced that this should go to stable. Leaving a
> regulator enabled in case of probe failure (no exynos TMU device) or
> after deferred probe (regulator won't be disabled during device
> removal) is not a critical issue, just leaks power.
> ---
> drivers/thermal/samsung/exynos_tmu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index
> 531f4b179871..13c3aceed19d 100644 ---
> a/drivers/thermal/samsung/exynos_tmu.c +++
> b/drivers/thermal/samsung/exynos_tmu.c @@ -1392,6 +1392,8 @@
> err_clk_sec: if (!IS_ERR(data->clk_sec))
> clk_unprepare(data->clk_sec);
> err_sensor:
> + if (!IS_ERR_OR_NULL(data->regulator))
> + regulator_disable(data->regulator);
> thermal_zone_of_sensor_unregister(&pdev->dev, data->tzd);
>
> return ret;
Acked-by: Lukasz Majewski
I will test it and afterwards add to samsung-thermal tree.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
Hi Anand, > Enable CONFIG_SND_SOC_ODROIDX2 and CONFIG_SND_SIMPLE_CARD to enable > sound on Odroid-XU3 board. > > Below is the output of boot log. > [6.021550] max98090 5-0010: MAX98090 REVID=0x43 > [6.025506] random: nonblocking pool is initialized > [6.047297] asoc-simple-card sound: HiFi <-> 383.i2s mapping ok > [6.068392] s5m-rtc s2mps14-rtc: setting system clock to > 2015-06-07 12:51:06 UTC (1433681466) [6.123650] ALSA device list: > [6.135203] #0: Odroid-XU3 > > Signed-off-by: Anand Moon > --- > arch/arm/configs/exynos_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig index 9504e77..1b7253b 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -144,6 +144,8 @@ CONFIG_SND=y > CONFIG_SND_SOC=y > CONFIG_SND_SOC_SAMSUNG=y > CONFIG_SND_SOC_SNOW=y > +CONFIG_SND_SOC_ODROIDX2=y > +CONFIG_SND_SIMPLE_CARD=y > CONFIG_USB=y > CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > CONFIG_USB_XHCI_HCD=y Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/2] ARM: exynos_defconfig: Enable CONFIG_LEDS_PWM for Odroid-XU3
Hi Anand, > Enable CONFIG_LEDS_PWM amd CONFIG_LEDS_TRIGGER_HEARTBEAT for > Odroid-XU3 board. > > Signed-off-by: Anand Moon > --- > arch/arm/configs/exynos_defconfig | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig index 1b7253b..2bbdf80 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -165,6 +165,12 @@ CONFIG_MMC_SDHCI_S3C_DMA=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_IDMAC=y > CONFIG_MMC_DW_EXYNOS=y > +CONFIG_NEW_LEDS=y > +CONFIG_LEDS_CLASS=m > +CONFIG_LEDS_PWM=m > +CONFIG_LEDS_TRIGGERS=y > +CONFIG_LEDS_TRIGGER_TIMER=m > +CONFIG_LEDS_TRIGGER_HEARTBEAT=m > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_MAX77686=y > CONFIG_RTC_DRV_MAX77802=y Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
Hi Viresh,
> On 25-05-15, 07:39, Shailendra Verma wrote:
> > During probe free the memory allocated to "exynos_info" in case of
> > unknown SOC type.
> >
> > Signed-off-by: Shailendra Verma
> > ---
> > drivers/cpufreq/exynos-cpufreq.c |6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > b/drivers/cpufreq/exynos-cpufreq.c index 82d2fbb..8682378 100644
> > --- a/drivers/cpufreq/exynos-cpufreq.c
> > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > @@ -182,7 +182,7 @@ static int exynos_cpufreq_probe(struct
> > platform_device *pdev) ret = exynos5250_cpufreq_init(exynos_info);
> > } else {
> > pr_err("%s: Unknown SoC type\n", __func__);
> > - return -ENODEV;
> > + ret = -ENODEV;
> > }
> >
> > if (ret)
> > @@ -190,12 +190,14 @@ static int exynos_cpufreq_probe(struct
> > platform_device *pdev)
> > if (exynos_info->set_freq == NULL) {
> > dev_err(&pdev->dev, "No set_freq function
> > (ERR)\n");
> > + ret = -EINVAL;
> > goto err_vdd_arm;
> > }
> >
> > arm_regulator = regulator_get(NULL, "vdd_arm");
> > if (IS_ERR(arm_regulator)) {
> > dev_err(&pdev->dev, "failed to get resource
> > vdd_arm\n");
> > + ret = -EINVAL;
> > goto err_vdd_arm;
> > }
> >
> > @@ -227,7 +229,7 @@ err_cpufreq_reg:
> > regulator_put(arm_regulator);
> > err_vdd_arm:
> > kfree(exynos_info);
> > - return -EINVAL;
> > + return ret;
> > }
> >
> > static struct platform_driver exynos_cpufreq_platdrv = {
>
> Acked-by: Viresh Kumar
>
Acked-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] thermal: exynos: Add the support for Exynos5433 TMU
Hi Chanwoo, > Hi Eduardo and Lukasz, > > I checked this patch merged on linux-next.git. > But, this patch is not merged on Linux 4.1-rc1. This is indeed strange. Eduardo do you have any idea why this patch is missing? > > Thanks, > Chanwoo Choi > > On 03/18/2015 04:39 PM, Lukasz Majewski wrote: > > Hi Chanwoo, > > > >> Hi Lukasz, > >> > >> Genlty Ping. > > > > I've got your patches at the back of my head :-) > > > > I will try to review them today or tomorrow. > > > >> > >> Best Regards, > >> Chanwoo Choi > >> -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Joonyoung,
> Hi Lukasz,
>
> On 04/17/2015 09:39 PM, Lukasz Majewski wrote:
> > Hi Joonyoung,
> >
> >> Hi Lukasz,
> >>
> >> On 04/15/2015 08:05 PM, Lukasz Majewski wrote:
> >>> Hi Joonyoung,
> >>>
> >>>> Hi Lukasz,
> >>>>
> >>>> On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
> >>>>> Hi Eduardo, Abhilash,
> >>>>>
> >>>>>> On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan
> >>>>>> wrote:
> >>>>>>> Hi Lukasz,
> >>>>>>>
> >>>>>>> On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
> >>>>>>> wrote:
> >>>>>>>> Hi Abhilash,
> >>>>>>>>
> >>>>>>>>> Hi Lukasz,
> >>>>>>>>>
> >>>>>>>>> On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
> >>>>>>>>> wrote:
> >>>>>>>>>> The exynos_map_dt_data() function must be called before
> >>>>>>>>>> thermal_zone_of_sensor_register(), and hence provide
> >>>>>>>>>> tmu_read() function, before it is needed.
> >>>>>>>>>>
> >>>>>>>>>> This change is driven by adding support for enabling
> >>>>>>>>>> thermal_zoneX when it is properly initialized.
> >>>>>>>>>>
> >>>>>>>>>> One can read the mode of operation
> >>>>>>>>>> at /sys/class/thermal/thermal_zone0/mode Such functionality
> >>>>>>>>>> was missing in the of-thermal.c code.
> >>>>>>>>>>
> >>>>>>>>>> Reported-by: Abhilash Kesavan
> >>>>>>>>>> Signed-off-by: Lukasz Majewski
> >>>>>>>>>> ---
> >>>>>>>>>> drivers/thermal/samsung/exynos_tmu.c | 7 ---
> >>>>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >>>>>>>>>> b/drivers/thermal/samsung/exynos_tmu.c index
> >>>>>>>>>> 9d2d685..5d946ab 100644 ---
> >>>>>>>>>> a/drivers/thermal/samsung/exynos_tmu.c +++
> >>>>>>>>>> b/drivers/thermal/samsung/exynos_tmu.c @@ -975,15 +975,16
> >>>>>>>>>> @@ static int exynos_tmu_probe(struct platform_device
> >>>>>>>>>> *pdev) platform_set_drvdata(pdev, data);
> >>>>>>>>>> mutex_init(&data->lock);
> >>>>>>>>>>
> >>>>>>>>>> + ret = exynos_map_dt_data(pdev);
> >>>>>>>>>> + if (ret)
> >>>>>>>>>> + goto err_sensor;
> >>>>
> >>>> It's enough to just return ret.
> >>>>
> >>>> One more, i think to need to take out regulator enable codes from
> >>>> exynos_map_dt_data. If not, can't restore about regulator when
> >>>> error occurs.
> >>>>
> >>>>>>>>>> +
> >>>>>>>>>> data->tzd =
> >>>>>>>>>> thermal_zone_of_sensor_register(&pdev->dev, 0, data,
> >>>>>>>>>> &exynos_sensor_ops); if (IS_ERR(data->tzd)) {
> >>>>>>>>>> pr_err("thermal: tz: %p ERROR\n",
> >>>>>>>>>> data->tzd); return PTR_ERR(data->tzd);
> >>>>>>>>>> }
> >>>>>>>>>> - ret = exynos_map_dt_data(pdev);
> >>>>>>>>>> - if (ret)
> >>>>>>>>>> - goto err_sensor;
> >>>>>>>>>>
> >>>>>>>>>> pdata = data->pdata;
> >>>>>>>>>
> >>>>>>>>> I have been testing this along with your v5 patch set and am
> >>>>>>>>> seeing incorrect temperature being reported at boot-up on
> >&
Re: [PATCH 6/8] clk: samsung: exynos5800: fix cpu clock configuration data
Hi Bartlomiej,
> Fix cpu clock configuration data for Exynos5800 (it uses
> higher PCLK_DBG divider values than Exynos5420 and supports
> additional frequencies).
>
> Based on Hardkernel's kernel for ODROID-XU3 board.
>
> Cc: Tomasz Figa
> Cc: Mike Turquette
> Cc: Javier Martinez Canillas
> Cc: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/clk/samsung/clk-exynos5420.c | 36
> +++--- 1 file changed, 33 insertions(+),
> 3 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c index 9398a2d..462aaee 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -1274,10 +1274,34 @@ static const struct exynos_cpuclk_cfg_data
> exynos5420_eglclk_d[] __initconst = { { 0 },
> };
>
> +static const struct exynos_cpuclk_cfg_data exynos5800_eglclk_d[]
> __initconst = {
> + { 200, E5420_EGL_DIV0(3, 7, 7, 4), },
> + { 190, E5420_EGL_DIV0(3, 7, 7, 4), },
> + { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
> + { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
> + { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
> + { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
> + { 100, E5420_EGL_DIV0(3, 7, 6, 2), },
> + { 90, E5420_EGL_DIV0(3, 7, 6, 2), },
> + { 80, E5420_EGL_DIV0(3, 7, 5, 2), },
> + { 70, E5420_EGL_DIV0(3, 7, 5, 2), },
> + { 60, E5420_EGL_DIV0(3, 7, 4, 2), },
> + { 50, E5420_EGL_DIV0(3, 7, 3, 2), },
> + { 40, E5420_EGL_DIV0(3, 7, 3, 2), },
> + { 30, E5420_EGL_DIV0(3, 7, 3, 2), },
> + { 20, E5420_EGL_DIV0(3, 7, 3, 2), },
> + { 0 },
> +};
> +
> #define E5420_KFC_DIV(kpll, pclk,
> aclk) \ kpll) << 24) |
> ((pclk) << 20) | ((aclk) << 4)))
> static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[]
> __initconst = {
> + { 140, E5420_KFC_DIV(3, 5, 3), }, /* for Exynos5800 */
> { 130, E5420_KFC_DIV(3, 5, 2), },
> { 120, E5420_KFC_DIV(3, 5, 2), },
> { 110, E5420_KFC_DIV(3, 5, 2), },
> @@ -1357,9 +1381,15 @@ static void __init exynos5x_clk_init(struct
> device_node *np, ARRAY_SIZE(exynos5800_gate_clks));
> }
>
> - exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
> - mout_cpu_p[0], mout_cpu_p[1], 0x200,
> - exynos5420_eglclk_d,
> ARRAY_SIZE(exynos5420_eglclk_d), 0);
> + if (soc == EXYNOS5420) {
> + exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
> + mout_cpu_p[0], mout_cpu_p[1], 0x200,
> + exynos5420_eglclk_d,
> ARRAY_SIZE(exynos5420_eglclk_d), 0);
> + } else {
> + exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
> + mout_cpu_p[0], mout_cpu_p[1], 0x200,
> + exynos5800_eglclk_d,
> ARRAY_SIZE(exynos5800_eglclk_d), 0);
> + }
> exynos_register_cpu_clock(ctx, CLK_KFC_CLK, "kfcclk",
> mout_kfc_p[0], mout_kfc_p[1], 0x28200,
> exynos5420_kfcclk_d,
> ARRAY_SIZE(exynos5420_kfcclk_d), 0);
Reviewed-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] ARM: Exynos: use generic cpufreq driver for Exynos5420
Hi Bartlomiej,
> From: Thomas Abraham
>
> The new CPU clock type allows the use of generic arm_big_little_dt
> cpufreq driver for Exynos5420.
>
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patch
> - disable cpufreq if big.LITTLE switcher support is enabled
>
> Cc: Tomasz Figa
> Cc: Kukjin Kim
> Cc: Javier Martinez Canillas
> Signed-off-by: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/mach-exynos/exynos.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/exynos.c
> b/arch/arm/mach-exynos/exynos.c index 4b03a32..11ac7fb 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -207,6 +207,13 @@ struct cpufreq_dt_platform_data cpufreq_dt_pd = {
> static const struct of_device_id exynos_cpufreq_matches[] = {
> { .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
> { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
> +/*
> + * FIXME: When big.LITTLE switcher is enabled system lockups during
> + * ondemand governor stress testing (observed on ODROID-XU3 board).
> + */
> +#ifndef CONFIG_BL_SWITCHER
> + { .compatible = "samsung,exynos5420", .data =
> "arm-bL-cpufreq-dt" }, +#endif
> { /* sentinel */ }
> };
>
Reviewed-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM: dts: Exynos5420: add CPU OPP and regulator supply property
Hi Bartlomiej,
> From: Thomas Abraham
>
> For Exynos5420 platforms, add CPU operating points and CPU
> regulator supply properties for migrating from Exynos specific
> cpufreq driver to using generic cpufreq driver.
>
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patch
>
> Cc: Kukjin Kim
> Cc: Doug Anderson
> Cc: Javier Martinez Canillas
> Cc: Andreas Faerber
> Cc: Sachin Kamat
> Signed-off-by: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 38
> + 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi index f67b23f..85b9cfc 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -59,8 +59,26 @@
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> + clocks = <&clock CLK_ARM_CLK>;
> + clock-names = "cpu-cluster.0";
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> + clock-latency = <14>;
> +
> + operating-points = <
> + 180 125
> + 170 1212500
> + 160 1175000
> + 150 1137500
> + 140 1112500
> + 130 1062500
> + 120 1037500
> + 110 1012500
> + 100 987500
> + 90 962500
> + 80 937500
> + 70 912500
> + >;
> };
>
> cpu1: cpu@1 {
> @@ -69,6 +87,7 @@
> reg = <0x1>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> + clock-latency = <14>;
> };
>
> cpu2: cpu@2 {
> @@ -77,6 +96,7 @@
> reg = <0x2>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> + clock-latency = <14>;
> };
>
> cpu3: cpu@3 {
> @@ -85,14 +105,29 @@
> reg = <0x3>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> + clock-latency = <14>;
> };
>
> cpu4: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <0x100>;
> + clocks = <&clock CLK_KFC_CLK>;
> + clock-names = "cpu-cluster.1";
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> + clock-latency = <14>;
> +
> + operating-points = <
> + 130 1275000
> + 120 1212500
> + 110 1162500
> + 100 1112500
> + 90 1062500
> + 80 1025000
> + 70 975000
> + 60 937500
> + >;
> };
>
> cpu5: cpu@101 {
> @@ -101,6 +136,7 @@
> reg = <0x101>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> + clock-latency = <14>;
> };
>
> cpu6: cpu@102 {
> @@ -109,6 +145,7 @@
> reg = <0x102>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> + clock-latency = <14>;
> };
>
> cpu7: cpu@103 {
> @@ -117,6 +154,7 @@
> reg = <0x103>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> + clock-latency = <14>;
> };
> };
>
Reviewed-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock
p[0], mout_kfc_p[1], 0x28200, > + exynos5420_kfcclk_d, > ARRAY_SIZE(exynos5420_kfcclk_d), 0); + > exynos5420_clk_sleep_init(); > > samsung_clk_of_add_provider(np, ctx); > diff --git a/include/dt-bindings/clock/exynos5420.h > b/include/dt-bindings/clock/exynos5420.h index 99da0d1..dde9664 100644 > --- a/include/dt-bindings/clock/exynos5420.h > +++ b/include/dt-bindings/clock/exynos5420.h > @@ -25,6 +25,8 @@ > #define CLK_FOUT_MPLL10 > #define CLK_FOUT_BPLL11 > #define CLK_FOUT_KPLL12 > +#define CLK_ARM_CLK 13 > +#define CLK_KFC_CLK 14 > > /* gate for special clocks (sclk) */ > #define CLK_SCLK_UART0 128 Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM: dts: add cluster regulator supply properties for exynos5422-odroidxu3
Hi Bartlomiej,
> Add cluster regulator supply properties as a preparation to
> adding generic arm_big_little_dt cpufreq driver support for
> ODROID-XU3 board.
>
> Cc: Kukjin Kim
> Cc: Doug Anderson
> Cc: Javier Martinez Canillas
> Cc: Andreas Faerber
> Cc: Sachin Kamat
> Cc: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3.dts |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index edc25cf..e876016
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -355,6 +355,14 @@
> dr_mode = "otg";
> };
>
> +&cpu0 {
> + cpu-cluster.0-supply = <&buck2_reg>;
> +};
> +
> +&cpu4 {
> + cpu-cluster.1-supply = <&buck6_reg>;
> +};
> +
> &i2c_0 {
> status = "okay";
>
Reviewed-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] cpufreq: arm_big_little: add cluster regulator support
rcu_read_unlock();
> + break;
> + }
> + opp_uV = dev_pm_opp_get_voltage(opp);
> + rcu_read_unlock();
> +
> + if
> (regulator_is_supported_voltage(reg[cluster], opp_uV,
> +opp_uV)) {
> + if (opp_uV < min_uV)
> + min_uV = opp_uV;
> + if (opp_uV > max_uV)
> + max_uV = opp_uV;
> + } else {
> + dev_pm_opp_disable(cpu_dev,
> opp_freq);
> + }
> +
> + opp_freq++;
> + }
> +
> + ret = regulator_set_voltage_time(reg[cluster],
> min_uV, max_uV);
> + if (ret > 0)
> + transition_latencies[cluster] = ret * 1000;
> + }
> +
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev,
> &freq_table[cluster]); if (ret) {
> dev_err(cpu_dev, "%s: failed to init cpufreq table,
> cpu: %d, err: %d\n", @@ -342,7 +455,6 @@ static int
> _get_cluster_clk_and_freq_table(struct device *cpu_dev) goto
> free_opp_table; }
>
> - name[12] = cluster + '0';
> clk[cluster] = clk_get(cpu_dev, name);
> if (!IS_ERR(clk[cluster])) {
> dev_dbg(cpu_dev, "%s: clk: %p & freq table: %p,
> cluster: %d\n", @@ -469,6 +581,11 @@ static int
> bL_cpufreq_init(struct cpufreq_policy *policy) else
> policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
>
> + if (cur_cluster < MAX_CLUSTERS &&
> + policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL)
> + policy->cpuinfo.transition_latency
> + += transition_latencies[cur_cluster];
> +
> if (is_bL_switching_enabled())
> per_cpu(cpu_last_req_freq, policy->cpu) =
> clk_get_cpu_rate(policy->cpu);
Reviewed-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Joonyoung,
> Hi Lukasz,
>
> On 04/15/2015 08:05 PM, Lukasz Majewski wrote:
> > Hi Joonyoung,
> >
> >> Hi Lukasz,
> >>
> >> On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
> >>> Hi Eduardo, Abhilash,
> >>>
> >>>> On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
> >>>>> Hi Lukasz,
> >>>>>
> >>>>> On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
> >>>>> wrote:
> >>>>>> Hi Abhilash,
> >>>>>>
> >>>>>>> Hi Lukasz,
> >>>>>>>
> >>>>>>> On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
> >>>>>>> wrote:
> >>>>>>>> The exynos_map_dt_data() function must be called before
> >>>>>>>> thermal_zone_of_sensor_register(), and hence provide
> >>>>>>>> tmu_read() function, before it is needed.
> >>>>>>>>
> >>>>>>>> This change is driven by adding support for enabling
> >>>>>>>> thermal_zoneX when it is properly initialized.
> >>>>>>>>
> >>>>>>>> One can read the mode of operation
> >>>>>>>> at /sys/class/thermal/thermal_zone0/mode Such functionality
> >>>>>>>> was missing in the of-thermal.c code.
> >>>>>>>>
> >>>>>>>> Reported-by: Abhilash Kesavan
> >>>>>>>> Signed-off-by: Lukasz Majewski
> >>>>>>>> ---
> >>>>>>>> drivers/thermal/samsung/exynos_tmu.c | 7 ---
> >>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >>>>>>>> b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab
> >>>>>>>> 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
> >>>>>>>> +++ b/drivers/thermal/samsung/exynos_tmu.c
> >>>>>>>> @@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
> >>>>>>>> platform_device *pdev) platform_set_drvdata(pdev, data);
> >>>>>>>> mutex_init(&data->lock);
> >>>>>>>>
> >>>>>>>> + ret = exynos_map_dt_data(pdev);
> >>>>>>>> + if (ret)
> >>>>>>>> + goto err_sensor;
> >>
> >> It's enough to just return ret.
> >>
> >> One more, i think to need to take out regulator enable codes from
> >> exynos_map_dt_data. If not, can't restore about regulator when
> >> error occurs.
> >>
> >>>>>>>> +
> >>>>>>>> data->tzd =
> >>>>>>>> thermal_zone_of_sensor_register(&pdev->dev, 0, data,
> >>>>>>>> &exynos_sensor_ops); if (IS_ERR(data->tzd)) {
> >>>>>>>> pr_err("thermal: tz: %p ERROR\n", data->tzd);
> >>>>>>>> return PTR_ERR(data->tzd);
> >>>>>>>> }
> >>>>>>>> - ret = exynos_map_dt_data(pdev);
> >>>>>>>> - if (ret)
> >>>>>>>> - goto err_sensor;
> >>>>>>>>
> >>>>>>>> pdata = data->pdata;
> >>>>>>>
> >>>>>>> I have been testing this along with your v5 patch set and am
> >>>>>>> seeing incorrect temperature being reported at boot-up on
> >>>>>>> exynos7.
> >>>>>>
> >>>>>> Does it show a maximal temperature value (0x1FF)?
> >>>>>
> >>>>> I did not print the current temperature register, but I remember
> >>>>> the message showing ~105C. Will give you the register value when
> >>>>> I test with more debug prints tomorrow.
> >>>>>
> >>>>>>
> >>>>>>> It looks
> >>>>>>> like exynos_tmu_read gets called from
> >>>>>>> thermal_zone_of_device_update during boot-up, now that we have
> >>>>>>> it populated early. However
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Joonyoung,
> Hi Lukasz,
>
> On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
> > Hi Eduardo, Abhilash,
> >
> >> On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
> >>> Hi Lukasz,
> >>>
> >>> On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
> >>> wrote:
> >>>> Hi Abhilash,
> >>>>
> >>>>> Hi Lukasz,
> >>>>>
> >>>>> On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
> >>>>> wrote:
> >>>>>> The exynos_map_dt_data() function must be called before
> >>>>>> thermal_zone_of_sensor_register(), and hence provide tmu_read()
> >>>>>> function, before it is needed.
> >>>>>>
> >>>>>> This change is driven by adding support for enabling
> >>>>>> thermal_zoneX when it is properly initialized.
> >>>>>>
> >>>>>> One can read the mode of operation
> >>>>>> at /sys/class/thermal/thermal_zone0/mode Such functionality was
> >>>>>> missing in the of-thermal.c code.
> >>>>>>
> >>>>>> Reported-by: Abhilash Kesavan
> >>>>>> Signed-off-by: Lukasz Majewski
> >>>>>> ---
> >>>>>> drivers/thermal/samsung/exynos_tmu.c | 7 ---
> >>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >>>>>> b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab
> >>>>>> 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
> >>>>>> +++ b/drivers/thermal/samsung/exynos_tmu.c
> >>>>>> @@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
> >>>>>> platform_device *pdev) platform_set_drvdata(pdev, data);
> >>>>>> mutex_init(&data->lock);
> >>>>>>
> >>>>>> + ret = exynos_map_dt_data(pdev);
> >>>>>> + if (ret)
> >>>>>> + goto err_sensor;
>
> It's enough to just return ret.
>
> One more, i think to need to take out regulator enable codes from
> exynos_map_dt_data. If not, can't restore about regulator when error
> occurs.
>
> >>>>>> +
> >>>>>> data->tzd =
> >>>>>> thermal_zone_of_sensor_register(&pdev->dev, 0, data,
> >>>>>> &exynos_sensor_ops); if (IS_ERR(data->tzd)) {
> >>>>>> pr_err("thermal: tz: %p ERROR\n", data->tzd);
> >>>>>> return PTR_ERR(data->tzd);
> >>>>>> }
> >>>>>> - ret = exynos_map_dt_data(pdev);
> >>>>>> - if (ret)
> >>>>>> - goto err_sensor;
> >>>>>>
> >>>>>> pdata = data->pdata;
> >>>>>
> >>>>> I have been testing this along with your v5 patch set and am
> >>>>> seeing incorrect temperature being reported at boot-up on
> >>>>> exynos7.
> >>>>
> >>>> Does it show a maximal temperature value (0x1FF)?
> >>>
> >>> I did not print the current temperature register, but I remember
> >>> the message showing ~105C. Will give you the register value when
> >>> I test with more debug prints tomorrow.
> >>>
> >>>>
> >>>>> It looks
> >>>>> like exynos_tmu_read gets called from
> >>>>> thermal_zone_of_device_update during boot-up, now that we have
> >>>>> it populated early. However, as the tmu initialization function
> >>>>> has not been called yet it returns a wrong value. Does that
> >>>>> sound correct ?
> >>>>
> >>>> No, this is a mistake. However, I'm wondering why on Exynos4/5
> >>>> this error didn't show up...
> >>>
> >>> I have been lowering the software trip point temperature in the
> >>> exynos7 dts file (to 55C) for testing purposes. Hence, when the
> >>> temperature is read incorrectly as ~105C the board trips at
> >>> boot-up
> >
> > this is a very unusual
> >
Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
Hi Anand,
> Hi Lukasz,
>
> On Odroidxu3 board critical temp is 85.0 C. Below is the sensors
> output.
Do you have XU3 with a fan?
>
> therm_zone0-virtual-0
> Adapter: Virtual device
> temp1: +39.0▒ၰC (crit = +85.0▒°C)
> temp2: +38.0▒°C (crit = +85.0▒°C)
> temp3: +40.0▒°C (crit = +85.0▒°C)
> temp4: +49.0▒°C (crit = +85.0▒°C)
> temp5: +29.0▒°C (crit = +85.0▒°C)
>
> I have observed cpu shutdown as we do test pm-qa thermal testing.
>
> So I propose the temperature values to be 5, 65000 ,8 and
> 85000 Critical temperature.
>
This seems strange - since other Samsung's SoC have higher work
temperatures (both exynos5 and exynos4).
I will try to check those thresholds on my XU3. Have anybody else
experienced overheating at XU3?
Sjoerd? Kukjin?
> Please share your thoughts.
>
> -Anand Moon
>
> On 8 April 2015 at 13:32, Lukasz Majewski
> wrote:
> > Hi Anand,
> >
> >> Move the registration of thermal sensors for tmu_cpu0 from
> >> exynos5420.dtsi to exynos5-cpu-thermal.dtsi, to avoid duplicate
> >> registration of the sensors.
> >>
> >> Tested on OdroidXU3 board.
> >>
> >> Signed-off-by: Anand Moon
> >> ---
> >> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi | 58
> >> ++
> >> arch/arm/boot/dts/exynos5420.dtsi | 4 ---
> >> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 1 + 3 files changed,
> >> 59 insertions(+), 4 deletions(-) create mode 100644
> >> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> >> b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi new file mode 100644
> >> index 000..8fede70
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> >> @@ -0,0 +1,58 @@
> >> +/*
> >> + * Device tree sources for Exynos5 thermal zone
> >> + *
> >> + * Copyright (c) 2014 Lukasz Majewski
> >
> > Could you update this
> > line :-). I'm just reviewer here :-)
> >
> >> + *
> >> + * 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.
> >> + *
> >> + */
> >> +
> >> +#include
> >> +
> >> +/ {
> >> + thermal-zones {
> >> + cpu0_thermal: cpu0-thermal {
> >> + thermal-sensors = <&tmu_cpu0>;
> >> + polling-delay-passive = <0>;
> >> + polling-delay = <0>;
> >> + trips {
> >> + cpu_alert0: cpu-alert-0 {
> >> + temperature = <48000>; /* ms
> >> */
> >> + hysteresis = <3000>; /* ms */
> > ^
> > We already
> > have "millicelsius"
> > instead od
> > ms
> >> + type = "active";
> >> + };
> >> + cpu_alert1: cpu-alert-1 {
> >> + temperature = <53000>; /* ms
> >> */
> >> + hysteresis = <3000>; /* ms */
> >> + type = "active";
> >> + };
> >> + cpu_alert2: cpu-alert-2 {
> >> + temperature = <59000>; /* ms
> >> */
> >> + hysteresis = <3000>; /* ms */
> >> + type = "active";
> >> + };
> >> + cpu_crit0: cpu-crit-0 {
> >> + temperature = <75000>; /* ms
> >> */
> >> + hysteresis = <0>; /* ms */
> >> + type = "critical";
> >
> > Is there any special reasons why we need special
> > values for
Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
Hi Anand,
> Below changes depend on following patch.
> https://patchwork.kernel.org/patch/5944061/
>
> Update the pwm_config with duty then update the pwm_disable
> to poweroff the cpu fan.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon
> ---
> drivers/hwmon/pwm-fan.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> index 7c83dc4..f25c841 100644
> --- a/drivers/hwmon/pwm-fan.c
> +++ b/drivers/hwmon/pwm-fan.c
> @@ -44,26 +44,24 @@ static int __set_pwm(struct pwm_fan_ctx *ctx,
> unsigned long pwm) int ret = 0;
>
> mutex_lock(&ctx->lock);
> +
> if (ctx->pwm_value == pwm)
> goto exit_set_pwm_err;
>
> - if (pwm == 0) {
> - pwm_disable(ctx->pwm);
> - goto exit_set_pwm;
> - }
> -
> duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
> ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
> if (ret)
> goto exit_set_pwm_err;
>
> + if (pwm == 0)
> + pwm_disable(ctx->pwm);
> +
> if (ctx->pwm_value == 0) {
> ret = pwm_enable(ctx->pwm);
> if (ret)
> goto exit_set_pwm_err;
> }
>
> -exit_set_pwm:
> ctx->pwm_value = pwm;
> exit_set_pwm_err:
> mutex_unlock(&ctx->lock);
Reviewed-by: Lukasz Majewski
BTW: I've added Guenter to CC.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling
Hi Anand,
> From: Sjoerd Simons
>
> When disabling the samsung PWM the output state remains at the level
> it was in the end of a pwm cycle. In other words, calling pwm_disable
> when at 100% duty will keep the output active, while at all other
> setting the output will go/stay inactive. On top of that the samsung
> PWM settings are double-buffered, which means the new settings only
> get applied at the start of a new PWM cycle.
>
> This results in a race if the PWM is at 100% duty and a driver calls:
> pwm_config (pwm, 0, period);
> pwm_disable (pwm);
>
> In this case the PWMs output will unexpectedly stay active, unless a
> new PWM cycle happened to start between the register writes in
> _config and _disable. As far as i can tell this is a regression
> introduced by 3bdf878, before that a call to pwm_config would call
> pwm_samsung_enable which, while heavy-handed, made sure the expected
> settings were live.
>
> To resolve this, while not re-introducing the issues 3bdf878
> (flickering as the PWM got reset while in a PWM cycle). Only force an
> update of the settings when at 100% duty, which shouldn't have a
> noticeable effect on the output but is enough to ensure the behaviour
> is as expected on disable.
>
> Signed-off-by: Sjoerd Simons
> Signed-off-by: Anand Moon
> ---
> drivers/pwm/pwm-samsung.c | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index 3e9b583..649f6c4 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip
> *chip, struct pwm_device *pwm)
> spin_unlock_irqrestore(&samsung_pwm_lock, flags); }
>
> +static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
> + struct pwm_device *pwm)
> +{
> + unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
> + u32 tcon;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&samsung_pwm_lock, flags);
> +
> + tcon = readl(chip->base + REG_TCON);
> + tcon |= TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, chip->base + REG_TCON);
> +
> + tcon &= ~TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, chip->base + REG_TCON);
> +
> + spin_unlock_irqrestore(&samsung_pwm_lock, flags);
> +}
> +
> static int pwm_samsung_config(struct pwm_chip *chip, struct
> pwm_device *pwm, int duty_ns, int period_ns)
> {
> struct samsung_pwm_chip *our_chip =
> to_samsung_pwm_chip(chip); struct samsung_pwm_channel *chan =
> pwm_get_chip_data(pwm);
> - u32 tin_ns = chan->tin_ns, tcnt, tcmp;
> + u32 tin_ns = chan->tin_ns, tcnt, tcmp, oldtcmp;
>
> /*
>* We currently avoid using 64bit arithmetic by using the
> @@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip
> *chip, struct pwm_device *pwm, return 0;
>
> tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
> + oldtcmp = readl(our_chip->base + REG_TCMPB(pwm->hwpwm));
>
> /* We need tick count for calculation, not last tick. */
> ++tcnt;
> @@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip
> *chip, struct pwm_device *pwm, writel(tcnt, our_chip->base +
> REG_TCNTB(pwm->hwpwm)); writel(tcmp, our_chip->base +
> REG_TCMPB(pwm->hwpwm));
> + /* In case the PWM is currently at 100% duty, force a manual
> update
Cosmetic comment:
Wasn't checkpatch complaining about this comment style?
/* .
* .
instead of:
/*
* .
* .
> + * to prevent the signal staying high in the pwm is disabled
> shortly
> + * afer this update (before it autoreloaded the new values) .
> + */
> + if (oldtcmp == (u32) -1) {
> + dev_dbg(our_chip->chip.dev, "Forcing manual update");
> + pwm_samsung_manual_update(our_chip, pwm);
> + }
> +
> chan->period_ns = period_ns;
> chan->tin_ns = tin_ns;
> chan->duty_ns = duty_ns;
Despite the above,
Acked-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.
Hi Anand,
> This commit enables TMU IP block on the Exynos5422 OdroidXU3
> device.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 25
> + 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index c8b3e3e..e1635b5
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -288,6 +288,31 @@
> #cooling-cells = <2>;
> cooling-levels = <0 90 130 170 230>;
> };
> +
> + tmu@1006 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@10064000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@10068000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@1006c000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@100a0000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> };
>
> &hdmi {
This seems correct. However please consider my comment to the previous
patch.
Acked-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
Hi Anand,
> Move the registration of thermal sensors for tmu_cpu0 from
> exynos5420.dtsi to exynos5-cpu-thermal.dtsi, to avoid duplicate
> registration of the sensors.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi | 58
> ++
> arch/arm/boot/dts/exynos5420.dtsi | 4 ---
> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 1 + 3 files changed, 59
> insertions(+), 4 deletions(-) create mode 100644
> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi new file mode 100644
> index 000..8fede70
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> @@ -0,0 +1,58 @@
> +/*
> + * Device tree sources for Exynos5 thermal zone
> + *
> + * Copyright (c) 2014 Lukasz Majewski
Could you update this
line :-). I'm just reviewer here :-)
> + *
> + * 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.
> + *
> + */
> +
> +#include
> +
> +/ {
> + thermal-zones {
> + cpu0_thermal: cpu0-thermal {
> + thermal-sensors = <&tmu_cpu0>;
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + trips {
> + cpu_alert0: cpu-alert-0 {
> + temperature = <48000>; /* ms
> */
> + hysteresis = <3000>; /* ms */
^
We already have
"millicelsius"
instead od ms
> + type = "active";
> + };
> + cpu_alert1: cpu-alert-1 {
> + temperature = <53000>; /* ms
> */
> + hysteresis = <3000>; /* ms */
> + type = "active";
> + };
> + cpu_alert2: cpu-alert-2 {
> + temperature = <59000>; /* ms
> */
> + hysteresis = <3000>; /* ms */
> + type = "active";
> + };
> + cpu_crit0: cpu-crit-0 {
> + temperature = <75000>; /* ms
> */
> + hysteresis = <0>; /* ms */
> + type = "critical";
Is there any special reasons why we need special values
for cpu0_thermal sensor at XU3? Is something wrong with
default values defined at exynos4-cpu-thermal.dtsi?
If this is Odroid XU3 specific, then IMHO it should be
added to exynos5422-odroidxu3.dts
> + };
> + };
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device = <&fan0 0 1>;
> + };
> + map1 {
> + trip = <&cpu_alert1>;
> + cooling-device = <&fan0 1 2>;
> + };
> + map2 {
> + trip = <&cpu_alert2>;
> + cooling-device = <&fan0 2 3>;
> + };
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi index 6b49f3c..eb0f16c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -827,10 +827,6 @@
> };
>
> thermal-zones {
> - cpu0_thermal: cpu0-thermal {
> - thermal-sensors = <&tmu_cpu0>;
> - #include "exynos5420-trip-points.dtsi"
^^^
Re: [PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0
Hi Anand,
> update the cooling level for cpu0 to avoid following message.
>
> root@odroidxu3:~# dmesg | grep ther
> [0.241511] /thermal-zones/cpu-thermal/cooling-maps/map0:
>could not get #cooling-cells for /cpus/cpu@0
>
> Signed-off-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi index c0e98cf..6b49f3c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -61,6 +61,10 @@
> reg = <0x0>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> +
> + cooling-min-level = <10>;
> + cooling-max-level = <7>;
> + #cooling-cells = <2>; /* min followed by max
> */ };
>
> cpu1: cpu@1 {
Acked-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.
Hi Anand,
> Add pwm-fan node to the OdroidXU3 board.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index a519c86..eaec006
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -278,6 +278,15 @@
> rtc@101E {
> status = "okay";
> };
> +
> + fan0: pwm-fan {
> + compatible = "pwm-fan";
> + pwms = <&pwm 0 20972 0>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + cooling-levels = <0 90 130 170 230>;
> + };
> };
>
> &hdmi {
> @@ -369,3 +378,10 @@
> shunt-resistor = <1>;
> };
> };
> +
> +&pwm {
> + pinctrl-0 = <&pwm0_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};
Acked-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 Resend] pwm: samsung: Fix output race on disabling
Hi Sjoerd,
> When disabling the samsung PWM the output state remains at the level
> it was in the end of a pwm cycle. In other words, calling pwm_disable
> when at 100% duty will keep the output active, while at all other
> setting the output will go/stay inactive. On top of that the samsung
> PWM settings are double-buffered, which means the new settings only
> get applied at the start of a new PWM cycle.
>
> This results in a race if the PWM is at 100% duty and a driver calls:
> pwm_config (pwm, 0, period);
> pwm_disable (pwm);
>
> In this case the PWMs output will unexpectedly stay active, unless a
> new PWM cycle happened to start between the register writes in
> _config and _disable. As far as i can tell this is a regression
> introduced by 3bdf878, before that a call to pwm_config would call
> pwm_samsung_enable which, while heavy-handed, made sure the expected
> settings were live.
>
> To resolve this, while not re-introducing the issues 3bdf878
> (flickering as the PWM got reset while in a PWM cycle). Only force an
> update of the settings when at 100% duty, which shouldn't have a
> noticeable effect on the output but is enough to ensure the behaviour
> is as expected on disable.
>
> Signed-off-by: Sjoerd Simons
> ---
> Changes since v1:
> Fix small issues pointed out by Tomasz Figa
> - Correct various coding style issues
> - Read the current value of the tcmp register for comparison rather
> then using a non-trivial comparison to decide whether the current
> state was 100% duty
> - Move the code to force manual update out into its own function
> - Clarify the comment indicating why a manual update is sometimes
> required
>
> drivers/pwm/pwm-samsung.c | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index 3e9b583..649f6c4 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip
> *chip, struct pwm_device *pwm)
> spin_unlock_irqrestore(&samsung_pwm_lock, flags); }
>
> +static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
> + struct pwm_device *pwm)
> +{
> + unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
> + u32 tcon;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&samsung_pwm_lock, flags);
> +
> + tcon = readl(chip->base + REG_TCON);
> + tcon |= TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, chip->base + REG_TCON);
> +
> + tcon &= ~TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, chip->base + REG_TCON);
> +
> + spin_unlock_irqrestore(&samsung_pwm_lock, flags);
> +}
> +
> static int pwm_samsung_config(struct pwm_chip *chip, struct
> pwm_device *pwm, int duty_ns, int period_ns)
> {
> struct samsung_pwm_chip *our_chip =
> to_samsung_pwm_chip(chip); struct samsung_pwm_channel *chan =
> pwm_get_chip_data(pwm);
> - u32 tin_ns = chan->tin_ns, tcnt, tcmp;
> + u32 tin_ns = chan->tin_ns, tcnt, tcmp, oldtcmp;
>
> /*
>* We currently avoid using 64bit arithmetic by using the
> @@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip
> *chip, struct pwm_device *pwm, return 0;
>
> tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
> + oldtcmp = readl(our_chip->base + REG_TCMPB(pwm->hwpwm));
>
> /* We need tick count for calculation, not last tick. */
> ++tcnt;
> @@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip
> *chip, struct pwm_device *pwm, writel(tcnt, our_chip->base +
> REG_TCNTB(pwm->hwpwm)); writel(tcmp, our_chip->base +
> REG_TCMPB(pwm->hwpwm));
> + /* In case the PWM is currently at 100% duty, force a manual
> update
> + * to prevent the signal staying high in the pwm is disabled
> shortly
> + * afer this update (before it autoreloaded the new values) .
> + */
> + if (oldtcmp == (u32) -1) {
> + dev_dbg(our_chip->chip.dev, "Forcing manual update");
> + pwm_samsung_manual_update(our_chip, pwm);
> + }
> +
> chan->period_ns = period_ns;
> chan->tin_ns = tin_ns;
> chan->duty_ns = duty_ns;
Acked-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] thermal: exynos: Add the support for Exynos5433 TMU
Hi Chanwoo,
> This patch adds the support for Exynos5433's TMU (Thermal Management
> Unit). Exynos5433 has a little different register bit fields as
> following description:
> - Support the eight trip points for rising/falling interrupt by using
> two registers
> - Read the calibration type (1-point or 2-point) and sensor id from
> TRIMINFO register
> - Use a little different register address
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Lukasz Majewski
> Signed-off-by: Chanwoo Choi
> ---
> Changes from v1:
> (https://lkml.org/lkml/2015/2/26/234)
> - Add exynos5433_tmu_control() instead of using exynos7_tmu_control()
> on both Exynos5433 and Exynos7.
> - Separate the patches related to devicetree and then send send
> Exnos5433's tmu patches[1] with other Exynos5433 devicetree patches.
> [1] https://lkml.org/lkml/2015/3/9/1036
>
> drivers/thermal/samsung/exynos_tmu.c | 187
> ++-
> drivers/thermal/samsung/exynos_tmu.h | 1 + 2 files changed, 186
> insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index 1d30b09..531f4b17 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -97,6 +97,32 @@
> #define EXYNOS4412_MUX_ADDR_VALUE 6
> #define EXYNOS4412_MUX_ADDR_SHIFT 20
>
> +/* Exynos5433 specific registers */
> +#define EXYNOS5433_TMU_REG_CONTROL1 0x024
> +#define EXYNOS5433_TMU_SAMPLING_INTERVAL 0x02c
> +#define EXYNOS5433_TMU_COUNTER_VALUE00x030
> +#define EXYNOS5433_TMU_COUNTER_VALUE10x034
> +#define EXYNOS5433_TMU_REG_CURRENT_TEMP1 0x044
> +#define EXYNOS5433_THD_TEMP_RISE3_0 0x050
> +#define EXYNOS5433_THD_TEMP_RISE7_4 0x054
> +#define EXYNOS5433_THD_TEMP_FALL3_0 0x060
> +#define EXYNOS5433_THD_TEMP_FALL7_4 0x064
> +#define EXYNOS5433_TMU_REG_INTEN 0x0c0
> +#define EXYNOS5433_TMU_REG_INTPEND 0x0c8
> +#define EXYNOS5433_TMU_EMUL_CON 0x110
> +#define EXYNOS5433_TMU_PD_DET_EN 0x130
> +
> +#define EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT 16
> +#define EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT 23
> +#define EXYNOS5433_TRIMINFO_SENSOR_ID_MASK \
> + (0xf << EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT)
> +#define EXYNOS5433_TRIMINFO_CALIB_SEL_MASK BIT(23)
> +
> +#define EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING 0
> +#define EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING 1
> +
> +#define EXYNOS5433_PD_DET_EN 1
> +
> /*exynos5440 specific registers*/
> #define EXYNOS5440_TMU_S0_7_TRIM 0x000
> #define EXYNOS5440_TMU_S0_7_CTRL 0x020
> @@ -484,6 +510,101 @@ out:
> return ret;
> }
>
> +static int exynos5433_tmu_initialize(struct platform_device *pdev)
> +{
> + struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> + struct exynos_tmu_platform_data *pdata = data->pdata;
> + struct thermal_zone_device *tz = data->tzd;
> + unsigned int status, trim_info;
> + unsigned int rising_threshold = 0, falling_threshold = 0;
> + unsigned long temp, temp_hist;
> + int ret = 0, threshold_code, i, sensor_id, cal_type;
> +
> + status = readb(data->base + EXYNOS_TMU_REG_STATUS);
> + if (!status) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
> + sanitize_temp_error(data, trim_info);
> +
> + /* Read the temperature sensor id */
> + sensor_id = (trim_info & EXYNOS5433_TRIMINFO_SENSOR_ID_MASK)
> + >>
> EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT;
> + dev_info(&pdev->dev, "Temperature sensor ID: 0x%x\n",
> sensor_id); +
> + /* Read the calibration mode */
> + writel(trim_info, data->base + EXYNOS_TMU_REG_TRIMINFO);
> + cal_type = (trim_info & EXYNOS5433_TRIMINFO_CALIB_SEL_MASK)
> + >>
> EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT; +
> + switch (cal_type) {
> + case EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING:
> + pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
> + break;
> + case EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING:
> + pdata->cal_type = TYPE_TWO_POINT_TRIMMING;
> + break;
> + default:
> + pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
> + break;
> + };
> +
> + dev_info(&pdev->dev, "Calibration type is %d-point
> calibration\n",
&g
Re: [PATCH v2 Resend] pwm: samsung: Fix output race on disabling
Hi Sjoerd,
> Hey Jingoo, Kukjijn, Lukasz,
>
> Pinging on this one again, could you please review this patch so it
> can be merged through the PWM tree?
As fair as I remember, I've already acked the patch :-)
>
> On Thu, 2015-03-05 at 09:14 +0100, Sjoerd Simons wrote:
> > When disabling the samsung PWM the output state remains at the
> > level it was in the end of a pwm cycle. In other words, calling
> > pwm_disable when at 100% duty will keep the output active, while at
> > all other setting the output will go/stay inactive. On top of that
> > the samsung PWM settings are double-buffered, which means the new
> > settings only get applied at the start of a new PWM cycle.
> >
> > This results in a race if the PWM is at 100% duty and a driver
> > calls: pwm_config (pwm, 0, period);
> > pwm_disable (pwm);
> >
> > In this case the PWMs output will unexpectedly stay active, unless
> > a new PWM cycle happened to start between the register writes in
> > _config and _disable. As far as i can tell this is a regression
> > introduced by 3bdf878, before that a call to pwm_config would call
> > pwm_samsung_enable which, while heavy-handed, made sure the
> > expected settings were live.
> >
> > To resolve this, while not re-introducing the issues 3bdf878
> > (flickering as the PWM got reset while in a PWM cycle). Only force
> > an update of the settings when at 100% duty, which shouldn't have a
> > noticeable effect on the output but is enough to ensure the
> > behaviour is as expected on disable.
> >
> > Signed-off-by: Sjoerd Simons
> > ---
> > Changes since v1:
> > Fix small issues pointed out by Tomasz Figa
> > - Correct various coding style issues
> > - Read the current value of the tcmp register for comparison
> > rather then using a non-trivial comparison to decide whether the
> > current state was 100% duty
> > - Move the code to force manual update out into its own function
> > - Clarify the comment indicating why a manual update is sometimes
> > required
> >
> > drivers/pwm/pwm-samsung.c | 31 ++-
> > 1 file changed, 30 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> > index 3e9b583..649f6c4 100644
> > --- a/drivers/pwm/pwm-samsung.c
> > +++ b/drivers/pwm/pwm-samsung.c
> > @@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct
> > pwm_chip *chip, struct pwm_device *pwm)
> > spin_unlock_irqrestore(&samsung_pwm_lock, flags); }
> >
> > +static void pwm_samsung_manual_update(struct samsung_pwm_chip
> > *chip,
> > + struct pwm_device *pwm)
> > +{
> > + unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
> > + u32 tcon;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&samsung_pwm_lock, flags);
> > +
> > + tcon = readl(chip->base + REG_TCON);
> > + tcon |= TCON_MANUALUPDATE(tcon_chan);
> > + writel(tcon, chip->base + REG_TCON);
> > +
> > + tcon &= ~TCON_MANUALUPDATE(tcon_chan);
> > + writel(tcon, chip->base + REG_TCON);
> > +
> > + spin_unlock_irqrestore(&samsung_pwm_lock, flags);
> > +}
> > +
> > static int pwm_samsung_config(struct pwm_chip *chip, struct
> > pwm_device *pwm, int duty_ns, int period_ns)
> > {
> > struct samsung_pwm_chip *our_chip =
> > to_samsung_pwm_chip(chip); struct samsung_pwm_channel *chan =
> > pwm_get_chip_data(pwm);
> > - u32 tin_ns = chan->tin_ns, tcnt, tcmp;
> > + u32 tin_ns = chan->tin_ns, tcnt, tcmp, oldtcmp;
> >
> > /*
> > * We currently avoid using 64bit arithmetic by using the
> > @@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip
> > *chip, struct pwm_device *pwm, return 0;
> >
> > tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
> > + oldtcmp = readl(our_chip->base + REG_TCMPB(pwm->hwpwm));
> >
> > /* We need tick count for calculation, not last tick. */
> > ++tcnt;
> > @@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip
> > *chip, struct pwm_device *pwm, writel(tcnt, our_chip->base +
> > REG_TCNTB(pwm->hwpwm)); writel(tcmp, our_chip->base +
> > REG_TCMPB(pwm->hwpwm));
> > + /* In case the PWM is currently at 100% duty, force a
> > manual update
> > +* to prevent the signal staying high in the pwm is
> > disabled shortly
> > +* afer this update (before it autoreloaded the new
> > values) .
> > +*/
> > + if (oldtcmp == (u32) -1) {
> > + dev_dbg(our_chip->chip.dev, "Forcing manual
> > update");
> > + pwm_samsung_manual_update(our_chip, pwm);
> > + }
> > +
> > chan->period_ns = period_ns;
> > chan->tin_ns = tin_ns;
> > chan->duty_ns = duty_ns;
>
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] thermal: exynos: Add the support for Exynos5433 TMU
Hi Chanwoo,
> Hi Lukasz,
>
> Genlty Ping.
I've got your patches at the back of my head :-)
I will try to review them today or tomorrow.
>
> Best Regards,
> Chanwoo Choi
>
> On 03/10/2015 11:23 AM, Chanwoo Choi wrote:
> > This patch adds the support for Exynos5433's TMU (Thermal
> > Management Unit). Exynos5433 has a little different register bit
> > fields as following description:
> > - Support the eight trip points for rising/falling interrupt by
> > using two registers
> > - Read the calibration type (1-point or 2-point) and sensor id from
> > TRIMINFO register
> > - Use a little different register address
> >
> > Cc: Zhang Rui
> > Cc: Eduardo Valentin
> > Cc: Lukasz Majewski
> > Signed-off-by: Chanwoo Choi
> > ---
> > Changes from v1:
> > (https://lkml.org/lkml/2015/2/26/234)
> > - Add exynos5433_tmu_control() instead of using
> > exynos7_tmu_control() on both Exynos5433 and Exynos7.
> > - Separate the patches related to devicetree and then send send
> > Exnos5433's tmu patches[1] with other Exynos5433 devicetree patches.
> > [1] https://lkml.org/lkml/2015/3/9/1036
> >
> > drivers/thermal/samsung/exynos_tmu.c | 187
> > ++-
> > drivers/thermal/samsung/exynos_tmu.h | 1 + 2 files changed, 186
> > insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c index 1d30b09..531f4b17
> > 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
> > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > @@ -97,6 +97,32 @@
> > #define EXYNOS4412_MUX_ADDR_VALUE 6
> > #define EXYNOS4412_MUX_ADDR_SHIFT 20
> >
> > +/* Exynos5433 specific registers */
> > +#define EXYNOS5433_TMU_REG_CONTROL10x024
> > +#define EXYNOS5433_TMU_SAMPLING_INTERVAL 0x02c
> > +#define EXYNOS5433_TMU_COUNTER_VALUE0 0x030
> > +#define EXYNOS5433_TMU_COUNTER_VALUE1 0x034
> > +#define EXYNOS5433_TMU_REG_CURRENT_TEMP1 0x044
> > +#define EXYNOS5433_THD_TEMP_RISE3_00x050
> > +#define EXYNOS5433_THD_TEMP_RISE7_40x054
> > +#define EXYNOS5433_THD_TEMP_FALL3_00x060
> > +#define EXYNOS5433_THD_TEMP_FALL7_40x064
> > +#define EXYNOS5433_TMU_REG_INTEN 0x0c0
> > +#define EXYNOS5433_TMU_REG_INTPEND 0x0c8
> > +#define EXYNOS5433_TMU_EMUL_CON0x110
> > +#define EXYNOS5433_TMU_PD_DET_EN 0x130
> > +
> > +#define EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT16
> > +#define EXYNOS5433_TRIMINFO_CALIB_SEL_SHIFT23
> > +#define EXYNOS5433_TRIMINFO_SENSOR_ID_MASK \
> > + (0xf <<
> > EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT) +#define
> > EXYNOS5433_TRIMINFO_CALIB_SEL_MASK BIT(23) +
> > +#define EXYNOS5433_TRIMINFO_ONE_POINT_TRIMMING 0
> > +#define EXYNOS5433_TRIMINFO_TWO_POINT_TRIMMING 1
> > +
> > +#define EXYNOS5433_PD_DET_EN 1
> > +
> > /*exynos5440 specific registers*/
> > #define EXYNOS5440_TMU_S0_7_TRIM 0x000
> > #define EXYNOS5440_TMU_S0_7_CTRL 0x020
> > @@ -484,6 +510,101 @@ out:
> > return ret;
> > }
> >
> > +static int exynos5433_tmu_initialize(struct platform_device *pdev)
> > +{
> > + struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> > + struct exynos_tmu_platform_data *pdata = data->pdata;
> > + struct thermal_zone_device *tz = data->tzd;
> > + unsigned int status, trim_info;
> > + unsigned int rising_threshold = 0, falling_threshold = 0;
> > + unsigned long temp, temp_hist;
> > + int ret = 0, threshold_code, i, sensor_id, cal_type;
> > +
> > + status = readb(data->base + EXYNOS_TMU_REG_STATUS);
> > + if (!status) {
> > + ret = -EBUSY;
> > + goto out;
> > + }
> > +
> > + trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
> > + sanitize_temp_error(data, trim_info);
> > +
> > + /* Read the temperature sensor id */
> > + sensor_id = (trim_info &
> > EXYNOS5433_TRIMINFO_SENSOR_ID_MASK)
> > + >>
> > EXYNOS5433_TRIMINFO_SENSOR_ID_SHIFT;
> > + dev_info(&pdev->dev, "Temperature sensor ID: 0x%x\n",
> > sensor_id); +
> > + /* Read the calibration mode */
> > + writel(trim_info, data->base + EXYNOS_TMU_REG_TRIMINFO);
> > + cal_type = (trim_info &
Re: [GIT PULL 2/2] Samsung fixes-2 for v4.0
Hi Kukjin, > Lukasz Majewski wrote: > > > > Hi Eduardo, > > > > > On Fri, Mar 06, 2015 at 07:16:53PM +0900, Kukjin Kim wrote: > > > > Arnd Bergmann wrote: > > > > > > > > > + Eduardo > > > > > > > > Hi Arnd, > > > > > > > > > On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote: > > > > > > Please pull Samsung tmu and hdmi regression fixes for v4.0 > > > > > > and I know this is quite big for fixes but I couldn't > > > > > > handle this series for previous merge window because of > > > > > > dependency with driver side...sorry for that and please > > > > > > pull so that we could support them in v4.0 on exynos > > > > > > platforms. > > > > > > > > > > What kind of dependency do you have there? It really should > > > > > not be necessary to wait for driver changes, unless you do an > > > > > incompatible DT binding change, which you should avoid. > > > > > > > > > For TMU patches, I've asked Eduardo to provide topic branch for > > > > 'include/dt-bindings/thermal/thermal_exynos.h' has been added > > > > via thermal tree because if I can't apply the patch in Samsung > > > > tree for arm-soc, kernel build breakage will be happened. But I > > > > couldn't get Eduardo's topic branch. > > > > > > > > > Specifically, the developer, while migrating the driver to > > > support DT and OF thermal, decided to create a header with > > > constants. The header is used by DT files and the driver code. > > > The header was the dependency. > > > > Just my 2 cents :-). > > > > The above situation is the justification for adding the whole patch > > set to one repository when all ACKs are collected for it. > > > I don't think so, even your series can be upstreamed though, other > useless merge conflicts would be happened so we decided all of DT > should be handled in arch side not driver side. So please don't argue > about that. Ok, I will not :-) > > - Kukjin > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] Samsung fixes-2 for v4.0
Hi Eduardo, > On Fri, Mar 06, 2015 at 07:16:53PM +0900, Kukjin Kim wrote: > > Arnd Bergmann wrote: > > > > > + Eduardo > > > > Hi Arnd, > > > > > On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote: > > > > Please pull Samsung tmu and hdmi regression fixes for v4.0 and > > > > I know this is quite big for fixes but I couldn't handle this > > > > series for previous merge window because of dependency with > > > > driver side...sorry for that and please pull so that we could > > > > support them in v4.0 on exynos platforms. > > > > > > What kind of dependency do you have there? It really should not be > > > necessary to wait for driver changes, unless you do an > > > incompatible DT binding change, which you should avoid. > > > > > For TMU patches, I've asked Eduardo to provide topic branch for > > 'include/dt-bindings/thermal/thermal_exynos.h' has been added via > > thermal tree because if I can't apply the patch in Samsung tree for > > arm-soc, kernel build breakage will be happened. But I couldn't get > > Eduardo's topic branch. > > > Specifically, the developer, while migrating the driver to support DT > and OF thermal, decided to create a header with constants. The header > is used by DT files and the driver code. The header was the > dependency. Just my 2 cents :-). The above situation is the justification for adding the whole patch set to one repository when all ACKs are collected for it. > > > BR, > > Eduardo Valentin > > > > > http://www.spinics.net/lists/linux-samsung-soc/msg41877.html > > > > > > For HDMI patches, I thought the DT changes have a dependency with > > "drm/exynos: add support for 'hdmi' clock" so waited for its > > applying then in drm tree. But I couldn't send it to arm-soc after > > that... > > > > http://www.spinics.net/lists/linux-samsung-soc/msg42173.html > > > > > > I asked about the situation (late DT changes?) when I sent a > > pull-request, then I couldn't get a access my kernel.org because of > > biz. trip to China :( > > > > http://www.spinics.net/lists/linux-samsung-soc/msg42235.html > > > > > > > I've pulled it into fixes, but won't forward it until I hear a > > > good explanation. > > > > > As you know, basically I tried to make a clear branch for > > pull-request but in that case, I couldn't find a solution. Sorry > > for the inconvenience. > > > > I hope v4.0 can support them properly. > > > > Thanks, > > Kukjin > > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
Changes for v6:
- cooling-{min|max}-state properties added to pwm-fan binding
- Mandatory properties for thermal-zones added
- Indentation fixed
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 29 --
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..c6d5332 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
- status = "okay";
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
pwms = <&pwm 0 1 0>;
+ cooling-levels = <0 102 170 230>;
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+thermal-sensors = <&tmu 0>;
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <10>; /*
millicelsius */
+ hysteresis = <2000>; /*
millicelsius */
+ type = "passive";
+ };
+};
+cooling-maps {
+ map0 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&fan0 0
1>;
+ };
+};
+ };
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = <&pwm 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+trip = <&cpu_alert2>;
+cooling-device = <&cpu0 13 13>;
+ };
+ map2 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+ };
+ map3 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+ };
+ map4 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
Signed-off-by: Lukasz Majewski
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski
- status = "okay"; dropped from the patch
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 1 0>;
+ };
+};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
&usb3503 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 4/6] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
Changes for v5:
- None
Changes for v6:
- None
---
drivers/hwmon/pwm-fan.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
};
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
- struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
- unsigned long pwm, duty;
- ssize_t ret;
-
- if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
- return -EINVAL;
+ unsigned long duty;
+ int ret = 0;
mutex_lock(&ctx->lock);
-
if (ctx->pwm_value == pwm)
- goto exit_set_pwm_no_change;
+ goto exit_set_pwm_err;
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
- ret = count;
exit_set_pwm_err:
mutex_unlock(&ctx->lock);
return ret;
}
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long pwm;
+ int ret;
+
+ if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
+ return -EINVAL;
+
+ ret = __set_pwm(ctx, pwm);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
Changes for v6:
- Adding missing ctx == NULL check in pwm_fan_get_max_state()
- Call to thermal_cooling_device_unregister(ctx->cdev); at pwm_fan_remove()
- struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
---
drivers/hwmon/pwm-fan.c | 89 -
1 file changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..7c83dc4 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -34,6 +35,7 @@ struct pwm_fan_ctx {
unsigned int pwm_fan_state;
unsigned int pwm_fan_max_state;
unsigned int *pwm_fan_cooling_levels;
+ struct thermal_cooling_device *cdev;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -68,6 +70,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +95,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +117,62 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(&cdev->device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -145,8 +215,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +264,21 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ &pwm_fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(&pdev->dev,
+
[PATCH RESEND v6 5/6] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when "cooling-levels" are defined in DT, but doesn't
have the value
Changes for v5:
- Use of of_find_property() to assess if "cooling-levels" was defined in
device tree
- Replace of_property_count_elems_of_size() with of_property_count_u32_elems()
- Remove ambiguity with returning error code from of_property_count_u32_elems()
- Return -EINVAL when "cooling-levels" has zero elements
Changes for v6:
- None
---
drivers/hwmon/pwm-fan.c | 50 -
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..e6ed353 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,46 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ if (!of_find_property(np, "cooling-levels", NULL))
+ return 0;
+
+ ret = of_property_count_u32_elems(np, "cooling-levels");
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret ? : -EINVAL;
+ }
+
+ num = ret;
+ ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx->pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
+ dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
+ ctx->pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx->pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +188,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx->pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND RESEND v6 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc2) SHA1: ad83a2d87bff355750a17dd00aec563eb9f9d388 Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 29 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 172 +++-- 4 files changed, 229 insertions(+), 17 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm64: dts: exynos: Add thermal-zones dt node for Exynos5433 SoC
};
> + apollo_alert_2: apollo-alert-2 {
> + temperature = <9>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + apollo_alert_3: apollo-alert-3 {
> + temperature = <95000>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + apollo_alert_4: apollo-alert-4 {
> + temperature = <10>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + apollo_alert_5: apollo-alert-5 {
> + temperature = <105000>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + apollo_alert_6: apollo-alert-6 {
> + temperature = <11>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + };
> + };
> +
> + isp_thermal: isp-thermal {
> + thermal-sensors = <&tmu_isp>;
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + trips {
> + isp_alert_0: isp-alert-0 {
> + temperature = <8>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + isp_alert_1: isp-alert-1 {
> + temperature = <85000>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + isp_alert_2: isp-alert-2 {
> + temperature = <9>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + isp_alert_3: isp-alert-3 {
> + temperature = <95000>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + isp_alert_4: isp-alert-4 {
> + temperature = <10>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + isp_alert_5: isp-alert-5 {
> + temperature = <105000>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + isp_alert_6: isp-alert-6 {
> + temperature = <11>; /*
> millicelsius */
> + hysteresis = <1>; /*
> millicelsius */
> + type = "active";
> + };
> + };
> + };
> +};
> +};
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi index b44ddcc..fbce27d
> 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -964,3 +964,4 @@
> };
>
> #include "exynos5433-pinctrl.dtsi"
> +#include "exynos5433-tmu.dtsi"
Reviewed-by: Lukasz Majewski
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm64: dts: exynos: Add TMU sensor dt node for Exynos5433 SoC
Hi Chanwoo,
> This patch adds the TMU (Thermal Management Unit) sensor devicetree
> node for Exynos5433. The Exynos5433 includes the five temperature
> sensors as following:
> - two temperature sensor for Cortex-A57 (ATLAS)
> - one temperature sensor for Cortex-A53 (APOLLO)
> - one temperature sensor for G3D IP
> - one temperature sensor for ISP IP
>
> Cc: Kukjin Kim
> Signed-off-by: Chanwoo Choi
> Acked-by: Inki Dae
> ---
> .../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 55
> ++ 2 files changed, 77 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
>
> diff --git
> a/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi new file
> mode 100644 index 000..396e60f --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
> @@ -0,0 +1,22 @@
> +/*
> + * Device tree sources for Exynos5433 TMU sensor configuration
> + *
> + * Copyright (c) 2015 Chanwoo Choi
> + *
> + * 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.
> + */
> +
> +#include
> +
> +#thermal-sensor-cells = <0>;
> +samsung,tmu_gain = <8>;
> +samsung,tmu_reference_voltage = <16>;
> +samsung,tmu_noise_cancel_mode = <4>;
> +samsung,tmu_efuse_value = <75>;
> +samsung,tmu_min_efuse_value = <40>;
> +samsung,tmu_max_efuse_value = <150>;
> +samsung,tmu_first_point_trim = <25>;
> +samsung,tmu_second_point_trim = <85>;
> +samsung,tmu_default_temp_offset = <50>;
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi index 0776b6d..b44ddcc
> 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -872,6 +872,61 @@
> status = "disabled";
> };
>
> + tmu_atlas0: tmu@1006 {
> + compatible = "samsung,exynos5433-tmu";
> + reg = <0x1006 0x200>;
> + interrupts = <0 95 0>;
> + clocks = <&cmu_peris CLK_PCLK_TMU0_APBIF>,
> + <&cmu_peris CLK_SCLK_TMU0>;
> + clock-names = "tmu_apbif", "tmu_sclk";
> + #include "exynos5433-tmu-sensor-conf.dtsi"
> + status = "disabled";
> + };
> +
> + tmu_atlas1: tmu@10068000 {
> + compatible = "samsung,exynos5433-tmu";
> + reg = <0x10068000 0x200>;
> + interrupts = <0 96 0>;
> + clocks = <&cmu_peris CLK_PCLK_TMU0_APBIF>,
> + <&cmu_peris CLK_SCLK_TMU0>;
> + clock-names = "tmu_apbif", "tmu_sclk";
> + #include "exynos5433-tmu-sensor-conf.dtsi"
> + status = "disabled";
> + };
> +
> + tmu_g3d: tmu@1007 {
> + compatible = "samsung,exynos5433-tmu";
> + reg = <0x1007 0x200>;
> + interrupts = <0 99 0>;
> + clocks = <&cmu_peris CLK_PCLK_TMU1_APBIF>,
> + <&cmu_peris CLK_SCLK_TMU1>;
> + clock-names = "tmu_apbif", "tmu_sclk";
> + #include "exynos5433-tmu-sensor-conf.dtsi"
> + status = "disabled";
> + };
> +
> + tmu_apollo: tmu@10078000 {
> + compatible = "samsung,exynos5433-tmu";
> + reg = <0x10078000 0x200>;
> + interrupts = <0 115 0>;
> + clocks = <&cmu_peris CLK_PCLK_TMU1_APBIF>,
> + <&cmu_peris CLK_SCLK_TMU1>;
> + clock-names = "tmu_apbif", "tmu_sclk";
> + #include "exynos5433-tmu-sensor-conf.dtsi"
> + status = "disabled";
> + };
> +
> + tmu_isp: tmu@1007c000 {
> + compatible = "samsung,exynos5433-tmu";
> +
Re: [PATCH 1/3] thermal: exynos: Add the support for Exynos5433 TMU
mu_match[] = { { .compatible = "samsung,exynos5260-tmu", },
> { .compatible = "samsung,exynos5420-tmu", },
> { .compatible = "samsung,exynos5420-tmu-ext-triminfo", },
> + { .compatible = "samsung,exynos5433-tmu", },
> { .compatible = "samsung,exynos5440-tmu", },
> { .compatible = "samsung,exynos7-tmu", },
> { /* sentinel */ },
> @@ -949,6 +1086,8 @@ static int exynos_of_get_soc_type(struct
> device_node *np) else if (of_device_is_compatible(np,
>"samsung,exynos5420-tmu-ext-triminfo"))
> return SOC_ARCH_EXYNOS5420_TRIMINFO;
> + else if (of_device_is_compatible(np,
> "samsung,exynos5433-tmu"))
> + return SOC_ARCH_EXYNOS5433;
> else if (of_device_is_compatible(np,
> "samsung,exynos5440-tmu")) return SOC_ARCH_EXYNOS5440;
> else if (of_device_is_compatible(np, "samsung,exynos7-tmu"))
> @@ -1069,6 +1208,13 @@ static int exynos_map_dt_data(struct
> platform_device *pdev) data->tmu_set_emulation =
> exynos4412_tmu_set_emulation; data->tmu_clear_irqs =
> exynos4210_tmu_clear_irqs; break;
> + case SOC_ARCH_EXYNOS5433:
> + data->tmu_initialize = exynos5433_tmu_initialize;
> + data->tmu_control = exynos7_tmu_control;
I must frankly admit that I'm a bit confused.
I'm curious why we didn't either define totally separate set of
exynos5433_tmu_* functions or reusing existing exynos7_tmu_* ?
Are exynos7 and exynos5433 so much different?
> + data->tmu_read = exynos4412_tmu_read;
> + data->tmu_set_emulation =
> exynos4412_tmu_set_emulation;
> + data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
> + break;
> case SOC_ARCH_EXYNOS5440:
> data->tmu_initialize = exynos5440_tmu_initialize;
> data->tmu_control = exynos5440_tmu_control;
> @@ -1172,7 +1318,9 @@ static int exynos_tmu_probe(struct
> platform_device *pdev) goto err_clk_sec;
> }
>
> - if (data->soc == SOC_ARCH_EXYNOS7) {
> + switch (data->soc) {
> + case SOC_ARCH_EXYNOS5433:
> + case SOC_ARCH_EXYNOS7:
> data->sclk = devm_clk_get(&pdev->dev, "tmu_sclk");
> if (IS_ERR(data->sclk)) {
> dev_err(&pdev->dev, "Failed to get sclk\n");
> @@ -1184,7 +1332,10 @@ static int exynos_tmu_probe(struct
> platform_device *pdev) goto err_clk;
> }
> }
> - }
> + break;
> + default:
> + break;
> + };
>
> ret = exynos_tmu_initialize(pdev);
> if (ret) {
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h index 4d71ec6..440c714 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -33,6 +33,7 @@ enum soc_type {
> SOC_ARCH_EXYNOS5260,
> SOC_ARCH_EXYNOS5420,
> SOC_ARCH_EXYNOS5420_TRIMINFO,
> + SOC_ARCH_EXYNOS5433,
> SOC_ARCH_EXYNOS5440,
> SOC_ARCH_EXYNOS7,
> };
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: exynos: Use simple approach to asses if cpu cooling can be used
Hi Eduardo,
> On Thu, Feb 26, 2015 at 11:36:24AM +0100, Lukasz Majewski wrote:
> > Hi Eduardo,
> >
> > > Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided
> > > possibility to use device tree to asses if cpu can be used as
> > > cooling device. Since the code was somewhat awkward, simpler
> > > approach has been proposed.
> > >
> > > Test HW: Exynos 4412 - Odroid U3.
> > >
> > > Suggested-by: Viresh Kumar
> > > Signed-off-by: Lukasz Majewski
> > > Acked-by: Viresh Kumar
> >
> > This patch is also missing from linux-thermal-soc tree.
> >
> > I will add it to samsung thermal tree, since Viresh has ACK'ed it.
>
> Do we have any dependency with something which is only in the thermal
> tree(s)? If not, I suggest the cpufreq changes go via cpufreq tree(s).
As fair as I remember, Viresh didn't mind if this patch would go via
thermal tree, since it is an integral part of the thermal solution for
Exynos.
Frankly, I'm for keeping all "related" patches in one tree
(especially when somebody already ACKed the patch) and not split them
into several trees.
Look how bad things look now with thermal DTS patches If we would
have taken them all at once, we hadn't had current problems.
Best regards,
Lukasz Majewski
>
>
> BR,
>
> Eduardo Valentin
>
> >
> > > ---
> > > Changes for v2:
> > > - Remove superfluous *np pointer
> > > ---
> > > drivers/cpufreq/exynos-cpufreq.c | 21 ++---
> > > 1 file changed, 6 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > > b/drivers/cpufreq/exynos-cpufreq.c index 5e98c6b..82d2fbb 100644
> > > --- a/drivers/cpufreq/exynos-cpufreq.c
> > > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > > @@ -159,7 +159,7 @@ static struct cpufreq_driver exynos_driver = {
> > >
> > > static int exynos_cpufreq_probe(struct platform_device *pdev)
> > > {
> > > - struct device_node *cpus, *np;
> > > + struct device_node *cpu0;
> > > int ret = -EINVAL;
> > >
> > > exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
> > > @@ -206,28 +206,19 @@ static int exynos_cpufreq_probe(struct
> > > platform_device *pdev) if (ret)
> > > goto err_cpufreq_reg;
> > >
> > > - cpus = of_find_node_by_path("/cpus");
> > > - if (!cpus) {
> > > - pr_err("failed to find cpus node\n");
> > > + cpu0 = of_get_cpu_node(0, NULL);
> > > + if (!cpu0) {
> > > + pr_err("failed to find cpu0 node\n");
> > > return 0;
> > > }
> > >
> > > - np = of_get_next_child(cpus, NULL);
> > > - if (!np) {
> > > - pr_err("failed to find cpus child node\n");
> > > - of_node_put(cpus);
> > > - return 0;
> > > - }
> > > -
> > > - if (of_find_property(np, "#cooling-cells", NULL)) {
> > > - cdev = of_cpufreq_cooling_register(np,
> > > + if (of_find_property(cpu0, "#cooling-cells", NULL)) {
> > > + cdev = of_cpufreq_cooling_register(cpu0,
> > > cpu_present_mask);
> > > if (IS_ERR(cdev))
> > > pr_err("running cpufreq without cooling
> > > device: %ld\n", PTR_ERR(cdev));
> > > }
> > > - of_node_put(np);
> > > - of_node_put(cpus);
> > >
> > > return 0;
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
pgphtauXOIr6g.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 00/18] thermal: exynos: Thermal code rework to use device tree
Hi Kukjin, > Lukasz Majewski wrote: > > > > Hi Kukjin, Eduardo > > > Hi, > > > > On 01/25/15 06:49, Eduardo Valentin wrote: > > > > On Fri, Jan 23, 2015 at 01:09:53PM +0100, Lukasz Majewski wrote: > > > >> 1. Introduction > > > >> > > > >> Following patches aim to clean up the current implementation of > > > >> the thermal framework on Exynos devices. > > > >> > > > >> The main goal was to use a generic code for reading thermal > > > >> configuration (of-thermal.c). Due to that redundant > > > >> exynos_thermal_common.[h|c] files were removed. > > > >> > > > >> Around 400 lines of code (LOC) were removed directly by this > > > >> patch, which is around 20% of the Exynos thermal code base. > > > >> > > > >> This work should NOT bring any functional changes to Exynos > > > >> thermal subsystem. > > > >> > > > >> 2. Patch-set structure > > > >> > > > >> Then the cpu_cooling functionality has been preserved to allow > > > >> cooling devices by reducing operating frequency. Definition of > > > >> trip points and cpufreq's cooling properties were moved to > > > >> device tree. > > > >> > > > >> Then the rework of the way in which configuration data is > > > >> provided to the Exynos thermal subsystem was performed. Now > > > >> device tree is used for configuration. > > > >> > > > >> 3. Dead code removal > > > >> > > > >> Thermal support for some SoCs, previously available in the > > > >> exynos_tmu_data.c file, was removed since, as of (almost) > > > >> 3.19-rc3, they didn't have TMU bindings. > > > >> > > > >> Moreover, support for cpu_cooling devices was preserved only on > > > >> those SoCs which had available and working cpufreq driver. > > > >> > > > >> 4. Testing > > > >> > > > >> Test devices: > > > >> - Exynos4210 - Trats (TMU zone + cpu_cooling) > > > >> - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) > > > >> - Exynos5250 - Arndale (TMU zone + cpu_cooling) > > > >> - Exynos5420 - Arndale-octa (only TMU zones) > > > >> > > > >> Unfortunately, I don't posses Exynos5440 for testing. Its > > > >> functionality has been preserved in the code, but not tested on > > > >> the hardware. I would be grateful for help in testing. > > > >> > > > >> > > > >> 5. This work apply on the following tree: > > > >> > > > >> kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree > > > >> SHA1: 1813d80874699145f04af6b05ebab0a6419001fb > > > >> > > > >> > > > >> Lukasz Majewski (18): > > > > > > > > I have applied the following patches to my -fixes branch (for > > > > next rc cycle) > > > > > > > >> thermal: exynos: cosmetic: Correct comment format > > > >> thermal: exynos: Provide thermal_exynos.h file to be > > > >> included in device tree files > > > >> thermal: exynos: Modify exynos thermal code to use device > > > >> tree for cpu cooling configuration > > > >> cpufreq: exynos: Use device tree to determine if cpufreq > > > >> cooling should be registered > > > >> dts: Documentation: Extending documentation entry for > > > >> exynos-thermal dts: Documentation: Update exynos-thermal.txt > > > >> example for Exynos5440 thermal: samsung: core: Exynos TMU > > > >> rework to use device tree for configuration > > > >> thermal: exynos: Remove exynos_thermal_common.[c|h] files > > > >> thermal: exynos: Remove exynos_tmu_data.c file > > > > > > > > The patches below should go via platform tree: > > > > > > > >> arm: dts: trats: Enable TMU on the Exynos4210 trats device > > > >> arm: dts: odroid: Add LDO10 regulator node necessary for TMU > > > >> on Odroid arm: dts: odroid: Enable TMU at Exynos4412 based > > > >> Odroid U3 device arm: dts: Adding CPU cooling binding for > > > >> Exynos SoCs thermal: exynos: dts: Add default definition of > > >
Re: [PATCH v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
Hi Guenter,
> On 02/26/2015 05:59 AM, Lukasz Majewski wrote:
> > The PWM FAN device can now be used as a thermal cooling device.
> > Necessary infrastructure has been added in this commit.
> >
> > Signed-off-by: Lukasz Majewski
> > Acked-by: Eduardo Valentin
> > ---
> > Changes for v2:
> > - Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
> > - Update ctx->pwm_fan_state when correct data from device tree is
> > available
> > - Using therma_cdev_update() when thermal is ready for controlling
> > the fan Changes for v3:
> > - Rename patch heading
> > - pwm_fan_of_get_cooling_data() now returns -EINVAL when no
> > "cooling-levels" property defined
> > - register of cooling device only when proper cooling data is
> > present Changes for v4:
> > - None
> > Changes for v5:
> > - Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent
> > from executing thermal_* specific functions
> > Changes for v6:
> > - Adding missing ctx == NULL check in pwm_fan_get_max_state()
> > - Call to thermal_cooling_device_unregister(ctx->cdev); at
> > pwm_fan_remove()
> > - struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
> > ---
> > drivers/hwmon/pwm-fan.c | 89
> > - 1 file changed,
> > 88 insertions(+), 1 deletion(-)
> [ ... ]
> >
> > @@ -200,6 +286,7 @@ static int pwm_fan_remove(struct
> > platform_device *pdev) {
> > struct pwm_fan_ctx *ctx = platform_get_drvdata(pdev);
> >
> > + thermal_cooling_device_unregister(ctx->cdev);
>
> Unfortunately there is still no prototype for this if CONFIG_THERMAL
> is not configured.
Yes... since Nishanth Menon's changes are now only in
linux-soc-thermal/fixes
>
> Two options: Yet another revision, or wait a week until the prototypes
> are (hopefully) available and submit a patch without the conditionals.
No problem, I will wait a bit and resend this patch set.
>
> Guenter
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = <&pwm 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+trip = <&cpu_alert2>;
+cooling-device = <&cpu0 13 13>;
+ };
+ map2 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+ };
+ map3 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+ };
+ map4 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
Signed-off-by: Lukasz Majewski
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski
- status = "okay"; dropped from the patch
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 1 0>;
+ };
+};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
&usb3503 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
Changes for v6:
- Adding missing ctx == NULL check in pwm_fan_get_max_state()
- Call to thermal_cooling_device_unregister(ctx->cdev); at pwm_fan_remove()
- struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
---
drivers/hwmon/pwm-fan.c | 89 -
1 file changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..7c83dc4 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -34,6 +35,7 @@ struct pwm_fan_ctx {
unsigned int pwm_fan_state;
unsigned int pwm_fan_max_state;
unsigned int *pwm_fan_cooling_levels;
+ struct thermal_cooling_device *cdev;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -68,6 +70,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +95,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +117,62 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(&cdev->device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -145,8 +215,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +264,21 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ &pwm_fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(&pdev->dev,
+
[PATCH v6 4/6] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
Changes for v5:
- None
Changes for v6:
- None
---
drivers/hwmon/pwm-fan.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
};
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
- struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
- unsigned long pwm, duty;
- ssize_t ret;
-
- if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
- return -EINVAL;
+ unsigned long duty;
+ int ret = 0;
mutex_lock(&ctx->lock);
-
if (ctx->pwm_value == pwm)
- goto exit_set_pwm_no_change;
+ goto exit_set_pwm_err;
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
- ret = count;
exit_set_pwm_err:
mutex_unlock(&ctx->lock);
return ret;
}
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long pwm;
+ int ret;
+
+ if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
+ return -EINVAL;
+
+ ret = __set_pwm(ctx, pwm);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/6] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when "cooling-levels" are defined in DT, but doesn't
have the value
Changes for v5:
- Use of of_find_property() to assess if "cooling-levels" was defined in
device tree
- Replace of_property_count_elems_of_size() with of_property_count_u32_elems()
- Remove ambiguity with returning error code from of_property_count_u32_elems()
- Return -EINVAL when "cooling-levels" has zero elements
Changes for v6:
- None
---
drivers/hwmon/pwm-fan.c | 50 -
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..e6ed353 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,46 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ if (!of_find_property(np, "cooling-levels", NULL))
+ return 0;
+
+ ret = of_property_count_u32_elems(np, "cooling-levels");
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret ? : -EINVAL;
+ }
+
+ num = ret;
+ ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx->pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
+ dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
+ ctx->pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx->pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +188,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx->pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc1) SHA1: b71d399c7f2fe06b60b96155ec0b9ae167334e4a Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 29 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 172 +++-- 4 files changed, 229 insertions(+), 17 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
Changes for v6:
- cooling-{min|max}-state properties added to pwm-fan binding
- Mandatory properties for thermal-zones added
- Indentation fixed
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 29 --
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..c6d5332 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
- status = "okay";
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
pwms = <&pwm 0 1 0>;
+ cooling-levels = <0 102 170 230>;
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+thermal-sensors = <&tmu 0>;
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <10>; /*
millicelsius */
+ hysteresis = <2000>; /*
millicelsius */
+ type = "passive";
+ };
+};
+cooling-maps {
+ map0 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&fan0 0
1>;
+ };
+};
+ };
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: exynos: Use simple approach to asses if cpu cooling can be used
Hi Eduardo,
> Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided possibility
> to use device tree to asses if cpu can be used as cooling device.
> Since the code was somewhat awkward, simpler approach has been
> proposed.
>
> Test HW: Exynos 4412 - Odroid U3.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Lukasz Majewski
> Acked-by: Viresh Kumar
This patch is also missing from linux-thermal-soc tree.
I will add it to samsung thermal tree, since Viresh has ACK'ed it.
> ---
> Changes for v2:
> - Remove superfluous *np pointer
> ---
> drivers/cpufreq/exynos-cpufreq.c | 21 ++---
> 1 file changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c index 5e98c6b..82d2fbb 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -159,7 +159,7 @@ static struct cpufreq_driver exynos_driver = {
>
> static int exynos_cpufreq_probe(struct platform_device *pdev)
> {
> - struct device_node *cpus, *np;
> + struct device_node *cpu0;
> int ret = -EINVAL;
>
> exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
> @@ -206,28 +206,19 @@ static int exynos_cpufreq_probe(struct
> platform_device *pdev) if (ret)
> goto err_cpufreq_reg;
>
> - cpus = of_find_node_by_path("/cpus");
> - if (!cpus) {
> - pr_err("failed to find cpus node\n");
> + cpu0 = of_get_cpu_node(0, NULL);
> + if (!cpu0) {
> + pr_err("failed to find cpu0 node\n");
> return 0;
> }
>
> - np = of_get_next_child(cpus, NULL);
> - if (!np) {
> - pr_err("failed to find cpus child node\n");
> - of_node_put(cpus);
> - return 0;
> - }
> -
> - if (of_find_property(np, "#cooling-cells", NULL)) {
> - cdev = of_cpufreq_cooling_register(np,
> + if (of_find_property(cpu0, "#cooling-cells", NULL)) {
> + cdev = of_cpufreq_cooling_register(cpu0,
> cpu_present_mask);
> if (IS_ERR(cdev))
> pr_err("running cpufreq without cooling
> device: %ld\n", PTR_ERR(cdev));
> }
> - of_node_put(np);
> - of_node_put(cpus);
>
> return 0;
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/6] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
Changes for v5:
- None
---
drivers/hwmon/pwm-fan.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
};
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
- struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
- unsigned long pwm, duty;
- ssize_t ret;
-
- if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
- return -EINVAL;
+ unsigned long duty;
+ int ret = 0;
mutex_lock(&ctx->lock);
-
if (ctx->pwm_value == pwm)
- goto exit_set_pwm_no_change;
+ goto exit_set_pwm_err;
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
- ret = count;
exit_set_pwm_err:
mutex_unlock(&ctx->lock);
return ret;
}
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long pwm;
+ int ret;
+
+ if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
+ return -EINVAL;
+
+ ret = __set_pwm(ctx, pwm);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
Signed-off-by: Lukasz Majewski
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski
- status = "okay"; dropped from the patch
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 1 0>;
+ };
+};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
&usb3503 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 25 +-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..645251b 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
status = "okay";
pwms = <&pwm 0 1 0>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 0 1>;
+ };
+ };
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc1) SHA1: b71d399c7f2fe06b60b96155ec0b9ae167334e4a Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 25 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 166 +++-- 4 files changed, 220 insertions(+), 16 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = <&pwm 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+trip = <&cpu_alert2>;
+cooling-device = <&cpu0 13 13>;
+ };
+ map2 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+ };
+ map3 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+ };
+ map4 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/6] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when "cooling-levels" are defined in DT, but doesn't
have the value
Changes for v5:
- Use of of_find_property() to assess if "cooling-levels" was defined in
device tree
- Replace of_property_count_elems_of_size() with of_property_count_u32_elems()
- Remove ambiguity with returning error code from of_property_count_u32_elems()
- Return -EINVAL when "cooling-levels" has zero elements
---
drivers/hwmon/pwm-fan.c | 50 -
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..e6ed353 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,46 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ if (!of_find_property(np, "cooling-levels", NULL))
+ return 0;
+
+ ret = of_property_count_u32_elems(np, "cooling-levels");
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret ? : -EINVAL;
+ }
+
+ num = ret;
+ ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx->pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
+ dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
+ ctx->pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx->pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +188,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx->pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
---
drivers/hwmon/pwm-fan.c | 83 -
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..2c1a8f0 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -68,6 +69,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(&cdev->device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -145,8 +211,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +260,20 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ &pwm_fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(&pdev->dev,
+ "Failed to register pwm-fan as cooling device");
+ pwm_disable(ctx->pwm);
+ return PTR_ERR(cdev);
+ }
+ thermal_cdev_update(cdev);
+ }
+
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
Hi Eduardo,
> On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
> > With those bindings it is possible to use pwm-fan device available
> > in Odroid U3 as a cooling device.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Rename cooling-pwm-values property to cooling-levels
> > Changes for v3:
> > - Change patch's topic to "ARM dts"
> > - Reduce maximal cooling-level to 230 from 255
> > Changes for v4:
> > - None
> > ---
> > arch/arm/boot/dts/exynos4412-odroidu3.dts | 33
> > ++- 1 file changed, 32 insertions(+), 1
> > deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> > b/arch/arm/boot/dts/exynos4412-odroidu3.dts index 60bd1e4..3e5df3e
> > 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> > +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> > @@ -32,11 +32,42 @@
> > };
> > };
> >
> > - pwm-fan {
> > + fan0: pwm-fan {
> > compatible = "pwm-fan";
> > pwms = <&pwm 0 1 0>;
> > + cooling-min-state = <0>;
> > + cooling-max-state = <3>;
> > + #cooling-cells = <2>;
> > + cooling-levels = <0 102 170 230>;
> > status = "okay";
> > };
> > +
> > + thermal-zones {
> > + cpu_thermal: cpu-thermal {
>
>
> This thermal zone misses the mandatory properties as per
> Documentation/devicetree/bindings/thermal/thermal.txt
Following mandatory properties:
thermal-sensors = <&tmu 0>;
polling-delay-passive = <0>;
polling-delay = <0>;
trips {
}
are defined in exynos4-cpu-thermal.dtsi included by this file.
In this patch only device dependent changes are stated.
>
> > + cooling-maps {
> > + map0 {
> > +trip = <&cpu_alert1>;
> > +cooling-device = <&cpu0 7 7>;
> > + };
> > + map1 {
> > +trip = <&cpu_alert2>;
> > +cooling-device = <&cpu0 13
> > 13>;
> > + };
> > + map2 {
> > +trip = <&cpu_alert0>;
> > +cooling-device = <&fan0 0 1>;
> > + };
> > + map3 {
> > + trip = <&cpu_alert1>;
> > +cooling-device = <&fan0 1 2>;
> > + };
> > + map4 {
> > +trip = <&cpu_alert2>;
> > +cooling-device = <&fan0 2 3>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
> > &pwm {
> > --
> > 2.0.0.rc2
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
Hi Eduardo,
> On Wed, Feb 18, 2015 at 11:07:29AM +0100, Lukasz Majewski wrote:
> > Odroid U3 fan can work without being registered as OF cooling device
> > (with CONFIG_THERMAL_OF disabled).
> > In this situation it can be controlled via PWM entry at
> > /sys/class/hwmon/hwmon0/pwm1.
> >
> > Therefore, the thermal_of_cooling_device_register() function needs
> > a stub to allow clean compilation.
>
>
> I've just applied a patch on this same matter from Nishanth Menon [1].
> Can you please check if his patch is enough for you?
>
> [1] -
> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixes&id=12ca7188468ee29c4e717f73db4bf43c90954fc7
>
I will prepare new PWM-FAN patch set with above changes in mind.
>
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - None
> > Changes for v3:
> > - Provide stub declaration when CONFIG_THERMAL is not set
> > Changes for v4:
> > - None
> > ---
> > include/linux/thermal.h | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > index fc52e30..eacf2de 100644
> > --- a/include/linux/thermal.h
> > +++ b/include/linux/thermal.h
> > @@ -293,6 +293,20 @@ struct thermal_trip {
> > };
> >
> > /* Function declarations */
> > +#ifdef CONFIG_THERMAL
> > +struct thermal_cooling_device *
> > +thermal_of_cooling_device_register(struct device_node *np,
> > + char *type, void *devdata,
> > + const struct
> > thermal_cooling_device_ops *); +#else
> > +static inline struct thermal_cooling_device *
> > +thermal_of_cooling_device_register(struct device_node *np,
> > + char *type, void *devdata,
> > + const struct
> > thermal_cooling_device_ops *ops) +{
> > + return NULL;
> > +}
> > +#endif
> > #ifdef CONFIG_THERMAL_OF
> > struct thermal_zone_device *
> > thermal_zone_of_sensor_register(struct device *dev, int id, void
> > *data, @@ -328,9 +342,6 @@ void thermal_zone_device_update(struct
> > thermal_zone_device *);
> > struct thermal_cooling_device
> > *thermal_cooling_device_register(char *, void *, const struct
> > thermal_cooling_device_ops *); -struct thermal_cooling_device *
> > -thermal_of_cooling_device_register(struct device_node *np, char *,
> > void *,
> > - const struct
> > thermal_cooling_device_ops *); void
> > thermal_cooling_device_unregister(struct thermal_cooling_device *);
> > struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> > char *name); int thermal_zone_get_temp(struct thermal_zone_device
> > *tz, unsigned long *temp); -- 2.0.0.rc2
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7
Hi Eduardo,
> Hi Lukasz,
>
> On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski
> wrote:
> > Hi Abhilash,
> >
> >> This patch fixes the wrong control of PD_DET_EN (power down
> >> detection mode) for Exynos7 because exynos7_tmu_control() always
> >> enables the power down detection mode regardless 'on' parameter.
> >>
> >> Cc: Zhang Rui
> >> Cc: Eduardo Valentin
> >> Signed-off-by: Chanwoo Choi
> >> ---
> >> drivers/thermal/samsung/exynos_tmu.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >> b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527
> >> 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
> >> +++ b/drivers/thermal/samsung/exynos_tmu.c
> >> @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
> >> platform_device *pdev, bool on)
> >> if (on) {
> >> con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
> >> + con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
> >> interrupt_en =
> >> (of_thermal_is_trip_valid(tz, 7)
> >> << EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
> >> @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
> >> platform_device *pdev, bool on) interrupt_en <<
> >> EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
> >> con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
> >> + con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
> >> interrupt_en = 0; /* Disable all interrupts */
> >> }
> >> - con |= 1 << EXYNOS7_PD_DET_EN_SHIFT;
> >>
> >> writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
> >> writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
> >
> > Could you test this patch if it isn't introducing any regression on
> > your HW?
>
> The patch does not cause any regression on exynos7 and seems
> logically correct.
>
> Tested-by: Abhilash Kesavan
>
Eduardo, it is up to you if you prefer to take this fix directly or via
the new thermal-samsung tree ?
>From when shall I regard myself as a maintainer? :-)
>
> Regards,
> Abhilash
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7
Hi Abhilash,
> This patch fixes the wrong control of PD_DET_EN (power down detection
> mode) for Exynos7 because exynos7_tmu_control() always enables the
> power down detection mode regardless 'on' parameter.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Chanwoo Choi
> ---
> drivers/thermal/samsung/exynos_tmu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
> platform_device *pdev, bool on)
> if (on) {
> con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
> + con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
> interrupt_en =
> (of_thermal_is_trip_valid(tz, 7)
> << EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
> @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
> platform_device *pdev, bool on) interrupt_en <<
> EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
> con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
> + con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
> interrupt_en = 0; /* Disable all interrupts */
> }
> - con |= 1 << EXYNOS7_PD_DET_EN_SHIFT;
>
> writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
> writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
Could you test this patch if it isn't introducing any regression on your
HW?
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
Hi Guenter,
> On Mon, Feb 23, 2015 at 05:13:36PM +0100, Lukasz Majewski wrote:
> > Hi Guenter,
> >
> [ ... ]
>
> > >
> > > If devicetree is not configured, of_property_count_elems_of_size
> > > returns -ENOSYS, which is returned, causing the driver to fail
> > > loading.
> >
> > Has of_property_count_elems_of_size() returns -ENOSYS?
> >
> > Maybe something has changed, but in my linux-vanila (3.19-rc4)
> > at ./drivers/of/base.c it returns -EINVAL, -ENODATA or number of
> > elements.
> >
> > Have I missed something?
> >
> Hi Lukasz,
>
> Yes, you have. Check include/linux/of.h, line 484, in latest mainline.
Ok. Now I got it.
The above situation shouldn't happen if I put of_find_property() check
on the very beginning of this function (it returns NULL when DT support
is not compiled).
The function would look as follows:
int
pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx
*ctx)
{
struct device_node *np = dev->of_node;
int num, i, ret;
if (!of_find_property(np, "cooling-levels", NULL))
return 0;
ret = of_property_count_u32_elems(np, "cooling-levels");
if (ret <= 0) {
dev_err(dev, "Wrong data!\n");
return ret;
}
num = ret;
ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num *
sizeof(u32), GFP_KERNEL);
if (!ctx->pwm_fan_cooling_levels)
return -ENOMEM;
ret = of_property_read_u32_array(np, "cooling-levels",
ctx->pwm_fan_cooling_levels,
num);
if (ret) {
dev_err(dev, "Property 'cooling-levels' cannot be
read!\n");
return ret;
}
for (i = 0; i < num; i++) {
if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
ctx->pwm_fan_cooling_levels[i],
MAX_PWM);
return -EINVAL;
}
}
ctx->pwm_fan_max_state = num - 1;
return 0;
}
>
> Guenter
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
Hi Guenter,
> On 02/18/2015 02:07 AM, Lukasz Majewski wrote:
> > This patch provides code for reading PWM FAN configuration data via
> > device tree. The pwm-fan can work with full speed when configuration
> > is not provided. However, errors are propagated when wrong DT
> > bindings are found.
> > Additionally the struct pwm_fan_ctx has been extended.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Rename pwm_fan_max_states to pwm_fan_cooling_levels
> > - Moving pwm_fan_of_get_cooling_data() call after setting end
> > enabling PWM FAN
> > - pwm_fan_of_get_cooling_data() now can fail - preserving old
> > behaviour
> > - Remove unnecessary dev_err() call
> > Changes for v3:
> > - Patch's headline has been reedited
> > - pwm_fan_of_get_cooling_data() return code is now being checked.
> > - of_property_count_elems_of_size() is now used instead
> > of_find_property()
> > - More verbose patch description added
> > Changes for v4:
> > - dev_err() has been removed from pwm_fan_of_get_cooling_data()
> > - Returning -EINVAL when "cooling-levels" are defined in DT, but
> > doesn't have the value
> > ---
> > drivers/hwmon/pwm-fan.c | 52
> > - 1 file changed,
> > 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > index bd42d39..82cd06a 100644
> > --- a/drivers/hwmon/pwm-fan.c
> > +++ b/drivers/hwmon/pwm-fan.c
> > @@ -30,7 +30,10 @@
> > struct pwm_fan_ctx {
> > struct mutex lock;
> > struct pwm_device *pwm;
> > - unsigned char pwm_value;
> > + unsigned int pwm_value;
> > + unsigned int pwm_fan_state;
> > + unsigned int pwm_fan_max_state;
> > + unsigned int *pwm_fan_cooling_levels;
> > };
> >
> > static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> > @@ -100,6 +103,48 @@ static struct attribute *pwm_fan_attrs[] = {
> >
> > ATTRIBUTE_GROUPS(pwm_fan);
> >
> > +int pwm_fan_of_get_cooling_data(struct device *dev, struct
> > pwm_fan_ctx *ctx) +{
> > + struct device_node *np = dev->of_node;
> > + int num, i, ret;
> > +
> > + ret = of_property_count_elems_of_size(np, "cooling-levels",
> > + sizeof(u32));
> > +
> > + if (ret == -EINVAL)
> > + return 0;
>
> The function returns -EINVAL if there is no such property,
> but also if prop->length % elem_size != 0. The latter _would_
> be an error.
>
> Overall I don't entirely understand why you do not call
> of_find_property first. If that returns NULL, you would know for sure
> that the property does not exist, and you would not have to second
> guess the returned error from of_property_count_elems_of_size.
For sake of readability I will at v5 first check of_find_property() and
if it is correct, then I will call of_property_count_u32_elems().
>
> On a side note, there is of_property_count_u32_elems() to count
> properties of size u32.
>
> > +
> > + if (ret <= 0) {
> > + dev_err(dev, "Wrong data!\n");
> > + return ret ? ret : -EINVAL;
> > + }
>
> If devicetree is not configured, of_property_count_elems_of_size
> returns -ENOSYS, which is returned, causing the driver to fail
> loading.
Has of_property_count_elems_of_size() returns -ENOSYS?
Maybe something has changed, but in my linux-vanila (3.19-rc4)
at ./drivers/of/base.c it returns -EINVAL, -ENODATA or number of
elements.
Have I missed something?
>
> > +
> > + num = ret;
> > + ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num *
> > sizeof(u32),
> > + GFP_KERNEL);
> > + if (!ctx->pwm_fan_cooling_levels)
> > + return -ENOMEM;
> > +
> > + ret = of_property_read_u32_array(np, "cooling-levels",
> > +
> > ctx->pwm_fan_cooling_levels, num);
> > + if (ret) {
> > + dev_err(dev, "Property 'cooling-levels' cannot be
> > read!\n");
> > + return ret;
> > + }
> > +
> > + for (i = 0; i < num; i++) {
> > + if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
> > + dev_err(dev, "PWM fan state[%d]:%d >
> > %d\n", i,
> > + ctx->pwm_fan_cooling_levels[i],
> > MAX_PWM);
> > + return -EINVAL;
> > + }
> > + }
> &
Re: [PATCH v6 00/18] thermal: exynos: Thermal code rework to use device tree
Hi Kukjin, > Lukasz Majewski wrote: > > > > Hi Kukjin, Eduardo > > > Hi, > > > > On 01/25/15 06:49, Eduardo Valentin wrote: > > > > On Fri, Jan 23, 2015 at 01:09:53PM +0100, Lukasz Majewski wrote: > > > >> 1. Introduction > > > >> > > > >> Following patches aim to clean up the current implementation of > > > >> the thermal framework on Exynos devices. > > > >> > > > >> The main goal was to use a generic code for reading thermal > > > >> configuration (of-thermal.c). Due to that redundant > > > >> exynos_thermal_common.[h|c] files were removed. > > > >> > > > >> Around 400 lines of code (LOC) were removed directly by this > > > >> patch, which is around 20% of the Exynos thermal code base. > > > >> > > > >> This work should NOT bring any functional changes to Exynos > > > >> thermal subsystem. > > > >> > > > >> 2. Patch-set structure > > > >> > > > >> Then the cpu_cooling functionality has been preserved to allow > > > >> cooling devices by reducing operating frequency. Definition of > > > >> trip points and cpufreq's cooling properties were moved to > > > >> device tree. > > > >> > > > >> Then the rework of the way in which configuration data is > > > >> provided to the Exynos thermal subsystem was performed. Now > > > >> device tree is used for configuration. > > > >> > > > >> 3. Dead code removal > > > >> > > > >> Thermal support for some SoCs, previously available in the > > > >> exynos_tmu_data.c file, was removed since, as of (almost) > > > >> 3.19-rc3, they didn't have TMU bindings. > > > >> > > > >> Moreover, support for cpu_cooling devices was preserved only on > > > >> those SoCs which had available and working cpufreq driver. > > > >> > > > >> 4. Testing > > > >> > > > >> Test devices: > > > >> - Exynos4210 - Trats (TMU zone + cpu_cooling) > > > >> - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) > > > >> - Exynos5250 - Arndale (TMU zone + cpu_cooling) > > > >> - Exynos5420 - Arndale-octa (only TMU zones) > > > >> > > > >> Unfortunately, I don't posses Exynos5440 for testing. Its > > > >> functionality has been preserved in the code, but not tested on > > > >> the hardware. I would be grateful for help in testing. > > > >> > > > >> > > > >> 5. This work apply on the following tree: > > > >> > > > >> kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree > > > >> SHA1: 1813d80874699145f04af6b05ebab0a6419001fb > > > >> > > > >> > > > >> Lukasz Majewski (18): > > > > > > > > I have applied the following patches to my -fixes branch (for > > > > next rc cycle) > > > > > > > >> thermal: exynos: cosmetic: Correct comment format > > > >> thermal: exynos: Provide thermal_exynos.h file to be > > > >> included in device tree files > > > >> thermal: exynos: Modify exynos thermal code to use device > > > >> tree for cpu cooling configuration > > > >> cpufreq: exynos: Use device tree to determine if cpufreq > > > >> cooling should be registered > > > >> dts: Documentation: Extending documentation entry for > > > >> exynos-thermal dts: Documentation: Update exynos-thermal.txt > > > >> example for Exynos5440 thermal: samsung: core: Exynos TMU > > > >> rework to use device tree for configuration > > > >> thermal: exynos: Remove exynos_thermal_common.[c|h] files > > > >> thermal: exynos: Remove exynos_tmu_data.c file > > > > > > > > The patches below should go via platform tree: > > > > > > > >> arm: dts: trats: Enable TMU on the Exynos4210 trats device > > > >> arm: dts: odroid: Add LDO10 regulator node necessary for TMU > > > >> on Odroid arm: dts: odroid: Enable TMU at Exynos4412 based > > > >> Odroid U3 device arm: dts: Adding CPU cooling binding for > > > >> Exynos SoCs thermal: exynos: dts: Add default definition of > > > &g
Re: [PATCH v6 00/18] thermal: exynos: Thermal code rework to use device tree
Hi Kukjin, Eduardo > On 01/25/15 06:49, Eduardo Valentin wrote: > > On Fri, Jan 23, 2015 at 01:09:53PM +0100, Lukasz Majewski wrote: > >> 1. Introduction > >> > >> Following patches aim to clean up the current implementation of > >> the thermal framework on Exynos devices. > >> > >> The main goal was to use a generic code for reading thermal > >> configuration (of-thermal.c). Due to that redundant > >> exynos_thermal_common.[h|c] files were removed. > >> > >> Around 400 lines of code (LOC) were removed directly by this > >> patch, which is around 20% of the Exynos thermal code base. > >> > >> This work should NOT bring any functional changes to Exynos > >> thermal subsystem. > >> > >> 2. Patch-set structure > >> > >> Then the cpu_cooling functionality has been preserved to allow > >> cooling devices by reducing operating frequency. Definition of > >> trip points and cpufreq's cooling properties were moved to device > >> tree. > >> > >> Then the rework of the way in which configuration data is provided > >> to the Exynos thermal subsystem was performed. Now device tree is > >> used for configuration. > >> > >> 3. Dead code removal > >> > >> Thermal support for some SoCs, previously available in the > >> exynos_tmu_data.c file, was removed since, as of (almost) > >> 3.19-rc3, they didn't have TMU bindings. > >> > >> Moreover, support for cpu_cooling devices was preserved only on > >> those SoCs which had available and working cpufreq driver. > >> > >> 4. Testing > >> > >> Test devices: > >> - Exynos4210 - Trats (TMU zone + cpu_cooling) > >> - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) > >> - Exynos5250 - Arndale (TMU zone + cpu_cooling) > >> - Exynos5420 - Arndale-octa (only TMU zones) > >> > >> Unfortunately, I don't posses Exynos5440 for testing. Its > >> functionality has been preserved in the code, but not tested on > >> the hardware. I would be grateful for help in testing. > >> > >> > >> 5. This work apply on the following tree: > >> > >> kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree > >> SHA1: 1813d80874699145f04af6b05ebab0a6419001fb > >> > >> > >> Lukasz Majewski (18): > > > > I have applied the following patches to my -fixes branch (for next > > rc cycle) > > > >> thermal: exynos: cosmetic: Correct comment format > >> thermal: exynos: Provide thermal_exynos.h file to be included in > >> device tree files > >> thermal: exynos: Modify exynos thermal code to use device tree > >> for cpu cooling configuration > >> cpufreq: exynos: Use device tree to determine if cpufreq cooling > >> should be registered > >> dts: Documentation: Extending documentation entry for > >> exynos-thermal dts: Documentation: Update exynos-thermal.txt > >> example for Exynos5440 thermal: samsung: core: Exynos TMU rework > >> to use device tree for configuration > >> thermal: exynos: Remove exynos_thermal_common.[c|h] files > >> thermal: exynos: Remove exynos_tmu_data.c file > > > > The patches below should go via platform tree: > > > >> arm: dts: trats: Enable TMU on the Exynos4210 trats device > >> arm: dts: odroid: Add LDO10 regulator node necessary for TMU on > >> Odroid arm: dts: odroid: Enable TMU at Exynos4412 based Odroid U3 > >> device arm: dts: Adding CPU cooling binding for Exynos SoCs > >> thermal: exynos: dts: Add default definition of the TMU sensor > >> parameter > >> thermal: dts: Default trip points definition for Exynos5420 SoCs > >> thermal: exynos: dts: Define default thermal-zones for Exynos4 > >> thermal: dts: exynos: Trip points and sensor configuration data > >> for Exynos5440 > >> thermal: exynos: dts: Provide device tree bindings identical to > >> the one in exynos_tmu_data.c > > > > I've applied above patches with small subject changes. > > BTW unfortunately, since missing the > "include/dt-bindings/thermal/thermal_exynos.h" in my tree, I couldn't > merge it into for-next yet. As of this writing: (Kernel 4.0-rc1) the "include/dt-bindings/thermal/thermal_exynos.h" file is in the kernel tree. Kukjin, could you add missing DTS files and send this to upstream. Thanks in advance. > &g
[PATCH v4 8/8] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
Changed for v4:
- None
---
drivers/hwmon/pwm-fan.c | 86 +++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 82cd06a..622bcd1 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -68,6 +69,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(&cdev->device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -112,7 +178,7 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
sizeof(u32));
if (ret == -EINVAL)
- return 0;
+ return ret;
if (ret <= 0) {
dev_err(dev, "Wrong data!\n");
@@ -147,8 +213,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -192,8 +259,21 @@ static int pwm_fan_probe(struct platform_device *pdev)
}
ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
- if (ret)
+ if (!ret) {
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ &pwm_fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(&pdev->dev,
+ "Failed to register pwm-fan as cooling device");
+ pwm_disable(ctx->pwm);
+ return PTR_ERR(cdev);
+ }
+ thermal_cdev_update(cdev);
+ } else if (ret != -EINVAL) {
return ret;
+ }
return 0;
}
--
2.0.0.rc2
--
To unsubscribe fro
[PATCH v4 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when "cooling-levels" are defined in DT, but doesn't
have the value
---
drivers/hwmon/pwm-fan.c | 52 -
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..82cd06a 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,48 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ ret = of_property_count_elems_of_size(np, "cooling-levels",
+ sizeof(u32));
+
+ if (ret == -EINVAL)
+ return 0;
+
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret ? ret : -EINVAL;
+ }
+
+ num = ret;
+ ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx->pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
+ dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
+ ctx->pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx->pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +190,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx->pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 6/8] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
---
drivers/hwmon/pwm-fan.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
};
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
- struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
- unsigned long pwm, duty;
- ssize_t ret;
-
- if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
- return -EINVAL;
+ unsigned long duty;
+ int ret = 0;
mutex_lock(&ctx->lock);
-
if (ctx->pwm_value == pwm)
- goto exit_set_pwm_no_change;
+ goto exit_set_pwm_err;
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
- ret = count;
exit_set_pwm_err:
mutex_unlock(&ctx->lock);
return ret;
}
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long pwm;
+ int ret;
+
+ if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
+ return -EINVAL;
+
+ ret = __set_pwm(ctx, pwm);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/8] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
[Rebased on the newest mainline by l.majew...@samsung.com]
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 13 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index f18d746..75266e3 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -582,7 +582,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index c8a64be..60bd1e4 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,19 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 1 0>;
+ status = "okay";
+ };
+};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
&usb3503 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 60bd1e4..3e5df3e 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,11 +32,42 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = <&pwm 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
status = "okay";
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+trip = <&cpu_alert2>;
+cooling-device = <&cpu0 13 13>;
+ };
+ map2 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+ };
+ map3 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+ };
+ map4 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+ };
+ };
+ };
+ };
};
&pwm {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/8] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
---
Documentation/devicetree/bindings/hwmon/pwm-fan.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..d53fe0c 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,30 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
+
+Thorough description of the following bindings:
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ thermal-zone {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 0 1>;
+ };
+ };
+ };
+
+for PWM FAN used as cooling device can be found at:
+./Documentation/devicetree/bindings/thermal/thermal.txt
Example:
pwm-fan {
compatible = "pwm-fan";
status = "okay";
pwms = <&pwm 0 1 0>;
+ cooling-levels = <0 102 170 230>;
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
Odroid U3 fan can work without being registered as OF cooling device
(with CONFIG_THERMAL_OF disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.
Therefore, the thermal_of_cooling_device_register() function needs a stub
to allow clean compilation.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- Provide stub declaration when CONFIG_THERMAL is not set
Changes for v4:
- None
---
include/linux/thermal.h | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index fc52e30..eacf2de 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -293,6 +293,20 @@ struct thermal_trip {
};
/* Function declarations */
+#ifdef CONFIG_THERMAL
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+ char *type, void *devdata,
+ const struct thermal_cooling_device_ops *);
+#else
+static inline struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+ char *type, void *devdata,
+ const struct thermal_cooling_device_ops *ops)
+{
+ return NULL;
+}
+#endif
#ifdef CONFIG_THERMAL_OF
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
@@ -328,9 +342,6 @@ void thermal_zone_device_update(struct thermal_zone_device
*);
struct thermal_cooling_device *thermal_cooling_device_register(char *, void *,
const struct thermal_cooling_device_ops *);
-struct thermal_cooling_device *
-thermal_of_cooling_device_register(struct device_node *np, char *, void *,
- const struct thermal_cooling_device_ops *);
void thermal_cooling_device_unregister(struct thermal_cooling_device *);
struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp);
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/8] thermal: Provide stub for thermal_cdev_update() function
Odroid U3 fan can work without being registered as OF cooling device
(with CONFIG_THERMAL{_OF|} disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.
Therefore, the thermal_cdev_update() function needs a stub
to allow clean compilation.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- New patch
Changes for v3:
- thermal_cdev_update() now depends on CONFIG_THERMAL flag
Changes for v4:
- None
---
include/linux/thermal.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index eacf2de..25382e6 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -298,6 +298,7 @@ struct thermal_cooling_device *
thermal_of_cooling_device_register(struct device_node *np,
char *type, void *devdata,
const struct thermal_cooling_device_ops *);
+void thermal_cdev_update(struct thermal_cooling_device *);
#else
static inline struct thermal_cooling_device *
thermal_of_cooling_device_register(struct device_node *np,
@@ -306,6 +307,9 @@ thermal_of_cooling_device_register(struct device_node *np,
{
return NULL;
}
+static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
+{
+}
#endif
#ifdef CONFIG_THERMAL_OF
struct thermal_zone_device *
@@ -349,7 +353,6 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz,
unsigned long *temp);
int get_tz_trend(struct thermal_zone_device *, int);
struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
struct thermal_cooling_device *, int);
-void thermal_cdev_update(struct thermal_cooling_device *);
void thermal_notify_framework(struct thermal_zone_device *, int);
#ifdef CONFIG_NET
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/8] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. To preserve the ability to use this fan as a PWM device stubs for thermal_of_cooling_device_register() and thermal_cdev_update() have been added. Additionally, devices without support for DTS are still supported. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested on Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/next branch (Linux 3.19-rc5) SHA1: 252454f5cbda2c6b40c5d36f58cac2938437b85d Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (7): thermal: Provide stub for thermal_of_cooling_device_register() function thermal: Provide stub for thermal_cdev_update() function Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 20 +++ arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 44 ++ drivers/hwmon/pwm-fan.c| 167 +++-- include/linux/thermal.h| 22 ++- 5 files changed, 236 insertions(+), 19 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] thermal: exynos: Fix NULL pointer exception during kernel booting
Hi Chanwoo, > Hi Lukasz, > > On Tue, Feb 17, 2015 at 12:06 AM, Lukasz Majewski > wrote: > > Hi Chanwoo, > > > >> This patch fixes the NULL pointer exception during kernel booting. > >> The thermal_zone _of_sensor_register() registers a sensor to DT > >> thermal zone and then read the current temperature by '.get_temp' > >> callback. The callback function of exynos thermal driver is > >> exynos_get_temp() which must need the 'pdata' instance of > >> exynos_tmu _platform_data structure. > >> - exynos_get_temp() -> code_to_temp() -> Must need the 'pdata' > >> instance > >> > >> But, exynos thermal driver is executed before getting the 'pdata' > >> instance. To avoid the kernel panic, have to get the platform data > >> by executing the exynos_map_dt_data() before calling > >> thermal_zone_of_sensor_register() . > > > > I've already prepared patch for this (unfortunately it isn't yet > > applied to mainline): > > > > "[PATCH] thermal: exynos: fix: Check if data->tmu_read callback is > > present before read" > > > > http://www.spinics.net/lists/linux-samsung-soc/msg42245.html > > There is different issue between you patch and this patch. > Your patch check the whether data->tmu_read is NULL or not. > But, my patch check the pdata is NULL or not. I've tried to do the same previously. Please compare with: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function http://www.spinics.net/lists/linux-samsung-soc/msg41308.html Unfortunately, Abhilash found some issues with this code, so I've looked into different solution. However, I didn't need to move pdata = data->pdata; Hence, I wonder why it need to be reordered. Are you using Exynos3250 based device? > > > > > Does applying this patch help? > > > > BTW: How can I reproduce this error? Could you point me the SHA1 and > > repository? > > I used your patch-set of linux-soc-thermal.git (branch: next). So I > applied you patchiest on Linux 3.19 for test. > - > https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/log/?h=next Is there any special .config? May I ask about the target platform? I will look closely on this problem tomorrow. > > Best Regards, > Chanwoo Choi -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] thermal: exynos: Clean-up code to use oneline entry for exynos compatible table
Hi Chanwoo,
> This patch cleanup the code to use oneline for entry of exynos
> compatible table.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Chanwoo Choi
> ---
> drivers/thermal/samsung/exynos_tmu.c | 38
> ++-- 1 file changed, 10
> insertions(+), 28 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index b199fff..7e6baf5 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -919,34 +919,16 @@ static irqreturn_t exynos_tmu_irq(int irq, void
> *id) }
>
> static const struct of_device_id exynos_tmu_match[] = {
> - {
> - .compatible = "samsung,exynos3250-tmu",
> - },
> - {
> - .compatible = "samsung,exynos4210-tmu",
> - },
> - {
> - .compatible = "samsung,exynos4412-tmu",
> - },
> - {
> - .compatible = "samsung,exynos5250-tmu",
> - },
> - {
> - .compatible = "samsung,exynos5260-tmu",
> - },
> - {
> - .compatible = "samsung,exynos5420-tmu",
> - },
> - {
> - .compatible = "samsung,exynos5420-tmu-ext-triminfo",
> - },
> - {
> - .compatible = "samsung,exynos5440-tmu",
> - },
> - {
> - .compatible = "samsung,exynos7-tmu",
> - },
> - {},
> + { .compatible = "samsung,exynos3250-tmu", },
> + { .compatible = "samsung,exynos4210-tmu", },
> + { .compatible = "samsung,exynos4412-tmu", },
> + { .compatible = "samsung,exynos5250-tmu", },
> + { .compatible = "samsung,exynos5260-tmu", },
> + { .compatible = "samsung,exynos5420-tmu", },
> + { .compatible = "samsung,exynos5420-tmu-ext-triminfo", },
> + { .compatible = "samsung,exynos5440-tmu", },
> + { .compatible = "samsung,exynos7-tmu", },
> + { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>
Acked-by: Lukasz Majewski
Thanks for clean up!
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] thermal: exynos: Fix NULL pointer exception during kernel booting
Hi Chanwoo,
> This patch fixes the NULL pointer exception during kernel booting.
> The thermal_zone _of_sensor_register() registers a sensor to DT
> thermal zone and then read the current temperature by '.get_temp'
> callback. The callback function of exynos thermal driver is
> exynos_get_temp() which must need the 'pdata' instance of exynos_tmu
> _platform_data structure.
> - exynos_get_temp() -> code_to_temp() -> Must need the 'pdata'
> instance
>
> But, exynos thermal driver is executed before getting the 'pdata'
> instance. To avoid the kernel panic, have to get the platform data by
> executing the exynos_map_dt_data() before calling
> thermal_zone_of_sensor_register() .
I've already prepared patch for this (unfortunately it isn't yet
applied to mainline):
"[PATCH] thermal: exynos: fix: Check if data->tmu_read callback is
present before read"
http://www.spinics.net/lists/linux-samsung-soc/msg42245.html
Does applying this patch help?
BTW: How can I reproduce this error? Could you point me the SHA1 and
repository?
>
> - kernel panic log
> [ 4211.324346] PC is at 0x0
> [ 4211.326867] LR is at exynos_get_temp+0x3c/0xe4
> [ 4211.331289] pc : [<>] lr : []
> [snip]
> [ 4211.940625] [< (null)>] (null)
> [ 4211.945315] [] of_thermal_get_temp+0x1c/0x30
> [ 4211.951132] [] thermal_zone_get_temp+0x48/0x7c
> [ 4211.957118] []
> thermal_zone_device_update+0x20/0x110 [ 4211.963627]
> [] of_thermal_set_mode+0x44/0x68 [ 4211.969443]
> [] thermal_zone_of_sensor_register+0x15c/0x1d8
> [ 4211.976475] [] exynos_tmu_probe+0x6c/0x814
> [ 4211.982120] [] platform_drv_probe+0x48/0xb8
> [ 4211.987846] [] driver_probe_device+0x8c/0x244
> [ 4211.993747] [] __driver_attach+0x98/0xa0
> [ 4211.999216] [] bus_for_each_dev+0x54/0x98
> [ 4212.004771] [] driver_attach+0x1c/0x28
> [ 4212.010066] [] bus_add_driver+0x150/0x208
> [ 4212.015622] [] driver_register+0x5c/0x11c
> [ 4212.021178] []
> __platform_driver_register+0x5c/0x68 [ 4212.027600]
> [] exynos_tmu_driver_init+0x14/0x20 [ 4212.033678]
> [] do_one_initcall+0x88/0x1a0 [ 4212.039235]
> [] kernel_init_freeable+0x1bc/0x260 [ 4212.045311]
> [] kernel_init+0xc/0xd8
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Chanwoo Choi
> ---
> drivers/thermal/samsung/exynos_tmu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index fbeedc0..b8846f1 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -1147,17 +1147,17 @@ static int exynos_tmu_probe(struct
> platform_device *pdev) platform_set_drvdata(pdev, data);
> mutex_init(&data->lock);
>
> + ret = exynos_map_dt_data(pdev);
> + if (ret)
> + return ret;
> + pdata = data->pdata;
> +
> data->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0,
> data, &exynos_sensor_ops);
> if (IS_ERR(data->tzd)) {
> pr_err("thermal: tz: %p ERROR\n", data->tzd);
> return PTR_ERR(data->tzd);
> }
> - ret = exynos_map_dt_data(pdev);
> - if (ret)
> - goto err_sensor;
> -
> - pdata = data->pdata;
>
> INIT_WORK(&data->irq_work, exynos_tmu_work);
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] exynos: config: Enable support for cpufreq on Exynos SoCs (exynos_defconfig)
Hi Kukjin, > On Wed, Jan 28, 2015 at 04:28:40PM +0100, Lukasz Majewski wrote: > > This commit enables the cpufreq subsystem. Moreover, support for > > using CPU as a cooling device is provided. > > > > Signed-off-by: Lukasz Majewski > > I dont see problems with this patch: > > Acked-by: Eduardo Valentin > > > Again, it must go via the correct tree. Could you add this change to -samsung tree? > > > --- > > arch/arm/configs/exynos_defconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/configs/exynos_defconfig > > b/arch/arm/configs/exynos_defconfig index 376dbf4..d6be7e8 100644 > > --- a/arch/arm/configs/exynos_defconfig > > +++ b/arch/arm/configs/exynos_defconfig > > @@ -86,6 +86,8 @@ CONFIG_BATTERY_SBS=y > > CONFIG_CHARGER_TPS65090=y > > CONFIG_HWMON=y > > CONFIG_SENSORS_LM90=y > > +CONFIG_CPU_FREQ=y > > +CONFIG_CPU_THERMAL=y > > CONFIG_THERMAL=y > > CONFIG_EXYNOS_THERMAL=y > > CONFIG_THERMAL_EMULATION=y > > -- > > 2.0.0.rc2 > > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] exynos: config: Enable thermal emulation for Exynos TMU (exynos_defconfig)
Hi Kukjin, > On Wed, Jan 28, 2015 at 04:28:39PM +0100, Lukasz Majewski wrote: > > Enabling thermal emulation on Exynos SoCs. New sysfs attribute - > > emul_temp is created. > > > > Signed-off-by: Lukasz Majewski > > I dont see problems with this patch: > > Acked-by: Eduardo Valentin Could you add this change to -samsung tree? > > > --- > > arch/arm/configs/exynos_defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/configs/exynos_defconfig > > b/arch/arm/configs/exynos_defconfig index 3691a68..376dbf4 100644 > > --- a/arch/arm/configs/exynos_defconfig > > +++ b/arch/arm/configs/exynos_defconfig > > @@ -88,6 +88,7 @@ CONFIG_HWMON=y > > CONFIG_SENSORS_LM90=y > > CONFIG_THERMAL=y > > CONFIG_EXYNOS_THERMAL=y > > +CONFIG_THERMAL_EMULATION=y > > CONFIG_WATCHDOG=y > > CONFIG_S3C2410_WATCHDOG=y > > CONFIG_MFD_CROS_EC=y > > -- > > 2.0.0.rc2 > > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] exynos: config: Remove CONFIG_EXYNOS_THERMAL_CORE define (exynos_defconfig)
Hi Kukjin, > On Wed, Jan 28, 2015 at 04:28:38PM +0100, Lukasz Majewski wrote: > > After Exynos TMU rework to use device tree for configuration this > > flag can be removed. It is not used anymore. > > > > Signed-off-by: Lukasz Majewski > > Acked-by: Eduardo Valentin Could you add this change to -samsung tree? > > > --- > > arch/arm/configs/exynos_defconfig | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/arch/arm/configs/exynos_defconfig > > b/arch/arm/configs/exynos_defconfig index 3d0c5d6..3691a68 100644 > > --- a/arch/arm/configs/exynos_defconfig > > +++ b/arch/arm/configs/exynos_defconfig > > @@ -88,7 +88,6 @@ CONFIG_HWMON=y > > CONFIG_SENSORS_LM90=y > > CONFIG_THERMAL=y > > CONFIG_EXYNOS_THERMAL=y > > -CONFIG_EXYNOS_THERMAL_CORE=y > > CONFIG_WATCHDOG=y > > CONFIG_S3C2410_WATCHDOG=y > > CONFIG_MFD_CROS_EC=y > > -- > > 2.0.0.rc2 > > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: exynos: fix: Check if data->tmu_read callback is present before read
Hi Eduardo,
> The exynos_tmu_data() function should on entrance test not only for
> valid data pointer, but also for data->tmu_read one.
> It is important, since afterwards it is dereferenced to get
> temperature code.
>
> Signed-off-by: Lukasz Majewski
> ---
> drivers/thermal/samsung/exynos_tmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index 3a19353..a86e0495e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -717,7 +717,7 @@ static int exynos_get_temp(void *p, long *temp)
> {
> struct exynos_tmu_data *data = p;
>
> - if (!data)
> + if (!data || !data->tmu_read)
> return -EINVAL;
>
> mutex_lock(&data->lock);
This fix shall be added to v3.20.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
Hi Krzysztof, Thomas, > 2015-01-08 22:17 GMT+01:00 Kevin Hilman : > > On Fri, Nov 21, 2014 at 5:31 AM, Thomas Abraham > > wrote: > >> Changes since v11: > >> - Rebased on top of git://linuxtv.org/snawrocki/samsung.git > >> for-v3.19-exynos-clk > >> > >> This patch series removes the use of Exynos4210 and Exynos5250 > >> specific cpufreq drivers and enables the use of cpufreq-dt driver > >> for these platforms. This series also enables cpufreq support for > >> Exynos5420 using arm_big_little cpufreq driver. > >> > >> This series is based on the following branch. > >> git://linuxtv.org/snawrocki/samsung.git for-v3.19-exynos-clk > >> > >> This series depends on the following patch which can be picked from > >> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git > >> samsung/dt e540920cf21c (ARM: dts: add CPU nodes for Exynos4 SoCs). > >> > >> This patch series has been tested on Exynos4210/5250/5420 based > >> boards. Tomasz Figa had plans to take this in the Samsung clock > >> tree for v3.19 > >> (http://www.spinics.net/lists/linux-samsung-soc/msg37933.html). > >> Sylwester, could you consider to merge this in your tree? > > > > CPUfreq for exynos is still not upstream. What's the status of this > > series? It's been ver a month since there's been any activity here > > (or any responses to the issues I reported.) > > > > On a related note, this series only does frequency scaling. Is there > > any work going on to also enable voltage scaling for the CPU rails > > as well? > > Hi Thomas, > > Do you plan to continue with this work? It would be very helpful. +1 from me. > > I also wonder if Exynos 4412 could be re-added (without the boost if > these bindings are not ready)? I would prefer to have all platforms converted at once, since it might happen that some parts of the work would get lost. > > Best regards, > Krzysztof -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
On Fri, 6 Feb 2015 10:36:57 -0800
Guenter Roeck wrote:
> On Fri, Feb 06, 2015 at 05:59:07PM +0100, Lukasz Majewski wrote:
> > This patch provides code for reading PWM FAN configuration data via
> > device tree. The pwm-fan can work with full speed when configuration
> > is not provided. However, errors are propagated when wrong DT
> > bindings are found.
> > Additionally the struct pwm_fan_ctx has been extended.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Rename pwm_fan_max_states to pwm_fan_cooling_levels
> > - Moving pwm_fan_of_get_cooling_data() call after setting end
> > enabling PWM FAN
> > - pwm_fan_of_get_cooling_data() now can fail - preserving old
> > behaviour
> > - Remove unnecessary dev_err() call
> > Changes for v3:
> > - Patch's headline has been reedited
> > - pwm_fan_of_get_cooling_data() return code is now being checked.
> > - of_property_count_elems_of_size() is now used instead
> > of_find_property()
> > - More verbose patch description added
> > ---
> > drivers/hwmon/pwm-fan.c | 54
> > - 1 file changed,
> > 53 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > index 870e100..f3f5843 100644
> > --- a/drivers/hwmon/pwm-fan.c
> > +++ b/drivers/hwmon/pwm-fan.c
> > @@ -30,7 +30,10 @@
> > struct pwm_fan_ctx {
> > struct mutex lock;
> > struct pwm_device *pwm;
> > - unsigned char pwm_value;
> > + unsigned int pwm_value;
> > + unsigned int pwm_fan_state;
> > + unsigned int pwm_fan_max_state;
> > + unsigned int *pwm_fan_cooling_levels;
> > };
> >
> > static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> > @@ -100,6 +103,50 @@ static struct attribute *pwm_fan_attrs[] = {
> >
> > ATTRIBUTE_GROUPS(pwm_fan);
> >
> > +int pwm_fan_of_get_cooling_data(struct device *dev, struct
> > pwm_fan_ctx *ctx) +{
> > + struct device_node *np = dev->of_node;
> > + int num, i, ret;
> > +
> > + ret = of_property_count_elems_of_size(np, "cooling-levels",
> > + sizeof(u32));
> > +
> > + if (ret == -EINVAL) {
> > + dev_err(dev, "Property 'cooling-levels' not
> > found\n");
> > + return 0;
>
> Returning 0 is obviously not an error, otherwise you would not return
> 0 here. So dev_err is wrong.
pr_info would be more appropriate here.
> Also, the message itself is wrong; the
> property may well be there but have a wrong size.
As fair as I remember the -EINVAL is set only when the property is not
defined. Such situation is correct and our pwm-fan driver should work
with or without it.
>
> > + }
> > +
> > + if (ret <= 0) {
> > + dev_err(dev, "Wrong data!\n");
> > + return ret;
> > + }
>
> This will result in the driver failing to load if devicetree is not
> configured (of_property_count_elems_of_size will return -ENOSYS).
As you pointed out in the comment to v2:
It is OK if the "cooling-levels" is not defined in DT. However, if it
has broken definition, then we should return error. This is what we do
here.
> This is not acceptable. Also, if the call returns 0 you don't return
> an error but display a "Wrong data!" error message. Either it is an
> error or it is not, but not both.
This is an error. "cooling-levels" with zero elements is regarded as a
broken property.
>
> Guenter
Best regards,
Lukasz Majewski
pgpwX7tXZHaer.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 6/8] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
On Fri, 6 Feb 2015 10:27:25 -0800
Guenter Roeck wrote:
> On Fri, Feb 06, 2015 at 05:59:06PM +0100, Lukasz Majewski wrote:
> > It was necessary to decouple code handling writing to sysfs from
> > the one responsible for setting PWM of the fan.
> > Due to that, new __set_pwm() method was extracted, which is
> > responsible for only setting new PWM duty cycle.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - None
> > Changes for v3:
> > - The commit headline has been reedited.
> > ---
> > drivers/hwmon/pwm-fan.c | 35 ++-
> > 1 file changed, 22 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > index 1991d903..870e100 100644
> > --- a/drivers/hwmon/pwm-fan.c
> > +++ b/drivers/hwmon/pwm-fan.c
> > @@ -33,21 +33,15 @@ struct pwm_fan_ctx {
> > unsigned char pwm_value;
> > };
> >
> > -static ssize_t set_pwm(struct device *dev, struct device_attribute
> > *attr,
> > - const char *buf, size_t count)
> > +static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> > {
> > - struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
> > - unsigned long pwm, duty;
> > - ssize_t ret;
> > -
> > - if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
> > - return -EINVAL;
> > -
> > - mutex_lock(&ctx->lock);
> > + unsigned long duty;
> > + int ret;
> >
> > if (ctx->pwm_value == pwm)
> > - goto exit_set_pwm_no_change;
> > + return 0;
> >
> Why did you move this check outside the lock ? With this change there
> is no guarantee that pwm_value wasn't changed while waiting for the
> lock.
Grrr. You are obviously right here. I will fix this. Thanks for spotting
Best regards,
Lukasz Majewski
>
> Guenter
>
> > + mutex_lock(&ctx->lock);
> > if (pwm == 0) {
> > pwm_disable(ctx->pwm);
> > goto exit_set_pwm;
> > @@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev,
> > struct device_attribute *attr,
> > exit_set_pwm:
> > ctx->pwm_value = pwm;
> > -exit_set_pwm_no_change:
> > - ret = count;
> > exit_set_pwm_err:
> > mutex_unlock(&ctx->lock);
> > return ret;
> > }
> >
> > +static ssize_t set_pwm(struct device *dev, struct device_attribute
> > *attr,
> > + const char *buf, size_t count)
> > +{
> > + struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
> > + unsigned long pwm;
> > + int ret;
> > +
> > + if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
> > + return -EINVAL;
> > +
> > + ret = __set_pwm(ctx, pwm);
> > + if (ret)
> > + return ret;
> > +
> > + return count;
> > +}
> > +
> > static ssize_t show_pwm(struct device *dev,
> > struct device_attribute *attr, char *buf)
> > {
> > --
> > 2.0.0.rc2
> >
pgpnEViyDwJ7m.pgp
Description: OpenPGP digital signature
[PATCH v3 0/8] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. To preserve the ability to use this fan as a PWM device stubs for thermal_of_cooling_device_register() and thermal_cdev_update() have been added. Additionally, devices without support for DTS are still supported. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested on Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/next branch (Linux 3.19-rc5) SHA1: 252454f5cbda2c6b40c5d36f58cac2938437b85d Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (7): thermal: Provide stub for thermal_of_cooling_device_register() function thermal: Provide stub for thermal_cdev_update() function Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 20 +++ arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 44 ++ drivers/hwmon/pwm-fan.c| 171 +++-- include/linux/thermal.h| 22 ++- 5 files changed, 239 insertions(+), 20 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/8] thermal: Provide stub for thermal_cdev_update() function
Odroid U3 fan can work without being registered as OF cooling device
(with CONFIG_THERMAL{_OF|} disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.
Therefore, the thermal_cdev_update() function needs a stub
to allow clean compilation.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- New patch
Changes for v3:
- thermal_cdev_update() now depends on CONFIG_THERMAL flag
---
include/linux/thermal.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index eacf2de..25382e6 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -298,6 +298,7 @@ struct thermal_cooling_device *
thermal_of_cooling_device_register(struct device_node *np,
char *type, void *devdata,
const struct thermal_cooling_device_ops *);
+void thermal_cdev_update(struct thermal_cooling_device *);
#else
static inline struct thermal_cooling_device *
thermal_of_cooling_device_register(struct device_node *np,
@@ -306,6 +307,9 @@ thermal_of_cooling_device_register(struct device_node *np,
{
return NULL;
}
+static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
+{
+}
#endif
#ifdef CONFIG_THERMAL_OF
struct thermal_zone_device *
@@ -349,7 +353,6 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz,
unsigned long *temp);
int get_tz_trend(struct thermal_zone_device *, int);
struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
struct thermal_cooling_device *, int);
-void thermal_cdev_update(struct thermal_cooling_device *);
void thermal_notify_framework(struct thermal_zone_device *, int);
#ifdef CONFIG_NET
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/8] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
---
drivers/hwmon/pwm-fan.c | 86 +++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index f3f5843..79fe24e 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -68,6 +69,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(&cdev->device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -113,7 +179,7 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
if (ret == -EINVAL) {
dev_err(dev, "Property 'cooling-levels' not found\n");
- return 0;
+ return ret;
}
if (ret <= 0) {
@@ -149,8 +215,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -194,8 +261,21 @@ static int pwm_fan_probe(struct platform_device *pdev)
}
ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
- if (ret)
+ if (!ret) {
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ &pwm_fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(&pdev->dev,
+ "Failed to register pwm-fan as cooling device");
+ pwm_disable(ctx->pwm);
+ return PTR_ERR(cdev);
+ }
+ thermal_cdev_update(cdev);
+ } else if (ret != -EINVAL) {
return ret;
+ }
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
