* Exynos5422 odroidxu3 pwm-fan control using thermal sensors
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel, linux-pwm
This work depeds upon work done by Lukasz Majewski <l.majewski@samsung.com>
and Sjoerd Simons <sjoerd.simons@collabora.co.uk> regarding the pwm-fan.
-Anand Moon
^ permalink raw reply [flat|nested] 86+ messages in thread
* Exynos5422 odroidxu3 pwm-fan control using thermal sensors
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
This work depeds upon work done by Lukasz Majewski <l.majewski@samsung.com>
and Sjoerd Simons <sjoerd.simons@collabora.co.uk> regarding the pwm-fan.
-Anand Moon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.
2015-03-26 16:39 ` Anand Moon
@ 2015-03-26 16:39 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm, Anand Moon
Add pwm-fan node to the OdroidXU3 board.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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@101E0000 {
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 = <10000>;
};
};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
Add pwm-fan node to the OdroidXU3 board.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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 at 101E0000 {
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 = <10000>;
};
};
+
+&pwm {
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0
2015-03-26 16:39 ` Anand Moon
@ 2015-03-26 16:39 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm, Anand Moon
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 <linux.amoon@gmail.com>
---
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 = <1800000000>;
cci-control-port = <&cci_control1>;
+
+ cooling-min-level = <10>;
+ cooling-max-level = <7>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu1: cpu@1 {
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
update the cooling level for cpu0 to avoid following message.
root at odroidxu3:~# dmesg | grep ther
[ 0.241511] /thermal-zones/cpu-thermal/cooling-maps/map0:
could not get #cooling-cells for /cpus/cpu at 0
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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 = <1800000000>;
cci-control-port = <&cci_control1>;
+
+ cooling-min-level = <10>;
+ cooling-max-level = <7>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu1: cpu at 1 {
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
2015-03-26 16:39 ` Anand Moon
@ 2015-03-26 16:39 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm, Anand Moon
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 <linux.amoon@gmail.com>
---
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 0000000..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 <l.majewski@samsung.com>
+ *
+ * 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 <dt-bindings/thermal/thermal.h>
+
+/ {
+ 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 */
+ 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";
+ };
+ };
+ 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"
- };
cpu1_thermal: cpu1-thermal {
thermal-sensors = <&tmu_cpu1>;
#include "exynos5420-trip-points.dtsi"
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index eaec006..c8b3e3e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "exynos5800.dtsi"
+#include "exynos5-cpu-thermal.dtsi"
/ {
model = "Hardkernel Odroid XU3";
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
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 <linux.amoon@gmail.com>
---
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 0000000..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 <l.majewski@samsung.com>
+ *
+ * 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 <dt-bindings/thermal/thermal.h>
+
+/ {
+ 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 */
+ 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";
+ };
+ };
+ 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"
- };
cpu1_thermal: cpu1-thermal {
thermal-sensors = <&tmu_cpu1>;
#include "exynos5420-trip-points.dtsi"
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index eaec006..c8b3e3e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "exynos5800.dtsi"
+#include "exynos5-cpu-thermal.dtsi"
/ {
model = "Hardkernel Odroid XU3";
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.
2015-03-26 16:39 ` Anand Moon
@ 2015-03-26 16:39 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm, Anand Moon
This commit enables TMU IP block on the Exynos5422 OdroidXU3
device.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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@10060000 {
+ 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 {
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
This commit enables TMU IP block on the Exynos5422 OdroidXU3
device.
Tested on OdroidXU3 board.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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 at 10060000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu at 10064000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu at 10068000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu at 1006c000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
+
+ tmu at 100a0000 {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
};
&hdmi {
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 5/6] pwm: samsung: Fix output race on disabling
2015-03-26 16:39 ` Anand Moon
(?)
@ 2015-03-26 16:39 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm, Anand Moon
From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
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 <sjoerd.simons@collabora.co.uk>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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;
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 5/6] pwm: samsung: Fix output race on disabling
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-samsung-soc, linux-pwm, Anand Moon,
linux-kernel, linux-arm-kernel
From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
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 <sjoerd.simons@collabora.co.uk>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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;
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 5/6] pwm: samsung: Fix output race on disabling
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
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 <sjoerd.simons@collabora.co.uk>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
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;
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-03-26 16:39 ` Anand Moon
@ 2015-03-26 16:39 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm, Anand Moon
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 <linux.amoon@gmail.com>
---
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);
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-03-26 16:39 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-03-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel
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 <linux.amoon@gmail.com>
---
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);
--
1.9.1
^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: Exynos5422 odroidxu3 pwm-fan control using thermal sensors
2015-03-26 16:39 ` Anand Moon
@ 2015-04-02 10:02 ` Markus Reichl
-1 siblings, 0 replies; 86+ messages in thread
From: Markus Reichl @ 2015-04-02 10:02 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Lukasz Majewski, linux-samsung-soc, Russell King,
linux-pwm, linux-kernel, Eduardo Valentin, Sjoerd Simons,
Kukjin Kim, linux-arm-kernel
Am Freitag, 27. März 2015, 03:09:09 schrieb Anand Moon:
> This work depeds upon work done by Lukasz Majewski <l.majewski@samsung.com>
> and Sjoerd Simons <sjoerd.simons@collabora.co.uk> regarding the pwm-fan.
>
> -Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Best Regards,
---
Markus Reichl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 86+ messages in thread
* Exynos5422 odroidxu3 pwm-fan control using thermal sensors
@ 2015-04-02 10:02 ` Markus Reichl
0 siblings, 0 replies; 86+ messages in thread
From: Markus Reichl @ 2015-04-02 10:02 UTC (permalink / raw)
To: linux-arm-kernel
Am Freitag, 27. M?rz 2015, 03:09:09 schrieb Anand Moon:
> This work depeds upon work done by Lukasz Majewski <l.majewski@samsung.com>
> and Sjoerd Simons <sjoerd.simons@collabora.co.uk> regarding the pwm-fan.
>
> -Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Best Regards,
---
Markus Reichl
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Exynos5422 odroidxu3 pwm-fan control using thermal sensors
2015-03-26 16:39 ` Anand Moon
@ 2015-04-02 10:06 ` Markus Reichl
-1 siblings, 0 replies; 86+ messages in thread
From: Markus Reichl @ 2015-04-02 10:06 UTC (permalink / raw)
To: Anand Moon
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-pwm
Am Freitag, 27. März 2015, 03:09:09 schrieb Anand Moon:
> This work depeds upon work done by Lukasz Majewski <l.majewski@samsung.com>
> and Sjoerd Simons <sjoerd.simons@collabora.co.uk> regarding the pwm-fan.
>
> -Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
MarkusTested-by: Markus Reichl <m.reichl@fivetechno.de>
Best Regards,
---
Markus Reichl
^ permalink raw reply [flat|nested] 86+ messages in thread
* Exynos5422 odroidxu3 pwm-fan control using thermal sensors
@ 2015-04-02 10:06 ` Markus Reichl
0 siblings, 0 replies; 86+ messages in thread
From: Markus Reichl @ 2015-04-02 10:06 UTC (permalink / raw)
To: linux-arm-kernel
Am Freitag, 27. M?rz 2015, 03:09:09 schrieb Anand Moon:
> This work depeds upon work done by Lukasz Majewski <l.majewski@samsung.com>
> and Sjoerd Simons <sjoerd.simons@collabora.co.uk> regarding the pwm-fan.
>
> -Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
MarkusTested-by: Markus Reichl <m.reichl@fivetechno.de>
Best Regards,
---
Markus Reichl
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.
2015-03-26 16:39 ` Anand Moon
@ 2015-04-08 7:46 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 7:46 UTC (permalink / raw)
To: Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
Hi Anand,
> Add pwm-fan node to the OdroidXU3 board.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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@101E0000 {
> 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 = <10000>;
> };
> };
> +
> +&pwm {
> + pinctrl-0 = <&pwm0_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.
@ 2015-04-08 7:46 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 7:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi Anand,
> Add pwm-fan node to the OdroidXU3 board.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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 at 101E0000 {
> 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 = <10000>;
> };
> };
> +
> +&pwm {
> + pinctrl-0 = <&pwm0_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0
2015-03-26 16:39 ` Anand Moon
@ 2015-04-08 7:47 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 7:47 UTC (permalink / raw)
To: Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
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 <linux.amoon@gmail.com>
> ---
> 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 = <1800000000>;
> 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 <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0
@ 2015-04-08 7:47 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 7:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Anand,
> update the cooling level for cpu0 to avoid following message.
>
> root at odroidxu3:~# dmesg | grep ther
> [ 0.241511] /thermal-zones/cpu-thermal/cooling-maps/map0:
> could not get #cooling-cells for /cpus/cpu at 0
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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 = <1800000000>;
> cci-control-port = <&cci_control1>;
> +
> + cooling-min-level = <10>;
> + cooling-max-level = <7>;
> + #cooling-cells = <2>; /* min followed by max
> */ };
>
> cpu1: cpu at 1 {
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
2015-03-26 16:39 ` Anand Moon
(?)
@ 2015-04-08 8:02 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:02 UTC (permalink / raw)
To: Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
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 <linux.amoon@gmail.com>
> ---
> 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 0000000..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 <l.majewski@samsung.com>
^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
> +
> +/ {
> + 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"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
> - };
> cpu1_thermal: cpu1-thermal {
> thermal-sensors = <&tmu_cpu1>;
> #include "exynos5420-trip-points.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -12,6 +12,7 @@
>
> /dts-v1/;
> #include "exynos5800.dtsi"
> +#include "exynos5-cpu-thermal.dtsi"
I would prefer to stick to convention proposed at [1]. It keeps
the locality of the include with respective thermal zone.
>
> / {
> model = "Hardkernel Odroid XU3";
DTS changes should be added to Samsung tree by Samsung maintainer - Mr.
Kukjin Kim.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 8:02 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:02 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, linux-samsung-soc, Russell King, linux-pwm,
linux-kernel, Eduardo Valentin, Sjoerd Simons, Kukjin Kim,
linux-arm-kernel
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 <linux.amoon@gmail.com>
> ---
> 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 0000000..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 <l.majewski@samsung.com>
^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
> +
> +/ {
> + 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"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
> - };
> cpu1_thermal: cpu1-thermal {
> thermal-sensors = <&tmu_cpu1>;
> #include "exynos5420-trip-points.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -12,6 +12,7 @@
>
> /dts-v1/;
> #include "exynos5800.dtsi"
> +#include "exynos5-cpu-thermal.dtsi"
I would prefer to stick to convention proposed at [1]. It keeps
the locality of the include with respective thermal zone.
>
> / {
> model = "Hardkernel Odroid XU3";
DTS changes should be added to Samsung tree by Samsung maintainer - Mr.
Kukjin Kim.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 8:02 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:02 UTC (permalink / raw)
To: linux-arm-kernel
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 <linux.amoon@gmail.com>
> ---
> 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 0000000..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 <l.majewski@samsung.com>
^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
> +
> +/ {
> + 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"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
> - };
> cpu1_thermal: cpu1-thermal {
> thermal-sensors = <&tmu_cpu1>;
> #include "exynos5420-trip-points.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -12,6 +12,7 @@
>
> /dts-v1/;
> #include "exynos5800.dtsi"
> +#include "exynos5-cpu-thermal.dtsi"
I would prefer to stick to convention proposed at [1]. It keeps
the locality of the include with respective thermal zone.
>
> / {
> model = "Hardkernel Odroid XU3";
DTS changes should be added to Samsung tree by Samsung maintainer - Mr.
Kukjin Kim.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.
2015-03-26 16:39 ` Anand Moon
@ 2015-04-08 8:03 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:03 UTC (permalink / raw)
To: Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
Hi Anand,
> This commit enables TMU IP block on the Exynos5422 OdroidXU3
> device.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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@10060000 {
> + 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 <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.
@ 2015-04-08 8:03 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Anand,
> This commit enables TMU IP block on the Exynos5422 OdroidXU3
> device.
>
> Tested on OdroidXU3 board.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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 at 10060000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu at 10064000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu at 10068000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu at 1006c000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu at 100a0000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> };
>
> &hdmi {
This seems correct. However please consider my comment to the previous
patch.
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling
2015-03-26 16:39 ` Anand Moon
@ 2015-04-08 8:28 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:28 UTC (permalink / raw)
To: Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
Hi Anand,
> From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>
> 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 <sjoerd.simons@collabora.co.uk>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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 <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/6] pwm: samsung: Fix output race on disabling
@ 2015-04-08 8:28 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Anand,
> From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>
> 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 <sjoerd.simons@collabora.co.uk>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> 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 <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling
2015-04-08 8:28 ` Lukasz Majewski
@ 2015-04-08 8:42 ` Sjoerd Simons
-1 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-08 8:42 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Anand Moon, Eduardo Valentin, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
> Hi Anand,
>
> > From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> > 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 patch is already in the linux-pwm for-next tree so should probably
be dropped form this patchset to prevent conflicts.
--
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/6] pwm: samsung: Fix output race on disabling
@ 2015-04-08 8:42 ` Sjoerd Simons
0 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-08 8:42 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
> Hi Anand,
>
> > From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> > 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 patch is already in the linux-pwm for-next tree so should probably
be dropped form this patchset to prevent conflicts.
--
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-03-26 16:39 ` Anand Moon
@ 2015-04-08 8:44 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:44 UTC (permalink / raw)
To: Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-samsung-soc, linux-pwm, linux-kernel,
linux-arm-kernel, Guenter Roeck
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 <linux.amoon@gmail.com>
> ---
> 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 <l.majewski@samsung.com>
BTW: I've added Guenter to CC.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 8:44 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 8:44 UTC (permalink / raw)
To: linux-arm-kernel
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 <linux.amoon@gmail.com>
> ---
> 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 <l.majewski@samsung.com>
BTW: I've added Guenter to CC.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling
2015-04-08 8:42 ` Sjoerd Simons
(?)
@ 2015-04-08 8:53 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 8:53 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Lukasz Majewski, Eduardo Valentin, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
Hi Sjoerd,
Correct. Will do so. I just included in this series. As it relevant to
my changes and testing.
-Anand Moon
On 8 April 2015 at 14:12, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>
>
> On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
>> Hi Anand,
>>
>> > From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>> > 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 patch is already in the linux-pwm for-next tree so should probably
> be dropped form this patchset to prevent conflicts.
>
> --
> Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> Collabora Ltd.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling
@ 2015-04-08 8:53 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 8:53 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Lukasz Majewski, Eduardo Valentin, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
Hi Sjoerd,
Correct. Will do so. I just included in this series. As it relevant to
my changes and testing.
-Anand Moon
On 8 April 2015 at 14:12, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>
>
> On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
>> Hi Anand,
>>
>> > From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>> > 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 patch is already in the linux-pwm for-next tree so should probably
> be dropped form this patchset to prevent conflicts.
>
> --
> Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> Collabora Ltd.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/6] pwm: samsung: Fix output race on disabling
@ 2015-04-08 8:53 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 8:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sjoerd,
Correct. Will do so. I just included in this series. As it relevant to
my changes and testing.
-Anand Moon
On 8 April 2015 at 14:12, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>
>
> On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
>> Hi Anand,
>>
>> > From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>> > 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 patch is already in the linux-pwm for-next tree so should probably
> be dropped form this patchset to prevent conflicts.
>
> --
> Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> Collabora Ltd.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
2015-04-08 8:02 ` Lukasz Majewski
(?)
@ 2015-04-08 9:12 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 9:12 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pwm
Hi Lukasz,
On Odroidxu3 board critical temp is 85.0 C. Below is the sensors output.
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 50000, 65000 ,80000 and
85000 Critical temperature.
Please share your thoughts.
-Anand Moon
On 8 April 2015 at 13:32, Lukasz Majewski <l.majewski@samsung.com> 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 <linux.amoon@gmail.com>
>> ---
>> 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 0000000..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 <l.majewski@samsung.com>
>
> ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
>> +
>> +/ {
>> + 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"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>
>> - };
>> cpu1_thermal: cpu1-thermal {
>> thermal-sensors = <&tmu_cpu1>;
>> #include "exynos5420-trip-points.dtsi"
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
>> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> @@ -12,6 +12,7 @@
>>
>> /dts-v1/;
>> #include "exynos5800.dtsi"
>> +#include "exynos5-cpu-thermal.dtsi"
>
> I would prefer to stick to convention proposed at [1]. It keeps
> the locality of the include with respective thermal zone.
>
>>
>> / {
>> model = "Hardkernel Odroid XU3";
>
> DTS changes should be added to Samsung tree by Samsung maintainer - Mr.
> Kukjin Kim.
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 9:12 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 9:12 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA
Hi Lukasz,
On Odroidxu3 board critical temp is 85.0 C. Below is the sensors output.
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 50000, 65000 ,80000 and
85000 Critical temperature.
Please share your thoughts.
-Anand Moon
On 8 April 2015 at 13:32, Lukasz Majewski <l.majewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 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 <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> 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 0000000..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 <l.majewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
>> +
>> +/ {
>> + 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"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>
>> - };
>> cpu1_thermal: cpu1-thermal {
>> thermal-sensors = <&tmu_cpu1>;
>> #include "exynos5420-trip-points.dtsi"
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
>> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> @@ -12,6 +12,7 @@
>>
>> /dts-v1/;
>> #include "exynos5800.dtsi"
>> +#include "exynos5-cpu-thermal.dtsi"
>
> I would prefer to stick to convention proposed at [1]. It keeps
> the locality of the include with respective thermal zone.
>
>>
>> / {
>> model = "Hardkernel Odroid XU3";
>
> DTS changes should be added to Samsung tree by Samsung maintainer - Mr.
> Kukjin Kim.
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 9:12 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lukasz,
On Odroidxu3 board critical temp is 85.0 C. Below is the sensors output.
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 50000, 65000 ,80000 and
85000 Critical temperature.
Please share your thoughts.
-Anand Moon
On 8 April 2015 at 13:32, Lukasz Majewski <l.majewski@samsung.com> 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 <linux.amoon@gmail.com>
>> ---
>> 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 0000000..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 <l.majewski@samsung.com>
>
> ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
>> +
>> +/ {
>> + 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"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>
>> - };
>> cpu1_thermal: cpu1-thermal {
>> thermal-sensors = <&tmu_cpu1>;
>> #include "exynos5420-trip-points.dtsi"
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
>> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> @@ -12,6 +12,7 @@
>>
>> /dts-v1/;
>> #include "exynos5800.dtsi"
>> +#include "exynos5-cpu-thermal.dtsi"
>
> I would prefer to stick to convention proposed at [1]. It keeps
> the locality of the include with respective thermal zone.
>
>>
>> / {
>> model = "Hardkernel Odroid XU3";
>
> DTS changes should be added to Samsung tree by Samsung maintainer - Mr.
> Kukjin Kim.
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
2015-04-08 9:12 ` Anand Moon
(?)
@ 2015-04-08 9:30 ` Lukasz Majewski
-1 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 9:30 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, linux-samsung-soc, Russell King, linux-pwm,
linux-kernel, Eduardo Valentin, Sjoerd Simons, Kukjin Kim,
linux-arm-kernel
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 50000, 65000 ,80000 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 <l.majewski@samsung.com>
> 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 <linux.amoon@gmail.com>
> >> ---
> >> 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 0000000..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 <l.majewski@samsung.com>
> >
> > ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
> >> +
> >> +/ {
> >> + 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"
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
> >
> >> - };
> >> cpu1_thermal: cpu1-thermal {
> >> thermal-sensors = <&tmu_cpu1>;
> >> #include "exynos5420-trip-points.dtsi"
> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> >> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> @@ -12,6 +12,7 @@
> >>
> >> /dts-v1/;
> >> #include "exynos5800.dtsi"
> >> +#include "exynos5-cpu-thermal.dtsi"
> >
> > I would prefer to stick to convention proposed at [1]. It keeps
> > the locality of the include with respective thermal zone.
> >
> >>
> >> / {
> >> model = "Hardkernel Odroid XU3";
> >
> > DTS changes should be added to Samsung tree by Samsung maintainer -
> > Mr. Kukjin Kim.
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 9:30 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 9:30 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, linux-samsung-soc, Russell King, linux-pwm,
linux-kernel, Eduardo Valentin, Sjoerd Simons, Kukjin Kim,
linux-arm-kernel
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 50000, 65000 ,80000 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 <l.majewski@samsung.com>
> 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 <linux.amoon@gmail.com>
> >> ---
> >> 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 0000000..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 <l.majewski@samsung.com>
> >
> > ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
> >> +
> >> +/ {
> >> + 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"
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
> >
> >> - };
> >> cpu1_thermal: cpu1-thermal {
> >> thermal-sensors = <&tmu_cpu1>;
> >> #include "exynos5420-trip-points.dtsi"
> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> >> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> @@ -12,6 +12,7 @@
> >>
> >> /dts-v1/;
> >> #include "exynos5800.dtsi"
> >> +#include "exynos5-cpu-thermal.dtsi"
> >
> > I would prefer to stick to convention proposed at [1]. It keeps
> > the locality of the include with respective thermal zone.
> >
> >>
> >> / {
> >> model = "Hardkernel Odroid XU3";
> >
> > DTS changes should be added to Samsung tree by Samsung maintainer -
> > Mr. Kukjin Kim.
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 9:30 ` Lukasz Majewski
0 siblings, 0 replies; 86+ messages in thread
From: Lukasz Majewski @ 2015-04-08 9:30 UTC (permalink / raw)
To: linux-arm-kernel
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 50000, 65000 ,80000 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 <l.majewski@samsung.com>
> 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 <linux.amoon@gmail.com>
> >> ---
> >> 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 0000000..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 <l.majewski@samsung.com>
> >
> > ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
> >> +
> >> +/ {
> >> + 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"
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
> >
> >> - };
> >> cpu1_thermal: cpu1-thermal {
> >> thermal-sensors = <&tmu_cpu1>;
> >> #include "exynos5420-trip-points.dtsi"
> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> >> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> @@ -12,6 +12,7 @@
> >>
> >> /dts-v1/;
> >> #include "exynos5800.dtsi"
> >> +#include "exynos5-cpu-thermal.dtsi"
> >
> > I would prefer to stick to convention proposed at [1]. It keeps
> > the locality of the include with respective thermal zone.
> >
> >>
> >> / {
> >> model = "Hardkernel Odroid XU3";
> >
> > DTS changes should be added to Samsung tree by Samsung maintainer -
> > Mr. Kukjin Kim.
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
2015-04-08 9:30 ` Lukasz Majewski
(?)
@ 2015-04-08 9:44 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 9:44 UTC (permalink / raw)
To: Lukasz Majewski
Cc: devicetree, linux-samsung-soc, Russell King, linux-pwm,
linux-kernel, Eduardo Valentin, Sjoerd Simons, Kukjin Kim,
linux-arm-kernel
Hi Lukasz,
I have Odroidxu3 board with fan. Odroid xu3 board and run on high temperature.
As per my understating as the sensors temperature cross the first
alert it triggers fan to run.
I was doing some stress testing to trigger this overheating with my changes.
-Anand Moon
On 8 April 2015 at 15:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 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 50000, 65000 ,80000 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 <l.majewski@samsung.com>
>> 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 <linux.amoon@gmail.com>
>> >> ---
>> >> 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 0000000..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 <l.majewski@samsung.com>
>> >
>> > ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
>> >> +
>> >> +/ {
>> >> + 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"
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>> >
>> >> - };
>> >> cpu1_thermal: cpu1-thermal {
>> >> thermal-sensors = <&tmu_cpu1>;
>> >> #include "exynos5420-trip-points.dtsi"
>> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
>> >> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> @@ -12,6 +12,7 @@
>> >>
>> >> /dts-v1/;
>> >> #include "exynos5800.dtsi"
>> >> +#include "exynos5-cpu-thermal.dtsi"
>> >
>> > I would prefer to stick to convention proposed at [1]. It keeps
>> > the locality of the include with respective thermal zone.
>> >
>> >>
>> >> / {
>> >> model = "Hardkernel Odroid XU3";
>> >
>> > DTS changes should be added to Samsung tree by Samsung maintainer -
>> > Mr. Kukjin Kim.
>> >
>> > --
>> > Best regards,
>> >
>> > Lukasz Majewski
>> >
>> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 9:44 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 9:44 UTC (permalink / raw)
To: Lukasz Majewski
Cc: devicetree, linux-samsung-soc, Russell King, linux-pwm,
linux-kernel, Eduardo Valentin, Sjoerd Simons, Kukjin Kim,
linux-arm-kernel
Hi Lukasz,
I have Odroidxu3 board with fan. Odroid xu3 board and run on high temperature.
As per my understating as the sensors temperature cross the first
alert it triggers fan to run.
I was doing some stress testing to trigger this overheating with my changes.
-Anand Moon
On 8 April 2015 at 15:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 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 50000, 65000 ,80000 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 <l.majewski@samsung.com>
>> 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 <linux.amoon@gmail.com>
>> >> ---
>> >> 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 0000000..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 <l.majewski@samsung.com>
>> >
>> > ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
>> >> +
>> >> +/ {
>> >> + 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"
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>> >
>> >> - };
>> >> cpu1_thermal: cpu1-thermal {
>> >> thermal-sensors = <&tmu_cpu1>;
>> >> #include "exynos5420-trip-points.dtsi"
>> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
>> >> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> @@ -12,6 +12,7 @@
>> >>
>> >> /dts-v1/;
>> >> #include "exynos5800.dtsi"
>> >> +#include "exynos5-cpu-thermal.dtsi"
>> >
>> > I would prefer to stick to convention proposed at [1]. It keeps
>> > the locality of the include with respective thermal zone.
>> >
>> >>
>> >> / {
>> >> model = "Hardkernel Odroid XU3";
>> >
>> > DTS changes should be added to Samsung tree by Samsung maintainer -
>> > Mr. Kukjin Kim.
>> >
>> > --
>> > Best regards,
>> >
>> > Lukasz Majewski
>> >
>> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0
@ 2015-04-08 9:44 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 9:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lukasz,
I have Odroidxu3 board with fan. Odroid xu3 board and run on high temperature.
As per my understating as the sensors temperature cross the first
alert it triggers fan to run.
I was doing some stress testing to trigger this overheating with my changes.
-Anand Moon
On 8 April 2015 at 15:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 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 50000, 65000 ,80000 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 <l.majewski@samsung.com>
>> 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 <linux.amoon@gmail.com>
>> >> ---
>> >> 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 0000000..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 <l.majewski@samsung.com>
>> >
>> > ^^^^^^^^^^^^^^^^ 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 <dt-bindings/thermal/thermal.h>
>> >> +
>> >> +/ {
>> >> + 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"
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>> >
>> >> - };
>> >> cpu1_thermal: cpu1-thermal {
>> >> thermal-sensors = <&tmu_cpu1>;
>> >> #include "exynos5420-trip-points.dtsi"
>> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
>> >> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> >> @@ -12,6 +12,7 @@
>> >>
>> >> /dts-v1/;
>> >> #include "exynos5800.dtsi"
>> >> +#include "exynos5-cpu-thermal.dtsi"
>> >
>> > I would prefer to stick to convention proposed at [1]. It keeps
>> > the locality of the include with respective thermal zone.
>> >
>> >>
>> >> / {
>> >> model = "Hardkernel Odroid XU3";
>> >
>> > DTS changes should be added to Samsung tree by Samsung maintainer -
>> > Mr. Kukjin Kim.
>> >
>> > --
>> > Best regards,
>> >
>> > Lukasz Majewski
>> >
>> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-08 8:44 ` Lukasz Majewski
@ 2015-04-08 13:11 ` Guenter Roeck
-1 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 13:11 UTC (permalink / raw)
To: Lukasz Majewski, Anand Moon
Cc: Eduardo Valentin, Sjoerd Simons, Russell King, Kukjin Kim,
devicetree, linux-samsung-soc, linux-pwm, linux-kernel,
linux-arm-kernel
On 04/08/2015 01:44 AM, Lukasz Majewski wrote:
> 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 <linux.amoon@gmail.com>
>> ---
>> 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 <l.majewski@samsung.com>
>
> BTW: I've added Guenter to CC.
>
I don't have a copy of the original patch, so I can't apply it.
Guenter
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 13:11 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 13:11 UTC (permalink / raw)
To: linux-arm-kernel
On 04/08/2015 01:44 AM, Lukasz Majewski wrote:
> 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 <linux.amoon@gmail.com>
>> ---
>> 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 <l.majewski@samsung.com>
>
> BTW: I've added Guenter to CC.
>
I don't have a copy of the original patch, so I can't apply it.
Guenter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-08 8:44 ` Lukasz Majewski
@ 2015-04-08 15:32 ` Guenter Roeck
-1 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 15:32 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Anand Moon, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> 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.
> >
Unfortunately, the patch does not include an explanation why it is needed.
The original code presumably did not update the duty cycle because
pwm was about to be disabled anyway. That kind of made sense to me.
Updating the duty cycle to 0 just to disable the pwm channel right
afterwards does not immediately make sense.
Given that, I would expect to see a rationale here. Why is this patch needed ?
Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
purpose of this patch ?
Maybe that is all explained in patch 0/6, which I was not copied on. Even
if so, the reationale will be needed in the changelog to explain to future
developers why this change was made.
Thanks,
Guenter
> > Tested on OdroidXU3 board.
> >
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > ---
> > 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);
> > +
[ please refrain from unnecessary whitespace changes ]
> > 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 <l.majewski@samsung.com>
>
> BTW: I've added Guenter to CC.
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 15:32 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 15:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> 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.
> >
Unfortunately, the patch does not include an explanation why it is needed.
The original code presumably did not update the duty cycle because
pwm was about to be disabled anyway. That kind of made sense to me.
Updating the duty cycle to 0 just to disable the pwm channel right
afterwards does not immediately make sense.
Given that, I would expect to see a rationale here. Why is this patch needed ?
Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
purpose of this patch ?
Maybe that is all explained in patch 0/6, which I was not copied on. Even
if so, the reationale will be needed in the changelog to explain to future
developers why this change was made.
Thanks,
Guenter
> > Tested on OdroidXU3 board.
> >
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > ---
> > 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);
> > +
[ please refrain from unnecessary whitespace changes ]
> > 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 <l.majewski@samsung.com>
>
> BTW: I've added Guenter to CC.
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-08 15:32 ` Guenter Roeck
(?)
@ 2015-04-08 16:02 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 16:02 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
Hi Guenter,
Initially the board bootup the cooling level state is 0.
So update the duty cycle and this power off the fan.
As their is no state change the fan will not spin.
Once the temperature sensor is reached to alert temperature it changes state.
With the state change the fan cools the CPU and then stop's
I have observed this state change with tmon utility in linux/tools/thermal/tmon/
-Anand Moon
On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> 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.
>> >
>
> Unfortunately, the patch does not include an explanation why it is needed.
>
> The original code presumably did not update the duty cycle because
> pwm was about to be disabled anyway. That kind of made sense to me.
> Updating the duty cycle to 0 just to disable the pwm channel right
> afterwards does not immediately make sense.
>
> Given that, I would expect to see a rationale here. Why is this patch needed ?
> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> purpose of this patch ?
>
> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> if so, the reationale will be needed in the changelog to explain to future
> developers why this change was made.
>
> Thanks,
> Guenter
>
>> > Tested on OdroidXU3 board.
>> >
>> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> > ---
>> > 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);
>> > +
>
> [ please refrain from unnecessary whitespace changes ]
>
>> > 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 <l.majewski@samsung.com>
>>
>> BTW: I've added Guenter to CC.
>>
>> --
>> Best regards,
>>
>> Lukasz Majewski
>>
>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 16:02 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 16:02 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
Hi Guenter,
Initially the board bootup the cooling level state is 0.
So update the duty cycle and this power off the fan.
As their is no state change the fan will not spin.
Once the temperature sensor is reached to alert temperature it changes state.
With the state change the fan cools the CPU and then stop's
I have observed this state change with tmon utility in linux/tools/thermal/tmon/
-Anand Moon
On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> 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.
>> >
>
> Unfortunately, the patch does not include an explanation why it is needed.
>
> The original code presumably did not update the duty cycle because
> pwm was about to be disabled anyway. That kind of made sense to me.
> Updating the duty cycle to 0 just to disable the pwm channel right
> afterwards does not immediately make sense.
>
> Given that, I would expect to see a rationale here. Why is this patch needed ?
> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> purpose of this patch ?
>
> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> if so, the reationale will be needed in the changelog to explain to future
> developers why this change was made.
>
> Thanks,
> Guenter
>
>> > Tested on OdroidXU3 board.
>> >
>> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> > ---
>> > 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);
>> > +
>
> [ please refrain from unnecessary whitespace changes ]
>
>> > 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 <l.majewski@samsung.com>
>>
>> BTW: I've added Guenter to CC.
>>
>> --
>> Best regards,
>>
>> Lukasz Majewski
>>
>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 16:02 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 16:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guenter,
Initially the board bootup the cooling level state is 0.
So update the duty cycle and this power off the fan.
As their is no state change the fan will not spin.
Once the temperature sensor is reached to alert temperature it changes state.
With the state change the fan cools the CPU and then stop's
I have observed this state change with tmon utility in linux/tools/thermal/tmon/
-Anand Moon
On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> 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.
>> >
>
> Unfortunately, the patch does not include an explanation why it is needed.
>
> The original code presumably did not update the duty cycle because
> pwm was about to be disabled anyway. That kind of made sense to me.
> Updating the duty cycle to 0 just to disable the pwm channel right
> afterwards does not immediately make sense.
>
> Given that, I would expect to see a rationale here. Why is this patch needed ?
> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> purpose of this patch ?
>
> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> if so, the reationale will be needed in the changelog to explain to future
> developers why this change was made.
>
> Thanks,
> Guenter
>
>> > Tested on OdroidXU3 board.
>> >
>> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> > ---
>> > 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);
>> > +
>
> [ please refrain from unnecessary whitespace changes ]
>
>> > 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 <l.majewski@samsung.com>
>>
>> BTW: I've added Guenter to CC.
>>
>> --
>> Best regards,
>>
>> Lukasz Majewski
>>
>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-08 16:02 ` Anand Moon
(?)
@ 2015-04-08 16:53 ` Guenter Roeck
-1 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 16:53 UTC (permalink / raw)
To: Anand Moon
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> Hi Guenter,
>
> Initially the board bootup the cooling level state is 0.
> So update the duty cycle and this power off the fan.
> As their is no state change the fan will not spin.
>
> Once the temperature sensor is reached to alert temperature it changes state.
> With the state change the fan cools the CPU and then stop's
>
> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>
Sorry, I am missing something. I still don't see what problem you are fixing
with this patch. What behavior is wrong with the current code, and how does your
patch fix it ?
Guenter
> -Anand Moon
>
> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >> 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.
> >> >
> >
> > Unfortunately, the patch does not include an explanation why it is needed.
> >
> > The original code presumably did not update the duty cycle because
> > pwm was about to be disabled anyway. That kind of made sense to me.
> > Updating the duty cycle to 0 just to disable the pwm channel right
> > afterwards does not immediately make sense.
> >
> > Given that, I would expect to see a rationale here. Why is this patch needed ?
> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> > purpose of this patch ?
> >
> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
> > if so, the reationale will be needed in the changelog to explain to future
> > developers why this change was made.
> >
> > Thanks,
> > Guenter
> >
> >> > Tested on OdroidXU3 board.
> >> >
> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> > ---
> >> > 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);
> >> > +
> >
> > [ please refrain from unnecessary whitespace changes ]
> >
> >> > 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 <l.majewski@samsung.com>
> >>
> >> BTW: I've added Guenter to CC.
> >>
> >> --
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 16:53 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 16:53 UTC (permalink / raw)
To: Anand Moon
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> Hi Guenter,
>
> Initially the board bootup the cooling level state is 0.
> So update the duty cycle and this power off the fan.
> As their is no state change the fan will not spin.
>
> Once the temperature sensor is reached to alert temperature it changes state.
> With the state change the fan cools the CPU and then stop's
>
> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>
Sorry, I am missing something. I still don't see what problem you are fixing
with this patch. What behavior is wrong with the current code, and how does your
patch fix it ?
Guenter
> -Anand Moon
>
> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >> 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.
> >> >
> >
> > Unfortunately, the patch does not include an explanation why it is needed.
> >
> > The original code presumably did not update the duty cycle because
> > pwm was about to be disabled anyway. That kind of made sense to me.
> > Updating the duty cycle to 0 just to disable the pwm channel right
> > afterwards does not immediately make sense.
> >
> > Given that, I would expect to see a rationale here. Why is this patch needed ?
> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> > purpose of this patch ?
> >
> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
> > if so, the reationale will be needed in the changelog to explain to future
> > developers why this change was made.
> >
> > Thanks,
> > Guenter
> >
> >> > Tested on OdroidXU3 board.
> >> >
> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> > ---
> >> > 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);
> >> > +
> >
> > [ please refrain from unnecessary whitespace changes ]
> >
> >> > 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 <l.majewski@samsung.com>
> >>
> >> BTW: I've added Guenter to CC.
> >>
> >> --
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 16:53 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-08 16:53 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> Hi Guenter,
>
> Initially the board bootup the cooling level state is 0.
> So update the duty cycle and this power off the fan.
> As their is no state change the fan will not spin.
>
> Once the temperature sensor is reached to alert temperature it changes state.
> With the state change the fan cools the CPU and then stop's
>
> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>
Sorry, I am missing something. I still don't see what problem you are fixing
with this patch. What behavior is wrong with the current code, and how does your
patch fix it ?
Guenter
> -Anand Moon
>
> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >> 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.
> >> >
> >
> > Unfortunately, the patch does not include an explanation why it is needed.
> >
> > The original code presumably did not update the duty cycle because
> > pwm was about to be disabled anyway. That kind of made sense to me.
> > Updating the duty cycle to 0 just to disable the pwm channel right
> > afterwards does not immediately make sense.
> >
> > Given that, I would expect to see a rationale here. Why is this patch needed ?
> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> > purpose of this patch ?
> >
> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
> > if so, the reationale will be needed in the changelog to explain to future
> > developers why this change was made.
> >
> > Thanks,
> > Guenter
> >
> >> > Tested on OdroidXU3 board.
> >> >
> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> > ---
> >> > 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);
> >> > +
> >
> > [ please refrain from unnecessary whitespace changes ]
> >
> >> > 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 <l.majewski@samsung.com>
> >>
> >> BTW: I've added Guenter to CC.
> >>
> >> --
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-08 16:53 ` Guenter Roeck
(?)
@ 2015-04-08 17:49 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 17:49 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
Hi Guenter,
Sorry my blunder mistake. Sorry for the noise.
I just tested with spiking this patch and my observation and testing
were wrong we can skip this patch.
I will send an v2 patch series removing the patch 5 and patch 6.
With correct dts changes.
Thanks for pointing my mistake.
-Anand Moon
On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>> Hi Guenter,
>>
>> Initially the board bootup the cooling level state is 0.
>> So update the duty cycle and this power off the fan.
>> As their is no state change the fan will not spin.
>>
>> Once the temperature sensor is reached to alert temperature it changes state.
>> With the state change the fan cools the CPU and then stop's
>>
>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>
> Sorry, I am missing something. I still don't see what problem you are fixing
> with this patch. What behavior is wrong with the current code, and how does your
> patch fix it ?
>
> Guenter
>
>> -Anand Moon
>>
>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> >> 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.
>> >> >
>> >
>> > Unfortunately, the patch does not include an explanation why it is needed.
>> >
>> > The original code presumably did not update the duty cycle because
>> > pwm was about to be disabled anyway. That kind of made sense to me.
>> > Updating the duty cycle to 0 just to disable the pwm channel right
>> > afterwards does not immediately make sense.
>> >
>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>> > purpose of this patch ?
>> >
>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>> > if so, the reationale will be needed in the changelog to explain to future
>> > developers why this change was made.
>> >
>> > Thanks,
>> > Guenter
>> >
>> >> > Tested on OdroidXU3 board.
>> >> >
>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> > ---
>> >> > 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);
>> >> > +
>> >
>> > [ please refrain from unnecessary whitespace changes ]
>> >
>> >> > 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 <l.majewski@samsung.com>
>> >>
>> >> BTW: I've added Guenter to CC.
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> Lukasz Majewski
>> >>
>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 17:49 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 17:49 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel
Hi Guenter,
Sorry my blunder mistake. Sorry for the noise.
I just tested with spiking this patch and my observation and testing
were wrong we can skip this patch.
I will send an v2 patch series removing the patch 5 and patch 6.
With correct dts changes.
Thanks for pointing my mistake.
-Anand Moon
On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>> Hi Guenter,
>>
>> Initially the board bootup the cooling level state is 0.
>> So update the duty cycle and this power off the fan.
>> As their is no state change the fan will not spin.
>>
>> Once the temperature sensor is reached to alert temperature it changes state.
>> With the state change the fan cools the CPU and then stop's
>>
>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>
> Sorry, I am missing something. I still don't see what problem you are fixing
> with this patch. What behavior is wrong with the current code, and how does your
> patch fix it ?
>
> Guenter
>
>> -Anand Moon
>>
>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> >> 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.
>> >> >
>> >
>> > Unfortunately, the patch does not include an explanation why it is needed.
>> >
>> > The original code presumably did not update the duty cycle because
>> > pwm was about to be disabled anyway. That kind of made sense to me.
>> > Updating the duty cycle to 0 just to disable the pwm channel right
>> > afterwards does not immediately make sense.
>> >
>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>> > purpose of this patch ?
>> >
>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>> > if so, the reationale will be needed in the changelog to explain to future
>> > developers why this change was made.
>> >
>> > Thanks,
>> > Guenter
>> >
>> >> > Tested on OdroidXU3 board.
>> >> >
>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> > ---
>> >> > 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);
>> >> > +
>> >
>> > [ please refrain from unnecessary whitespace changes ]
>> >
>> >> > 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 <l.majewski@samsung.com>
>> >>
>> >> BTW: I've added Guenter to CC.
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> Lukasz Majewski
>> >>
>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-08 17:49 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-08 17:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guenter,
Sorry my blunder mistake. Sorry for the noise.
I just tested with spiking this patch and my observation and testing
were wrong we can skip this patch.
I will send an v2 patch series removing the patch 5 and patch 6.
With correct dts changes.
Thanks for pointing my mistake.
-Anand Moon
On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>> Hi Guenter,
>>
>> Initially the board bootup the cooling level state is 0.
>> So update the duty cycle and this power off the fan.
>> As their is no state change the fan will not spin.
>>
>> Once the temperature sensor is reached to alert temperature it changes state.
>> With the state change the fan cools the CPU and then stop's
>>
>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>
> Sorry, I am missing something. I still don't see what problem you are fixing
> with this patch. What behavior is wrong with the current code, and how does your
> patch fix it ?
>
> Guenter
>
>> -Anand Moon
>>
>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> >> 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.
>> >> >
>> >
>> > Unfortunately, the patch does not include an explanation why it is needed.
>> >
>> > The original code presumably did not update the duty cycle because
>> > pwm was about to be disabled anyway. That kind of made sense to me.
>> > Updating the duty cycle to 0 just to disable the pwm channel right
>> > afterwards does not immediately make sense.
>> >
>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>> > purpose of this patch ?
>> >
>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>> > if so, the reationale will be needed in the changelog to explain to future
>> > developers why this change was made.
>> >
>> > Thanks,
>> > Guenter
>> >
>> >> > Tested on OdroidXU3 board.
>> >> >
>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> > ---
>> >> > 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);
>> >> > +
>> >
>> > [ please refrain from unnecessary whitespace changes ]
>> >
>> >> > 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 <l.majewski@samsung.com>
>> >>
>> >> BTW: I've added Guenter to CC.
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> Lukasz Majewski
>> >>
>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-08 17:49 ` Anand Moon
(?)
@ 2015-04-10 11:28 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 11:28 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel, Markus Reichl
Hi Guenter/Lukasz,
Earlier I send v2 version of the patch spiking this one.
Markus Riechl came back to me with below mail.
So This patch confirms fixes the bug.
I will send v3 version of the patch. Earlier I was in delima about the bug.
-Anand Moon
-------------------------------------------
Hi Anand,
I tested your patch.
After booting the fan is spinning despite only 44°C.
/sys/class/thermal/cooling_device0/curstate is 0.
/sys/class/hwmon/hwmon4/pwm1 is 0
when I echo 1 > cur_state and then echo 0 > cur_state again,
the fan switches to off and behaves as expected.
It looks like there is a bug in initializing the pwm output
immediately after booting.
Best Regards,
--
Markus Reichl
On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> Hi Guenter,
>
> Sorry my blunder mistake. Sorry for the noise.
>
> I just tested with spiking this patch and my observation and testing
> were wrong we can skip this patch.
>
> I will send an v2 patch series removing the patch 5 and patch 6.
>
> With correct dts changes.
>
> Thanks for pointing my mistake.
>
> -Anand Moon
>
> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>> Hi Guenter,
>>>
>>> Initially the board bootup the cooling level state is 0.
>>> So update the duty cycle and this power off the fan.
>>> As their is no state change the fan will not spin.
>>>
>>> Once the temperature sensor is reached to alert temperature it changes state.
>>> With the state change the fan cools the CPU and then stop's
>>>
>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>>
>> Sorry, I am missing something. I still don't see what problem you are fixing
>> with this patch. What behavior is wrong with the current code, and how does your
>> patch fix it ?
>>
>> Guenter
>>
>>> -Anand Moon
>>>
>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>> >> 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.
>>> >> >
>>> >
>>> > Unfortunately, the patch does not include an explanation why it is needed.
>>> >
>>> > The original code presumably did not update the duty cycle because
>>> > pwm was about to be disabled anyway. That kind of made sense to me.
>>> > Updating the duty cycle to 0 just to disable the pwm channel right
>>> > afterwards does not immediately make sense.
>>> >
>>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>>> > purpose of this patch ?
>>> >
>>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>>> > if so, the reationale will be needed in the changelog to explain to future
>>> > developers why this change was made.
>>> >
>>> > Thanks,
>>> > Guenter
>>> >
>>> >> > Tested on OdroidXU3 board.
>>> >> >
>>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>> >> > ---
>>> >> > 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);
>>> >> > +
>>> >
>>> > [ please refrain from unnecessary whitespace changes ]
>>> >
>>> >> > 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 <l.majewski@samsung.com>
>>> >>
>>> >> BTW: I've added Guenter to CC.
>>> >>
>>> >> --
>>> >> Best regards,
>>> >>
>>> >> Lukasz Majewski
>>> >>
>>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 11:28 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 11:28 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukasz Majewski, Eduardo Valentin, Sjoerd Simons, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel, Markus Reichl
Hi Guenter/Lukasz,
Earlier I send v2 version of the patch spiking this one.
Markus Riechl came back to me with below mail.
So This patch confirms fixes the bug.
I will send v3 version of the patch. Earlier I was in delima about the bug.
-Anand Moon
-------------------------------------------
Hi Anand,
I tested your patch.
After booting the fan is spinning despite only 44°C.
/sys/class/thermal/cooling_device0/curstate is 0.
/sys/class/hwmon/hwmon4/pwm1 is 0
when I echo 1 > cur_state and then echo 0 > cur_state again,
the fan switches to off and behaves as expected.
It looks like there is a bug in initializing the pwm output
immediately after booting.
Best Regards,
--
Markus Reichl
On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> Hi Guenter,
>
> Sorry my blunder mistake. Sorry for the noise.
>
> I just tested with spiking this patch and my observation and testing
> were wrong we can skip this patch.
>
> I will send an v2 patch series removing the patch 5 and patch 6.
>
> With correct dts changes.
>
> Thanks for pointing my mistake.
>
> -Anand Moon
>
> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>> Hi Guenter,
>>>
>>> Initially the board bootup the cooling level state is 0.
>>> So update the duty cycle and this power off the fan.
>>> As their is no state change the fan will not spin.
>>>
>>> Once the temperature sensor is reached to alert temperature it changes state.
>>> With the state change the fan cools the CPU and then stop's
>>>
>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>>
>> Sorry, I am missing something. I still don't see what problem you are fixing
>> with this patch. What behavior is wrong with the current code, and how does your
>> patch fix it ?
>>
>> Guenter
>>
>>> -Anand Moon
>>>
>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>> >> 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.
>>> >> >
>>> >
>>> > Unfortunately, the patch does not include an explanation why it is needed.
>>> >
>>> > The original code presumably did not update the duty cycle because
>>> > pwm was about to be disabled anyway. That kind of made sense to me.
>>> > Updating the duty cycle to 0 just to disable the pwm channel right
>>> > afterwards does not immediately make sense.
>>> >
>>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>>> > purpose of this patch ?
>>> >
>>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>>> > if so, the reationale will be needed in the changelog to explain to future
>>> > developers why this change was made.
>>> >
>>> > Thanks,
>>> > Guenter
>>> >
>>> >> > Tested on OdroidXU3 board.
>>> >> >
>>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>> >> > ---
>>> >> > 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);
>>> >> > +
>>> >
>>> > [ please refrain from unnecessary whitespace changes ]
>>> >
>>> >> > 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 <l.majewski@samsung.com>
>>> >>
>>> >> BTW: I've added Guenter to CC.
>>> >>
>>> >> --
>>> >> Best regards,
>>> >>
>>> >> Lukasz Majewski
>>> >>
>>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 11:28 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 11:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guenter/Lukasz,
Earlier I send v2 version of the patch spiking this one.
Markus Riechl came back to me with below mail.
So This patch confirms fixes the bug.
I will send v3 version of the patch. Earlier I was in delima about the bug.
-Anand Moon
-------------------------------------------
Hi Anand,
I tested your patch.
After booting the fan is spinning despite only 44?C.
/sys/class/thermal/cooling_device0/curstate is 0.
/sys/class/hwmon/hwmon4/pwm1 is 0
when I echo 1 > cur_state and then echo 0 > cur_state again,
the fan switches to off and behaves as expected.
It looks like there is a bug in initializing the pwm output
immediately after booting.
Best Regards,
--
Markus Reichl
On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> Hi Guenter,
>
> Sorry my blunder mistake. Sorry for the noise.
>
> I just tested with spiking this patch and my observation and testing
> were wrong we can skip this patch.
>
> I will send an v2 patch series removing the patch 5 and patch 6.
>
> With correct dts changes.
>
> Thanks for pointing my mistake.
>
> -Anand Moon
>
> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>> Hi Guenter,
>>>
>>> Initially the board bootup the cooling level state is 0.
>>> So update the duty cycle and this power off the fan.
>>> As their is no state change the fan will not spin.
>>>
>>> Once the temperature sensor is reached to alert temperature it changes state.
>>> With the state change the fan cools the CPU and then stop's
>>>
>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>>
>> Sorry, I am missing something. I still don't see what problem you are fixing
>> with this patch. What behavior is wrong with the current code, and how does your
>> patch fix it ?
>>
>> Guenter
>>
>>> -Anand Moon
>>>
>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>> >> 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.
>>> >> >
>>> >
>>> > Unfortunately, the patch does not include an explanation why it is needed.
>>> >
>>> > The original code presumably did not update the duty cycle because
>>> > pwm was about to be disabled anyway. That kind of made sense to me.
>>> > Updating the duty cycle to 0 just to disable the pwm channel right
>>> > afterwards does not immediately make sense.
>>> >
>>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>>> > purpose of this patch ?
>>> >
>>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>>> > if so, the reationale will be needed in the changelog to explain to future
>>> > developers why this change was made.
>>> >
>>> > Thanks,
>>> > Guenter
>>> >
>>> >> > Tested on OdroidXU3 board.
>>> >> >
>>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>> >> > ---
>>> >> > 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);
>>> >> > +
>>> >
>>> > [ please refrain from unnecessary whitespace changes ]
>>> >
>>> >> > 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 <l.majewski@samsung.com>
>>> >>
>>> >> BTW: I've added Guenter to CC.
>>> >>
>>> >> --
>>> >> Best regards,
>>> >>
>>> >> Lukasz Majewski
>>> >>
>>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 11:28 ` Anand Moon
(?)
@ 2015-04-10 12:00 ` Sjoerd Simons
-1 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-10 12:00 UTC (permalink / raw)
To: Anand Moon, Thierry Reding
Cc: Guenter Roeck, Lukasz Majewski, Eduardo Valentin, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel, Markus Reichl
Hey Anand,
On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> Hi Guenter/Lukasz,
>
> Earlier I send v2 version of the patch spiking this one.
>
> Markus Riechl came back to me with below mail.
> So This patch confirms fixes the bug.
>
> I will send v3 version of the patch. Earlier I was in delima about the bug.
>
> -Anand Moon
> -------------------------------------------
> Hi Anand,
>
> I tested your patch.
>
> After booting the fan is spinning despite only 44°C.
>
> /sys/class/thermal/cooling_device0/curstate is 0.
> /sys/class/hwmon/hwmon4/pwm1 is 0
>
> when I echo 1 > cur_state and then echo 0 > cur_state again,
> the fan switches to off and behaves as expected.
>
> It looks like there is a bug in initializing the pwm output
> immediately after booting.
The problem here will be that at boot the PWM runs at full duty. With
the current exynos PWM drive if you disable the PWM it will stop pulsing
but remain high if it was at 100% duty. My patch on which you depend
upon fixed a race where disabling the pwm right after changing the duty
cycle (e.g. to 0%) also kept the signal high.
>From looking at other PWM users at the time it seemed that most if not
all always first set to duty to 0% and then disable the pwm. Which
should work fine on exynos now. However iirc Thierry recently clarified
that the expected result of pwm_disable is not just that the modulation
stops but also that the output signal goes low, although that's not very
explicit in the current pwm documentation.. The exynos PWM driver will
need another fix tweak to make that true.
> Best Regards,
> --
> Markus Reichl
>
> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> > Hi Guenter,
> >
> > Sorry my blunder mistake. Sorry for the noise.
> >
> > I just tested with spiking this patch and my observation and testing
> > were wrong we can skip this patch.
> >
> > I will send an v2 patch series removing the patch 5 and patch 6.
> >
> > With correct dts changes.
> >
> > Thanks for pointing my mistake.
> >
> > -Anand Moon
> >
> > On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> >> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> >>> Hi Guenter,
> >>>
> >>> Initially the board bootup the cooling level state is 0.
> >>> So update the duty cycle and this power off the fan.
> >>> As their is no state change the fan will not spin.
> >>>
> >>> Once the temperature sensor is reached to alert temperature it changes state.
> >>> With the state change the fan cools the CPU and then stop's
> >>>
> >>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> >>>
> >> Sorry, I am missing something. I still don't see what problem you are fixing
> >> with this patch. What behavior is wrong with the current code, and how does your
> >> patch fix it ?
> >>
> >> Guenter
> >>
> >>> -Anand Moon
> >>>
> >>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> >>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >>> >> 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.
> >>> >> >
> >>> >
> >>> > Unfortunately, the patch does not include an explanation why it is needed.
> >>> >
> >>> > The original code presumably did not update the duty cycle because
> >>> > pwm was about to be disabled anyway. That kind of made sense to me.
> >>> > Updating the duty cycle to 0 just to disable the pwm channel right
> >>> > afterwards does not immediately make sense.
> >>> >
> >>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
> >>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> >>> > purpose of this patch ?
> >>> >
> >>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
> >>> > if so, the reationale will be needed in the changelog to explain to future
> >>> > developers why this change was made.
> >>> >
> >>> > Thanks,
> >>> > Guenter
> >>> >
> >>> >> > Tested on OdroidXU3 board.
> >>> >> >
> >>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >>> >> > ---
> >>> >> > 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);
> >>> >> > +
> >>> >
> >>> > [ please refrain from unnecessary whitespace changes ]
> >>> >
> >>> >> > 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 <l.majewski@samsung.com>
> >>> >>
> >>> >> BTW: I've added Guenter to CC.
> >>> >>
> >>> >> --
> >>> >> Best regards,
> >>> >>
> >>> >> Lukasz Majewski
> >>> >>
> >>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 12:00 ` Sjoerd Simons
0 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-10 12:00 UTC (permalink / raw)
To: Anand Moon, Thierry Reding
Cc: Guenter Roeck, Lukasz Majewski, Eduardo Valentin, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel, Markus Reichl
Hey Anand,
On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> Hi Guenter/Lukasz,
>
> Earlier I send v2 version of the patch spiking this one.
>
> Markus Riechl came back to me with below mail.
> So This patch confirms fixes the bug.
>
> I will send v3 version of the patch. Earlier I was in delima about the bug.
>
> -Anand Moon
> -------------------------------------------
> Hi Anand,
>
> I tested your patch.
>
> After booting the fan is spinning despite only 44°C.
>
> /sys/class/thermal/cooling_device0/curstate is 0.
> /sys/class/hwmon/hwmon4/pwm1 is 0
>
> when I echo 1 > cur_state and then echo 0 > cur_state again,
> the fan switches to off and behaves as expected.
>
> It looks like there is a bug in initializing the pwm output
> immediately after booting.
The problem here will be that at boot the PWM runs at full duty. With
the current exynos PWM drive if you disable the PWM it will stop pulsing
but remain high if it was at 100% duty. My patch on which you depend
upon fixed a race where disabling the pwm right after changing the duty
cycle (e.g. to 0%) also kept the signal high.
From looking at other PWM users at the time it seemed that most if not
all always first set to duty to 0% and then disable the pwm. Which
should work fine on exynos now. However iirc Thierry recently clarified
that the expected result of pwm_disable is not just that the modulation
stops but also that the output signal goes low, although that's not very
explicit in the current pwm documentation.. The exynos PWM driver will
need another fix tweak to make that true.
> Best Regards,
> --
> Markus Reichl
>
> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> > Hi Guenter,
> >
> > Sorry my blunder mistake. Sorry for the noise.
> >
> > I just tested with spiking this patch and my observation and testing
> > were wrong we can skip this patch.
> >
> > I will send an v2 patch series removing the patch 5 and patch 6.
> >
> > With correct dts changes.
> >
> > Thanks for pointing my mistake.
> >
> > -Anand Moon
> >
> > On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> >> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> >>> Hi Guenter,
> >>>
> >>> Initially the board bootup the cooling level state is 0.
> >>> So update the duty cycle and this power off the fan.
> >>> As their is no state change the fan will not spin.
> >>>
> >>> Once the temperature sensor is reached to alert temperature it changes state.
> >>> With the state change the fan cools the CPU and then stop's
> >>>
> >>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> >>>
> >> Sorry, I am missing something. I still don't see what problem you are fixing
> >> with this patch. What behavior is wrong with the current code, and how does your
> >> patch fix it ?
> >>
> >> Guenter
> >>
> >>> -Anand Moon
> >>>
> >>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> >>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >>> >> 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.
> >>> >> >
> >>> >
> >>> > Unfortunately, the patch does not include an explanation why it is needed.
> >>> >
> >>> > The original code presumably did not update the duty cycle because
> >>> > pwm was about to be disabled anyway. That kind of made sense to me.
> >>> > Updating the duty cycle to 0 just to disable the pwm channel right
> >>> > afterwards does not immediately make sense.
> >>> >
> >>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
> >>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> >>> > purpose of this patch ?
> >>> >
> >>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
> >>> > if so, the reationale will be needed in the changelog to explain to future
> >>> > developers why this change was made.
> >>> >
> >>> > Thanks,
> >>> > Guenter
> >>> >
> >>> >> > Tested on OdroidXU3 board.
> >>> >> >
> >>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >>> >> > ---
> >>> >> > 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);
> >>> >> > +
> >>> >
> >>> > [ please refrain from unnecessary whitespace changes ]
> >>> >
> >>> >> > 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 <l.majewski@samsung.com>
> >>> >>
> >>> >> BTW: I've added Guenter to CC.
> >>> >>
> >>> >> --
> >>> >> Best regards,
> >>> >>
> >>> >> Lukasz Majewski
> >>> >>
> >>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 12:00 ` Sjoerd Simons
0 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-10 12:00 UTC (permalink / raw)
To: linux-arm-kernel
Hey Anand,
On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> Hi Guenter/Lukasz,
>
> Earlier I send v2 version of the patch spiking this one.
>
> Markus Riechl came back to me with below mail.
> So This patch confirms fixes the bug.
>
> I will send v3 version of the patch. Earlier I was in delima about the bug.
>
> -Anand Moon
> -------------------------------------------
> Hi Anand,
>
> I tested your patch.
>
> After booting the fan is spinning despite only 44?C.
>
> /sys/class/thermal/cooling_device0/curstate is 0.
> /sys/class/hwmon/hwmon4/pwm1 is 0
>
> when I echo 1 > cur_state and then echo 0 > cur_state again,
> the fan switches to off and behaves as expected.
>
> It looks like there is a bug in initializing the pwm output
> immediately after booting.
The problem here will be that at boot the PWM runs at full duty. With
the current exynos PWM drive if you disable the PWM it will stop pulsing
but remain high if it was at 100% duty. My patch on which you depend
upon fixed a race where disabling the pwm right after changing the duty
cycle (e.g. to 0%) also kept the signal high.
>From looking at other PWM users at the time it seemed that most if not
all always first set to duty to 0% and then disable the pwm. Which
should work fine on exynos now. However iirc Thierry recently clarified
that the expected result of pwm_disable is not just that the modulation
stops but also that the output signal goes low, although that's not very
explicit in the current pwm documentation.. The exynos PWM driver will
need another fix tweak to make that true.
> Best Regards,
> --
> Markus Reichl
>
> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> > Hi Guenter,
> >
> > Sorry my blunder mistake. Sorry for the noise.
> >
> > I just tested with spiking this patch and my observation and testing
> > were wrong we can skip this patch.
> >
> > I will send an v2 patch series removing the patch 5 and patch 6.
> >
> > With correct dts changes.
> >
> > Thanks for pointing my mistake.
> >
> > -Anand Moon
> >
> > On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> >> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> >>> Hi Guenter,
> >>>
> >>> Initially the board bootup the cooling level state is 0.
> >>> So update the duty cycle and this power off the fan.
> >>> As their is no state change the fan will not spin.
> >>>
> >>> Once the temperature sensor is reached to alert temperature it changes state.
> >>> With the state change the fan cools the CPU and then stop's
> >>>
> >>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> >>>
> >> Sorry, I am missing something. I still don't see what problem you are fixing
> >> with this patch. What behavior is wrong with the current code, and how does your
> >> patch fix it ?
> >>
> >> Guenter
> >>
> >>> -Anand Moon
> >>>
> >>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> >>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >>> >> 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.
> >>> >> >
> >>> >
> >>> > Unfortunately, the patch does not include an explanation why it is needed.
> >>> >
> >>> > The original code presumably did not update the duty cycle because
> >>> > pwm was about to be disabled anyway. That kind of made sense to me.
> >>> > Updating the duty cycle to 0 just to disable the pwm channel right
> >>> > afterwards does not immediately make sense.
> >>> >
> >>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
> >>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> >>> > purpose of this patch ?
> >>> >
> >>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
> >>> > if so, the reationale will be needed in the changelog to explain to future
> >>> > developers why this change was made.
> >>> >
> >>> > Thanks,
> >>> > Guenter
> >>> >
> >>> >> > Tested on OdroidXU3 board.
> >>> >> >
> >>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >>> >> > ---
> >>> >> > 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);
> >>> >> > +
> >>> >
> >>> > [ please refrain from unnecessary whitespace changes ]
> >>> >
> >>> >> > 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 <l.majewski@samsung.com>
> >>> >>
> >>> >> BTW: I've added Guenter to CC.
> >>> >>
> >>> >> --
> >>> >> Best regards,
> >>> >>
> >>> >> Lukasz Majewski
> >>> >>
> >>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 12:59 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 12:59 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Thierry Reding, Guenter Roeck, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
Hi Sjoerd,
I don't much advance knowledge on internal signaling of pwm-samsung module.
So do I need to send this patch again ?
-Anand Moon
On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> Hey Anand,
>
> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>> Hi Guenter/Lukasz,
>>
>> Earlier I send v2 version of the patch spiking this one.
>>
>> Markus Riechl came back to me with below mail.
>> So This patch confirms fixes the bug.
>>
>> I will send v3 version of the patch. Earlier I was in delima about the bug.
>>
>> -Anand Moon
>> -------------------------------------------
>> Hi Anand,
>>
>> I tested your patch.
>>
>> After booting the fan is spinning despite only 44°C.
>>
>> /sys/class/thermal/cooling_device0/curstate is 0.
>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>
>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>> the fan switches to off and behaves as expected.
>>
>> It looks like there is a bug in initializing the pwm output
>> immediately after booting.
>
> The problem here will be that at boot the PWM runs at full duty. With
> the current exynos PWM drive if you disable the PWM it will stop pulsing
> but remain high if it was at 100% duty. My patch on which you depend
> upon fixed a race where disabling the pwm right after changing the duty
> cycle (e.g. to 0%) also kept the signal high.
>
> From looking at other PWM users at the time it seemed that most if not
> all always first set to duty to 0% and then disable the pwm. Which
> should work fine on exynos now. However iirc Thierry recently clarified
> that the expected result of pwm_disable is not just that the modulation
> stops but also that the output signal goes low, although that's not very
> explicit in the current pwm documentation.. The exynos PWM driver will
> need another fix tweak to make that true.
>
>
>
>> Best Regards,
>
>
>
>> --
>> Markus Reichl
>>
>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>> > Hi Guenter,
>> >
>> > Sorry my blunder mistake. Sorry for the noise.
>> >
>> > I just tested with spiking this patch and my observation and testing
>> > were wrong we can skip this patch.
>> >
>> > I will send an v2 patch series removing the patch 5 and patch 6.
>> >
>> > With correct dts changes.
>> >
>> > Thanks for pointing my mistake.
>> >
>> > -Anand Moon
>> >
>> > On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>> >> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>> >>> Hi Guenter,
>> >>>
>> >>> Initially the board bootup the cooling level state is 0.
>> >>> So update the duty cycle and this power off the fan.
>> >>> As their is no state change the fan will not spin.
>> >>>
>> >>> Once the temperature sensor is reached to alert temperature it changes state.
>> >>> With the state change the fan cools the CPU and then stop's
>> >>>
>> >>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>> >>>
>> >> Sorry, I am missing something. I still don't see what problem you are fixing
>> >> with this patch. What behavior is wrong with the current code, and how does your
>> >> patch fix it ?
>> >>
>> >> Guenter
>> >>
>> >>> -Anand Moon
>> >>>
>> >>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>> >>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> >>> >> 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.
>> >>> >> >
>> >>> >
>> >>> > Unfortunately, the patch does not include an explanation why it is needed.
>> >>> >
>> >>> > The original code presumably did not update the duty cycle because
>> >>> > pwm was about to be disabled anyway. That kind of made sense to me.
>> >>> > Updating the duty cycle to 0 just to disable the pwm channel right
>> >>> > afterwards does not immediately make sense.
>> >>> >
>> >>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>> >>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>> >>> > purpose of this patch ?
>> >>> >
>> >>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>> >>> > if so, the reationale will be needed in the changelog to explain to future
>> >>> > developers why this change was made.
>> >>> >
>> >>> > Thanks,
>> >>> > Guenter
>> >>> >
>> >>> >> > Tested on OdroidXU3 board.
>> >>> >> >
>> >>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >>> >> > ---
>> >>> >> > 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);
>> >>> >> > +
>> >>> >
>> >>> > [ please refrain from unnecessary whitespace changes ]
>> >>> >
>> >>> >> > 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 <l.majewski@samsung.com>
>> >>> >>
>> >>> >> BTW: I've added Guenter to CC.
>> >>> >>
>> >>> >> --
>> >>> >> Best regards,
>> >>> >>
>> >>> >> Lukasz Majewski
>> >>> >>
>> >>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 12:59 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 12:59 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Thierry Reding, Guenter Roeck, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Markus Reichl
Hi Sjoerd,
I don't much advance knowledge on internal signaling of pwm-samsung module.
So do I need to send this patch again ?
-Anand Moon
On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> Hey Anand,
>
> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>> Hi Guenter/Lukasz,
>>
>> Earlier I send v2 version of the patch spiking this one.
>>
>> Markus Riechl came back to me with below mail.
>> So This patch confirms fixes the bug.
>>
>> I will send v3 version of the patch. Earlier I was in delima about the bug.
>>
>> -Anand Moon
>> -------------------------------------------
>> Hi Anand,
>>
>> I tested your patch.
>>
>> After booting the fan is spinning despite only 44°C.
>>
>> /sys/class/thermal/cooling_device0/curstate is 0.
>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>
>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>> the fan switches to off and behaves as expected.
>>
>> It looks like there is a bug in initializing the pwm output
>> immediately after booting.
>
> The problem here will be that at boot the PWM runs at full duty. With
> the current exynos PWM drive if you disable the PWM it will stop pulsing
> but remain high if it was at 100% duty. My patch on which you depend
> upon fixed a race where disabling the pwm right after changing the duty
> cycle (e.g. to 0%) also kept the signal high.
>
> From looking at other PWM users at the time it seemed that most if not
> all always first set to duty to 0% and then disable the pwm. Which
> should work fine on exynos now. However iirc Thierry recently clarified
> that the expected result of pwm_disable is not just that the modulation
> stops but also that the output signal goes low, although that's not very
> explicit in the current pwm documentation.. The exynos PWM driver will
> need another fix tweak to make that true.
>
>
>
>> Best Regards,
>
>
>
>> --
>> Markus Reichl
>>
>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Hi Guenter,
>> >
>> > Sorry my blunder mistake. Sorry for the noise.
>> >
>> > I just tested with spiking this patch and my observation and testing
>> > were wrong we can skip this patch.
>> >
>> > I will send an v2 patch series removing the patch 5 and patch 6.
>> >
>> > With correct dts changes.
>> >
>> > Thanks for pointing my mistake.
>> >
>> > -Anand Moon
>> >
>> > On 8 April 2015 at 22:23, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
>> >> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>> >>> Hi Guenter,
>> >>>
>> >>> Initially the board bootup the cooling level state is 0.
>> >>> So update the duty cycle and this power off the fan.
>> >>> As their is no state change the fan will not spin.
>> >>>
>> >>> Once the temperature sensor is reached to alert temperature it changes state.
>> >>> With the state change the fan cools the CPU and then stop's
>> >>>
>> >>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>> >>>
>> >> Sorry, I am missing something. I still don't see what problem you are fixing
>> >> with this patch. What behavior is wrong with the current code, and how does your
>> >> patch fix it ?
>> >>
>> >> Guenter
>> >>
>> >>> -Anand Moon
>> >>>
>> >>> On 8 April 2015 at 21:02, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
>> >>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> >>> >> 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.
>> >>> >> >
>> >>> >
>> >>> > Unfortunately, the patch does not include an explanation why it is needed.
>> >>> >
>> >>> > The original code presumably did not update the duty cycle because
>> >>> > pwm was about to be disabled anyway. That kind of made sense to me.
>> >>> > Updating the duty cycle to 0 just to disable the pwm channel right
>> >>> > afterwards does not immediately make sense.
>> >>> >
>> >>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>> >>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>> >>> > purpose of this patch ?
>> >>> >
>> >>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>> >>> > if so, the reationale will be needed in the changelog to explain to future
>> >>> > developers why this change was made.
>> >>> >
>> >>> > Thanks,
>> >>> > Guenter
>> >>> >
>> >>> >> > Tested on OdroidXU3 board.
>> >>> >> >
>> >>> >> > Signed-off-by: Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >>> >> > ---
>> >>> >> > 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);
>> >>> >> > +
>> >>> >
>> >>> > [ please refrain from unnecessary whitespace changes ]
>> >>> >
>> >>> >> > 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 <l.majewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> >>> >>
>> >>> >> 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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 12:59 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sjoerd,
I don't much advance knowledge on internal signaling of pwm-samsung module.
So do I need to send this patch again ?
-Anand Moon
On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> Hey Anand,
>
> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>> Hi Guenter/Lukasz,
>>
>> Earlier I send v2 version of the patch spiking this one.
>>
>> Markus Riechl came back to me with below mail.
>> So This patch confirms fixes the bug.
>>
>> I will send v3 version of the patch. Earlier I was in delima about the bug.
>>
>> -Anand Moon
>> -------------------------------------------
>> Hi Anand,
>>
>> I tested your patch.
>>
>> After booting the fan is spinning despite only 44?C.
>>
>> /sys/class/thermal/cooling_device0/curstate is 0.
>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>
>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>> the fan switches to off and behaves as expected.
>>
>> It looks like there is a bug in initializing the pwm output
>> immediately after booting.
>
> The problem here will be that at boot the PWM runs at full duty. With
> the current exynos PWM drive if you disable the PWM it will stop pulsing
> but remain high if it was at 100% duty. My patch on which you depend
> upon fixed a race where disabling the pwm right after changing the duty
> cycle (e.g. to 0%) also kept the signal high.
>
> From looking at other PWM users at the time it seemed that most if not
> all always first set to duty to 0% and then disable the pwm. Which
> should work fine on exynos now. However iirc Thierry recently clarified
> that the expected result of pwm_disable is not just that the modulation
> stops but also that the output signal goes low, although that's not very
> explicit in the current pwm documentation.. The exynos PWM driver will
> need another fix tweak to make that true.
>
>
>
>> Best Regards,
>
>
>
>> --
>> Markus Reichl
>>
>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>> > Hi Guenter,
>> >
>> > Sorry my blunder mistake. Sorry for the noise.
>> >
>> > I just tested with spiking this patch and my observation and testing
>> > were wrong we can skip this patch.
>> >
>> > I will send an v2 patch series removing the patch 5 and patch 6.
>> >
>> > With correct dts changes.
>> >
>> > Thanks for pointing my mistake.
>> >
>> > -Anand Moon
>> >
>> > On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>> >> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>> >>> Hi Guenter,
>> >>>
>> >>> Initially the board bootup the cooling level state is 0.
>> >>> So update the duty cycle and this power off the fan.
>> >>> As their is no state change the fan will not spin.
>> >>>
>> >>> Once the temperature sensor is reached to alert temperature it changes state.
>> >>> With the state change the fan cools the CPU and then stop's
>> >>>
>> >>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>> >>>
>> >> Sorry, I am missing something. I still don't see what problem you are fixing
>> >> with this patch. What behavior is wrong with the current code, and how does your
>> >> patch fix it ?
>> >>
>> >> Guenter
>> >>
>> >>> -Anand Moon
>> >>>
>> >>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>> >>> > On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>> >>> >> 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.
>> >>> >> >
>> >>> >
>> >>> > Unfortunately, the patch does not include an explanation why it is needed.
>> >>> >
>> >>> > The original code presumably did not update the duty cycle because
>> >>> > pwm was about to be disabled anyway. That kind of made sense to me.
>> >>> > Updating the duty cycle to 0 just to disable the pwm channel right
>> >>> > afterwards does not immediately make sense.
>> >>> >
>> >>> > Given that, I would expect to see a rationale here. Why is this patch needed ?
>> >>> > Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>> >>> > purpose of this patch ?
>> >>> >
>> >>> > Maybe that is all explained in patch 0/6, which I was not copied on. Even
>> >>> > if so, the reationale will be needed in the changelog to explain to future
>> >>> > developers why this change was made.
>> >>> >
>> >>> > Thanks,
>> >>> > Guenter
>> >>> >
>> >>> >> > Tested on OdroidXU3 board.
>> >>> >> >
>> >>> >> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >>> >> > ---
>> >>> >> > 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);
>> >>> >> > +
>> >>> >
>> >>> > [ please refrain from unnecessary whitespace changes ]
>> >>> >
>> >>> >> > 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 <l.majewski@samsung.com>
>> >>> >>
>> >>> >> BTW: I've added Guenter to CC.
>> >>> >>
>> >>> >> --
>> >>> >> Best regards,
>> >>> >>
>> >>> >> Lukasz Majewski
>> >>> >>
>> >>> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 12:59 ` Anand Moon
(?)
@ 2015-04-10 13:09 ` Guenter Roeck
-1 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-10 13:09 UTC (permalink / raw)
To: Anand Moon, Sjoerd Simons
Cc: Thierry Reding, Lukasz Majewski, Eduardo Valentin, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel, Markus Reichl
On 04/10/2015 05:59 AM, Anand Moon wrote:
> Hi Sjoerd,
>
> I don't much advance knowledge on internal signaling of pwm-samsung module.
>
> So do I need to send this patch again ?
>
From the context, it seems that the fix in hwmon would only paint
over a problem in the actual pwm driver, correct ?
If you resubmit the patch I would expect you to explain this in the
commit log.
Guenter
> -Anand Moon
>
>
> On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>> Hey Anand,
>>
>> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>>> Hi Guenter/Lukasz,
>>>
>>> Earlier I send v2 version of the patch spiking this one.
>>>
>>> Markus Riechl came back to me with below mail.
>>> So This patch confirms fixes the bug.
>>>
>>> I will send v3 version of the patch. Earlier I was in delima about the bug.
>>>
>>> -Anand Moon
>>> -------------------------------------------
>>> Hi Anand,
>>>
>>> I tested your patch.
>>>
>>> After booting the fan is spinning despite only 44°C.
>>>
>>> /sys/class/thermal/cooling_device0/curstate is 0.
>>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>>
>>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>>> the fan switches to off and behaves as expected.
>>>
>>> It looks like there is a bug in initializing the pwm output
>>> immediately after booting.
>>
>> The problem here will be that at boot the PWM runs at full duty. With
>> the current exynos PWM drive if you disable the PWM it will stop pulsing
>> but remain high if it was at 100% duty. My patch on which you depend
>> upon fixed a race where disabling the pwm right after changing the duty
>> cycle (e.g. to 0%) also kept the signal high.
>>
>> From looking at other PWM users at the time it seemed that most if not
>> all always first set to duty to 0% and then disable the pwm. Which
>> should work fine on exynos now. However iirc Thierry recently clarified
>> that the expected result of pwm_disable is not just that the modulation
>> stops but also that the output signal goes low, although that's not very
>> explicit in the current pwm documentation.. The exynos PWM driver will
>> need another fix tweak to make that true.
>>
>>
>>
>>> Best Regards,
>>
>>
>>
>>> --
>>> Markus Reichl
>>>
>>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>>>> Hi Guenter,
>>>>
>>>> Sorry my blunder mistake. Sorry for the noise.
>>>>
>>>> I just tested with spiking this patch and my observation and testing
>>>> were wrong we can skip this patch.
>>>>
>>>> I will send an v2 patch series removing the patch 5 and patch 6.
>>>>
>>>> With correct dts changes.
>>>>
>>>> Thanks for pointing my mistake.
>>>>
>>>> -Anand Moon
>>>>
>>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>>>>> Hi Guenter,
>>>>>>
>>>>>> Initially the board bootup the cooling level state is 0.
>>>>>> So update the duty cycle and this power off the fan.
>>>>>> As their is no state change the fan will not spin.
>>>>>>
>>>>>> Once the temperature sensor is reached to alert temperature it changes state.
>>>>>> With the state change the fan cools the CPU and then stop's
>>>>>>
>>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>>>>>
>>>>> Sorry, I am missing something. I still don't see what problem you are fixing
>>>>> with this patch. What behavior is wrong with the current code, and how does your
>>>>> patch fix it ?
>>>>>
>>>>> Guenter
>>>>>
>>>>>> -Anand Moon
>>>>>>
>>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>
>>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
>>>>>>>
>>>>>>> The original code presumably did not update the duty cycle because
>>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
>>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
>>>>>>> afterwards does not immediately make sense.
>>>>>>>
>>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
>>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>>>>>>> purpose of this patch ?
>>>>>>>
>>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
>>>>>>> if so, the reationale will be needed in the changelog to explain to future
>>>>>>> developers why this change was made.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Guenter
>>>>>>>
>>>>>>>>> Tested on OdroidXU3 board.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>>>>>>>> ---
>>>>>>>>> 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);
>>>>>>>>> +
>>>>>>>
>>>>>>> [ please refrain from unnecessary whitespace changes ]
>>>>>>>
>>>>>>>>> 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 <l.majewski@samsung.com>
>>>>>>>>
>>>>>>>> BTW: I've added Guenter to CC.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Lukasz Majewski
>>>>>>>>
>>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:09 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-10 13:09 UTC (permalink / raw)
To: Anand Moon, Sjoerd Simons
Cc: Thierry Reding, Lukasz Majewski, Eduardo Valentin, Russell King,
Kukjin Kim, devicetree, linux-samsung-soc, linux-pwm,
linux-kernel, linux-arm-kernel, Markus Reichl
On 04/10/2015 05:59 AM, Anand Moon wrote:
> Hi Sjoerd,
>
> I don't much advance knowledge on internal signaling of pwm-samsung module.
>
> So do I need to send this patch again ?
>
From the context, it seems that the fix in hwmon would only paint
over a problem in the actual pwm driver, correct ?
If you resubmit the patch I would expect you to explain this in the
commit log.
Guenter
> -Anand Moon
>
>
> On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>> Hey Anand,
>>
>> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>>> Hi Guenter/Lukasz,
>>>
>>> Earlier I send v2 version of the patch spiking this one.
>>>
>>> Markus Riechl came back to me with below mail.
>>> So This patch confirms fixes the bug.
>>>
>>> I will send v3 version of the patch. Earlier I was in delima about the bug.
>>>
>>> -Anand Moon
>>> -------------------------------------------
>>> Hi Anand,
>>>
>>> I tested your patch.
>>>
>>> After booting the fan is spinning despite only 44°C.
>>>
>>> /sys/class/thermal/cooling_device0/curstate is 0.
>>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>>
>>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>>> the fan switches to off and behaves as expected.
>>>
>>> It looks like there is a bug in initializing the pwm output
>>> immediately after booting.
>>
>> The problem here will be that at boot the PWM runs at full duty. With
>> the current exynos PWM drive if you disable the PWM it will stop pulsing
>> but remain high if it was at 100% duty. My patch on which you depend
>> upon fixed a race where disabling the pwm right after changing the duty
>> cycle (e.g. to 0%) also kept the signal high.
>>
>> From looking at other PWM users at the time it seemed that most if not
>> all always first set to duty to 0% and then disable the pwm. Which
>> should work fine on exynos now. However iirc Thierry recently clarified
>> that the expected result of pwm_disable is not just that the modulation
>> stops but also that the output signal goes low, although that's not very
>> explicit in the current pwm documentation.. The exynos PWM driver will
>> need another fix tweak to make that true.
>>
>>
>>
>>> Best Regards,
>>
>>
>>
>>> --
>>> Markus Reichl
>>>
>>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>>>> Hi Guenter,
>>>>
>>>> Sorry my blunder mistake. Sorry for the noise.
>>>>
>>>> I just tested with spiking this patch and my observation and testing
>>>> were wrong we can skip this patch.
>>>>
>>>> I will send an v2 patch series removing the patch 5 and patch 6.
>>>>
>>>> With correct dts changes.
>>>>
>>>> Thanks for pointing my mistake.
>>>>
>>>> -Anand Moon
>>>>
>>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>>>>> Hi Guenter,
>>>>>>
>>>>>> Initially the board bootup the cooling level state is 0.
>>>>>> So update the duty cycle and this power off the fan.
>>>>>> As their is no state change the fan will not spin.
>>>>>>
>>>>>> Once the temperature sensor is reached to alert temperature it changes state.
>>>>>> With the state change the fan cools the CPU and then stop's
>>>>>>
>>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>>>>>
>>>>> Sorry, I am missing something. I still don't see what problem you are fixing
>>>>> with this patch. What behavior is wrong with the current code, and how does your
>>>>> patch fix it ?
>>>>>
>>>>> Guenter
>>>>>
>>>>>> -Anand Moon
>>>>>>
>>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>
>>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
>>>>>>>
>>>>>>> The original code presumably did not update the duty cycle because
>>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
>>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
>>>>>>> afterwards does not immediately make sense.
>>>>>>>
>>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
>>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>>>>>>> purpose of this patch ?
>>>>>>>
>>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
>>>>>>> if so, the reationale will be needed in the changelog to explain to future
>>>>>>> developers why this change was made.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Guenter
>>>>>>>
>>>>>>>>> Tested on OdroidXU3 board.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>>>>>>>> ---
>>>>>>>>> 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);
>>>>>>>>> +
>>>>>>>
>>>>>>> [ please refrain from unnecessary whitespace changes ]
>>>>>>>
>>>>>>>>> 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 <l.majewski@samsung.com>
>>>>>>>>
>>>>>>>> BTW: I've added Guenter to CC.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Lukasz Majewski
>>>>>>>>
>>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:09 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-10 13:09 UTC (permalink / raw)
To: linux-arm-kernel
On 04/10/2015 05:59 AM, Anand Moon wrote:
> Hi Sjoerd,
>
> I don't much advance knowledge on internal signaling of pwm-samsung module.
>
> So do I need to send this patch again ?
>
From the context, it seems that the fix in hwmon would only paint
over a problem in the actual pwm driver, correct ?
If you resubmit the patch I would expect you to explain this in the
commit log.
Guenter
> -Anand Moon
>
>
> On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>> Hey Anand,
>>
>> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>>> Hi Guenter/Lukasz,
>>>
>>> Earlier I send v2 version of the patch spiking this one.
>>>
>>> Markus Riechl came back to me with below mail.
>>> So This patch confirms fixes the bug.
>>>
>>> I will send v3 version of the patch. Earlier I was in delima about the bug.
>>>
>>> -Anand Moon
>>> -------------------------------------------
>>> Hi Anand,
>>>
>>> I tested your patch.
>>>
>>> After booting the fan is spinning despite only 44?C.
>>>
>>> /sys/class/thermal/cooling_device0/curstate is 0.
>>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>>
>>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>>> the fan switches to off and behaves as expected.
>>>
>>> It looks like there is a bug in initializing the pwm output
>>> immediately after booting.
>>
>> The problem here will be that at boot the PWM runs at full duty. With
>> the current exynos PWM drive if you disable the PWM it will stop pulsing
>> but remain high if it was at 100% duty. My patch on which you depend
>> upon fixed a race where disabling the pwm right after changing the duty
>> cycle (e.g. to 0%) also kept the signal high.
>>
>> From looking at other PWM users at the time it seemed that most if not
>> all always first set to duty to 0% and then disable the pwm. Which
>> should work fine on exynos now. However iirc Thierry recently clarified
>> that the expected result of pwm_disable is not just that the modulation
>> stops but also that the output signal goes low, although that's not very
>> explicit in the current pwm documentation.. The exynos PWM driver will
>> need another fix tweak to make that true.
>>
>>
>>
>>> Best Regards,
>>
>>
>>
>>> --
>>> Markus Reichl
>>>
>>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>>>> Hi Guenter,
>>>>
>>>> Sorry my blunder mistake. Sorry for the noise.
>>>>
>>>> I just tested with spiking this patch and my observation and testing
>>>> were wrong we can skip this patch.
>>>>
>>>> I will send an v2 patch series removing the patch 5 and patch 6.
>>>>
>>>> With correct dts changes.
>>>>
>>>> Thanks for pointing my mistake.
>>>>
>>>> -Anand Moon
>>>>
>>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>>>>> Hi Guenter,
>>>>>>
>>>>>> Initially the board bootup the cooling level state is 0.
>>>>>> So update the duty cycle and this power off the fan.
>>>>>> As their is no state change the fan will not spin.
>>>>>>
>>>>>> Once the temperature sensor is reached to alert temperature it changes state.
>>>>>> With the state change the fan cools the CPU and then stop's
>>>>>>
>>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
>>>>>>
>>>>> Sorry, I am missing something. I still don't see what problem you are fixing
>>>>> with this patch. What behavior is wrong with the current code, and how does your
>>>>> patch fix it ?
>>>>>
>>>>> Guenter
>>>>>
>>>>>> -Anand Moon
>>>>>>
>>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>
>>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
>>>>>>>
>>>>>>> The original code presumably did not update the duty cycle because
>>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
>>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
>>>>>>> afterwards does not immediately make sense.
>>>>>>>
>>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
>>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
>>>>>>> purpose of this patch ?
>>>>>>>
>>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
>>>>>>> if so, the reationale will be needed in the changelog to explain to future
>>>>>>> developers why this change was made.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Guenter
>>>>>>>
>>>>>>>>> Tested on OdroidXU3 board.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>>>>>>>> ---
>>>>>>>>> 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);
>>>>>>>>> +
>>>>>>>
>>>>>>> [ please refrain from unnecessary whitespace changes ]
>>>>>>>
>>>>>>>>> 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 <l.majewski@samsung.com>
>>>>>>>>
>>>>>>>> BTW: I've added Guenter to CC.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Lukasz Majewski
>>>>>>>>
>>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 13:09 ` Guenter Roeck
(?)
@ 2015-04-10 13:17 ` Anand Moon
-1 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 13:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Sjoerd Simons, Thierry Reding, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
Hi Guenter,
I will do so.
-Anand Moon
On 10 April 2015 at 18:39, Guenter Roeck <linux@roeck-us.net> wrote:
> On 04/10/2015 05:59 AM, Anand Moon wrote:
>>
>> Hi Sjoerd,
>>
>> I don't much advance knowledge on internal signaling of pwm-samsung
>> module.
>>
>> So do I need to send this patch again ?
>>
>
> From the context, it seems that the fix in hwmon would only paint
> over a problem in the actual pwm driver, correct ?
>
> If you resubmit the patch I would expect you to explain this in the
> commit log.
>
> Guenter
>
>
>> -Anand Moon
>>
>>
>> On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>> wrote:
>>>
>>> Hey Anand,
>>>
>>> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>>>>
>>>> Hi Guenter/Lukasz,
>>>>
>>>> Earlier I send v2 version of the patch spiking this one.
>>>>
>>>> Markus Riechl came back to me with below mail.
>>>> So This patch confirms fixes the bug.
>>>>
>>>> I will send v3 version of the patch. Earlier I was in delima about the
>>>> bug.
>>>>
>>>> -Anand Moon
>>>> -------------------------------------------
>>>> Hi Anand,
>>>>
>>>> I tested your patch.
>>>>
>>>> After booting the fan is spinning despite only 44°C.
>>>>
>>>> /sys/class/thermal/cooling_device0/curstate is 0.
>>>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>>>
>>>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>>>> the fan switches to off and behaves as expected.
>>>>
>>>> It looks like there is a bug in initializing the pwm output
>>>> immediately after booting.
>>>
>>>
>>> The problem here will be that at boot the PWM runs at full duty. With
>>> the current exynos PWM drive if you disable the PWM it will stop pulsing
>>> but remain high if it was at 100% duty. My patch on which you depend
>>> upon fixed a race where disabling the pwm right after changing the duty
>>> cycle (e.g. to 0%) also kept the signal high.
>>>
>>> From looking at other PWM users at the time it seemed that most if not
>>> all always first set to duty to 0% and then disable the pwm. Which
>>> should work fine on exynos now. However iirc Thierry recently clarified
>>> that the expected result of pwm_disable is not just that the modulation
>>> stops but also that the output signal goes low, although that's not very
>>> explicit in the current pwm documentation.. The exynos PWM driver will
>>> need another fix tweak to make that true.
>>>
>>>
>>>
>>>> Best Regards,
>>>
>>>
>>>
>>>
>>>> --
>>>> Markus Reichl
>>>>
>>>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>>>>>
>>>>> Hi Guenter,
>>>>>
>>>>> Sorry my blunder mistake. Sorry for the noise.
>>>>>
>>>>> I just tested with spiking this patch and my observation and testing
>>>>> were wrong we can skip this patch.
>>>>>
>>>>> I will send an v2 patch series removing the patch 5 and patch 6.
>>>>>
>>>>> With correct dts changes.
>>>>>
>>>>> Thanks for pointing my mistake.
>>>>>
>>>>> -Anand Moon
>>>>>
>>>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>
>>>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>>>>>>
>>>>>>> Hi Guenter,
>>>>>>>
>>>>>>> Initially the board bootup the cooling level state is 0.
>>>>>>> So update the duty cycle and this power off the fan.
>>>>>>> As their is no state change the fan will not spin.
>>>>>>>
>>>>>>> Once the temperature sensor is reached to alert temperature it
>>>>>>> changes state.
>>>>>>> With the state change the fan cools the CPU and then stop's
>>>>>>>
>>>>>>> I have observed this state change with tmon utility in
>>>>>>> linux/tools/thermal/tmon/
>>>>>>>
>>>>>> Sorry, I am missing something. I still don't see what problem you are
>>>>>> fixing
>>>>>> with this patch. What behavior is wrong with the current code, and how
>>>>>> does your
>>>>>> patch fix it ?
>>>>>>
>>>>>> Guenter
>>>>>>
>>>>>>> -Anand Moon
>>>>>>>
>>>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>>>
>>>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately, the patch does not include an explanation why it is
>>>>>>>> needed.
>>>>>>>>
>>>>>>>> The original code presumably did not update the duty cycle because
>>>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
>>>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
>>>>>>>> afterwards does not immediately make sense.
>>>>>>>>
>>>>>>>> Given that, I would expect to see a rationale here. Why is this
>>>>>>>> patch needed ?
>>>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is
>>>>>>>> the
>>>>>>>> purpose of this patch ?
>>>>>>>>
>>>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on.
>>>>>>>> Even
>>>>>>>> if so, the reationale will be needed in the changelog to explain to
>>>>>>>> future
>>>>>>>> developers why this change was made.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Guenter
>>>>>>>>
>>>>>>>>>> Tested on OdroidXU3 board.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>> 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);
>>>>>>>>>> +
>>>>>>>>
>>>>>>>>
>>>>>>>> [ please refrain from unnecessary whitespace changes ]
>>>>>>>>
>>>>>>>>>> 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 <l.majewski@samsung.com>
>>>>>>>>>
>>>>>>>>> BTW: I've added Guenter to CC.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Lukasz Majewski
>>>>>>>>>
>>>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>>
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:17 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 13:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Sjoerd Simons, Thierry Reding, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
Hi Guenter,
I will do so.
-Anand Moon
On 10 April 2015 at 18:39, Guenter Roeck <linux@roeck-us.net> wrote:
> On 04/10/2015 05:59 AM, Anand Moon wrote:
>>
>> Hi Sjoerd,
>>
>> I don't much advance knowledge on internal signaling of pwm-samsung
>> module.
>>
>> So do I need to send this patch again ?
>>
>
> From the context, it seems that the fix in hwmon would only paint
> over a problem in the actual pwm driver, correct ?
>
> If you resubmit the patch I would expect you to explain this in the
> commit log.
>
> Guenter
>
>
>> -Anand Moon
>>
>>
>> On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>> wrote:
>>>
>>> Hey Anand,
>>>
>>> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>>>>
>>>> Hi Guenter/Lukasz,
>>>>
>>>> Earlier I send v2 version of the patch spiking this one.
>>>>
>>>> Markus Riechl came back to me with below mail.
>>>> So This patch confirms fixes the bug.
>>>>
>>>> I will send v3 version of the patch. Earlier I was in delima about the
>>>> bug.
>>>>
>>>> -Anand Moon
>>>> -------------------------------------------
>>>> Hi Anand,
>>>>
>>>> I tested your patch.
>>>>
>>>> After booting the fan is spinning despite only 44°C.
>>>>
>>>> /sys/class/thermal/cooling_device0/curstate is 0.
>>>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>>>
>>>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>>>> the fan switches to off and behaves as expected.
>>>>
>>>> It looks like there is a bug in initializing the pwm output
>>>> immediately after booting.
>>>
>>>
>>> The problem here will be that at boot the PWM runs at full duty. With
>>> the current exynos PWM drive if you disable the PWM it will stop pulsing
>>> but remain high if it was at 100% duty. My patch on which you depend
>>> upon fixed a race where disabling the pwm right after changing the duty
>>> cycle (e.g. to 0%) also kept the signal high.
>>>
>>> From looking at other PWM users at the time it seemed that most if not
>>> all always first set to duty to 0% and then disable the pwm. Which
>>> should work fine on exynos now. However iirc Thierry recently clarified
>>> that the expected result of pwm_disable is not just that the modulation
>>> stops but also that the output signal goes low, although that's not very
>>> explicit in the current pwm documentation.. The exynos PWM driver will
>>> need another fix tweak to make that true.
>>>
>>>
>>>
>>>> Best Regards,
>>>
>>>
>>>
>>>
>>>> --
>>>> Markus Reichl
>>>>
>>>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>>>>>
>>>>> Hi Guenter,
>>>>>
>>>>> Sorry my blunder mistake. Sorry for the noise.
>>>>>
>>>>> I just tested with spiking this patch and my observation and testing
>>>>> were wrong we can skip this patch.
>>>>>
>>>>> I will send an v2 patch series removing the patch 5 and patch 6.
>>>>>
>>>>> With correct dts changes.
>>>>>
>>>>> Thanks for pointing my mistake.
>>>>>
>>>>> -Anand Moon
>>>>>
>>>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>
>>>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>>>>>>
>>>>>>> Hi Guenter,
>>>>>>>
>>>>>>> Initially the board bootup the cooling level state is 0.
>>>>>>> So update the duty cycle and this power off the fan.
>>>>>>> As their is no state change the fan will not spin.
>>>>>>>
>>>>>>> Once the temperature sensor is reached to alert temperature it
>>>>>>> changes state.
>>>>>>> With the state change the fan cools the CPU and then stop's
>>>>>>>
>>>>>>> I have observed this state change with tmon utility in
>>>>>>> linux/tools/thermal/tmon/
>>>>>>>
>>>>>> Sorry, I am missing something. I still don't see what problem you are
>>>>>> fixing
>>>>>> with this patch. What behavior is wrong with the current code, and how
>>>>>> does your
>>>>>> patch fix it ?
>>>>>>
>>>>>> Guenter
>>>>>>
>>>>>>> -Anand Moon
>>>>>>>
>>>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>>>
>>>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately, the patch does not include an explanation why it is
>>>>>>>> needed.
>>>>>>>>
>>>>>>>> The original code presumably did not update the duty cycle because
>>>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
>>>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
>>>>>>>> afterwards does not immediately make sense.
>>>>>>>>
>>>>>>>> Given that, I would expect to see a rationale here. Why is this
>>>>>>>> patch needed ?
>>>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is
>>>>>>>> the
>>>>>>>> purpose of this patch ?
>>>>>>>>
>>>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on.
>>>>>>>> Even
>>>>>>>> if so, the reationale will be needed in the changelog to explain to
>>>>>>>> future
>>>>>>>> developers why this change was made.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Guenter
>>>>>>>>
>>>>>>>>>> Tested on OdroidXU3 board.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>> 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);
>>>>>>>>>> +
>>>>>>>>
>>>>>>>>
>>>>>>>> [ please refrain from unnecessary whitespace changes ]
>>>>>>>>
>>>>>>>>>> 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 <l.majewski@samsung.com>
>>>>>>>>>
>>>>>>>>> BTW: I've added Guenter to CC.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Lukasz Majewski
>>>>>>>>>
>>>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>>
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:17 ` Anand Moon
0 siblings, 0 replies; 86+ messages in thread
From: Anand Moon @ 2015-04-10 13:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guenter,
I will do so.
-Anand Moon
On 10 April 2015 at 18:39, Guenter Roeck <linux@roeck-us.net> wrote:
> On 04/10/2015 05:59 AM, Anand Moon wrote:
>>
>> Hi Sjoerd,
>>
>> I don't much advance knowledge on internal signaling of pwm-samsung
>> module.
>>
>> So do I need to send this patch again ?
>>
>
> From the context, it seems that the fix in hwmon would only paint
> over a problem in the actual pwm driver, correct ?
>
> If you resubmit the patch I would expect you to explain this in the
> commit log.
>
> Guenter
>
>
>> -Anand Moon
>>
>>
>> On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>> wrote:
>>>
>>> Hey Anand,
>>>
>>> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
>>>>
>>>> Hi Guenter/Lukasz,
>>>>
>>>> Earlier I send v2 version of the patch spiking this one.
>>>>
>>>> Markus Riechl came back to me with below mail.
>>>> So This patch confirms fixes the bug.
>>>>
>>>> I will send v3 version of the patch. Earlier I was in delima about the
>>>> bug.
>>>>
>>>> -Anand Moon
>>>> -------------------------------------------
>>>> Hi Anand,
>>>>
>>>> I tested your patch.
>>>>
>>>> After booting the fan is spinning despite only 44?C.
>>>>
>>>> /sys/class/thermal/cooling_device0/curstate is 0.
>>>> /sys/class/hwmon/hwmon4/pwm1 is 0
>>>>
>>>> when I echo 1 > cur_state and then echo 0 > cur_state again,
>>>> the fan switches to off and behaves as expected.
>>>>
>>>> It looks like there is a bug in initializing the pwm output
>>>> immediately after booting.
>>>
>>>
>>> The problem here will be that at boot the PWM runs at full duty. With
>>> the current exynos PWM drive if you disable the PWM it will stop pulsing
>>> but remain high if it was at 100% duty. My patch on which you depend
>>> upon fixed a race where disabling the pwm right after changing the duty
>>> cycle (e.g. to 0%) also kept the signal high.
>>>
>>> From looking at other PWM users at the time it seemed that most if not
>>> all always first set to duty to 0% and then disable the pwm. Which
>>> should work fine on exynos now. However iirc Thierry recently clarified
>>> that the expected result of pwm_disable is not just that the modulation
>>> stops but also that the output signal goes low, although that's not very
>>> explicit in the current pwm documentation.. The exynos PWM driver will
>>> need another fix tweak to make that true.
>>>
>>>
>>>
>>>> Best Regards,
>>>
>>>
>>>
>>>
>>>> --
>>>> Markus Reichl
>>>>
>>>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
>>>>>
>>>>> Hi Guenter,
>>>>>
>>>>> Sorry my blunder mistake. Sorry for the noise.
>>>>>
>>>>> I just tested with spiking this patch and my observation and testing
>>>>> were wrong we can skip this patch.
>>>>>
>>>>> I will send an v2 patch series removing the patch 5 and patch 6.
>>>>>
>>>>> With correct dts changes.
>>>>>
>>>>> Thanks for pointing my mistake.
>>>>>
>>>>> -Anand Moon
>>>>>
>>>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>
>>>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
>>>>>>>
>>>>>>> Hi Guenter,
>>>>>>>
>>>>>>> Initially the board bootup the cooling level state is 0.
>>>>>>> So update the duty cycle and this power off the fan.
>>>>>>> As their is no state change the fan will not spin.
>>>>>>>
>>>>>>> Once the temperature sensor is reached to alert temperature it
>>>>>>> changes state.
>>>>>>> With the state change the fan cools the CPU and then stop's
>>>>>>>
>>>>>>> I have observed this state change with tmon utility in
>>>>>>> linux/tools/thermal/tmon/
>>>>>>>
>>>>>> Sorry, I am missing something. I still don't see what problem you are
>>>>>> fixing
>>>>>> with this patch. What behavior is wrong with the current code, and how
>>>>>> does your
>>>>>> patch fix it ?
>>>>>>
>>>>>> Guenter
>>>>>>
>>>>>>> -Anand Moon
>>>>>>>
>>>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>>>
>>>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately, the patch does not include an explanation why it is
>>>>>>>> needed.
>>>>>>>>
>>>>>>>> The original code presumably did not update the duty cycle because
>>>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
>>>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
>>>>>>>> afterwards does not immediately make sense.
>>>>>>>>
>>>>>>>> Given that, I would expect to see a rationale here. Why is this
>>>>>>>> patch needed ?
>>>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is
>>>>>>>> the
>>>>>>>> purpose of this patch ?
>>>>>>>>
>>>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on.
>>>>>>>> Even
>>>>>>>> if so, the reationale will be needed in the changelog to explain to
>>>>>>>> future
>>>>>>>> developers why this change was made.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Guenter
>>>>>>>>
>>>>>>>>>> Tested on OdroidXU3 board.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>> 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);
>>>>>>>>>> +
>>>>>>>>
>>>>>>>>
>>>>>>>> [ please refrain from unnecessary whitespace changes ]
>>>>>>>>
>>>>>>>>>> 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 <l.majewski@samsung.com>
>>>>>>>>>
>>>>>>>>> BTW: I've added Guenter to CC.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Lukasz Majewski
>>>>>>>>>
>>>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>>
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 13:09 ` Guenter Roeck
(?)
@ 2015-04-10 13:30 ` Sjoerd Simons
-1 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-10 13:30 UTC (permalink / raw)
To: Guenter Roeck
Cc: Anand Moon, Thierry Reding, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl,
linux-pwm
On Fri, 2015-04-10 at 06:09 -0700, Guenter Roeck wrote:
> On 04/10/2015 05:59 AM, Anand Moon wrote:
> > Hi Sjoerd,
> >
> > I don't much advance knowledge on internal signaling of pwm-samsung module.
> >
> > So do I need to send this patch again ?
> >
>
> From the context, it seems that the fix in hwmon would only paint
> over a problem in the actual pwm driver, correct ?
Yes/no/maybe :). Imho this is something to clarify in the pwm API
documentation. As currently all it says is:
"pwm_disable - stop a PWM output toggling",
Which is what the exynos driver does.
Thierry, could you clearify what the intention is here? I'm happy to
prepare a pwm driver patch if needed to solve this?
> If you resubmit the patch I would expect you to explain this in the
> commit log.
>
> Guenter
>
> > -Anand Moon
> >
> >
> > On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> >> Hey Anand,
> >>
> >> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> >>> Hi Guenter/Lukasz,
> >>>
> >>> Earlier I send v2 version of the patch spiking this one.
> >>>
> >>> Markus Riechl came back to me with below mail.
> >>> So This patch confirms fixes the bug.
> >>>
> >>> I will send v3 version of the patch. Earlier I was in delima about the bug.
> >>>
> >>> -Anand Moon
> >>> -------------------------------------------
> >>> Hi Anand,
> >>>
> >>> I tested your patch.
> >>>
> >>> After booting the fan is spinning despite only 44°C.
> >>>
> >>> /sys/class/thermal/cooling_device0/curstate is 0.
> >>> /sys/class/hwmon/hwmon4/pwm1 is 0
> >>>
> >>> when I echo 1 > cur_state and then echo 0 > cur_state again,
> >>> the fan switches to off and behaves as expected.
> >>>
> >>> It looks like there is a bug in initializing the pwm output
> >>> immediately after booting.
> >>
> >> The problem here will be that at boot the PWM runs at full duty. With
> >> the current exynos PWM drive if you disable the PWM it will stop pulsing
> >> but remain high if it was at 100% duty. My patch on which you depend
> >> upon fixed a race where disabling the pwm right after changing the duty
> >> cycle (e.g. to 0%) also kept the signal high.
> >>
> >> From looking at other PWM users at the time it seemed that most if not
> >> all always first set to duty to 0% and then disable the pwm. Which
> >> should work fine on exynos now. However iirc Thierry recently clarified
> >> that the expected result of pwm_disable is not just that the modulation
> >> stops but also that the output signal goes low, although that's not very
> >> explicit in the current pwm documentation.. The exynos PWM driver will
> >> need another fix tweak to make that true.
> >>
> >>
> >>
> >>> Best Regards,
> >>
> >>
> >>
> >>> --
> >>> Markus Reichl
> >>>
> >>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> >>>> Hi Guenter,
> >>>>
> >>>> Sorry my blunder mistake. Sorry for the noise.
> >>>>
> >>>> I just tested with spiking this patch and my observation and testing
> >>>> were wrong we can skip this patch.
> >>>>
> >>>> I will send an v2 patch series removing the patch 5 and patch 6.
> >>>>
> >>>> With correct dts changes.
> >>>>
> >>>> Thanks for pointing my mistake.
> >>>>
> >>>> -Anand Moon
> >>>>
> >>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> >>>>>> Hi Guenter,
> >>>>>>
> >>>>>> Initially the board bootup the cooling level state is 0.
> >>>>>> So update the duty cycle and this power off the fan.
> >>>>>> As their is no state change the fan will not spin.
> >>>>>>
> >>>>>> Once the temperature sensor is reached to alert temperature it changes state.
> >>>>>> With the state change the fan cools the CPU and then stop's
> >>>>>>
> >>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> >>>>>>
> >>>>> Sorry, I am missing something. I still don't see what problem you are fixing
> >>>>> with this patch. What behavior is wrong with the current code, and how does your
> >>>>> patch fix it ?
> >>>>>
> >>>>> Guenter
> >>>>>
> >>>>>> -Anand Moon
> >>>>>>
> >>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>
> >>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
> >>>>>>>
> >>>>>>> The original code presumably did not update the duty cycle because
> >>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
> >>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
> >>>>>>> afterwards does not immediately make sense.
> >>>>>>>
> >>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
> >>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> >>>>>>> purpose of this patch ?
> >>>>>>>
> >>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> >>>>>>> if so, the reationale will be needed in the changelog to explain to future
> >>>>>>> developers why this change was made.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Guenter
> >>>>>>>
> >>>>>>>>> Tested on OdroidXU3 board.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >>>>>>>>> ---
> >>>>>>>>> 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);
> >>>>>>>>> +
> >>>>>>>
> >>>>>>> [ please refrain from unnecessary whitespace changes ]
> >>>>>>>
> >>>>>>>>> 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 <l.majewski@samsung.com>
> >>>>>>>>
> >>>>>>>> BTW: I've added Guenter to CC.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>> Lukasz Majewski
> >>>>>>>>
> >>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >>
> >>
> >
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:30 ` Sjoerd Simons
0 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-10 13:30 UTC (permalink / raw)
To: Guenter Roeck
Cc: Anand Moon, Thierry Reding, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
On Fri, 2015-04-10 at 06:09 -0700, Guenter Roeck wrote:
> On 04/10/2015 05:59 AM, Anand Moon wrote:
> > Hi Sjoerd,
> >
> > I don't much advance knowledge on internal signaling of pwm-samsung module.
> >
> > So do I need to send this patch again ?
> >
>
> From the context, it seems that the fix in hwmon would only paint
> over a problem in the actual pwm driver, correct ?
Yes/no/maybe :). Imho this is something to clarify in the pwm API
documentation. As currently all it says is:
"pwm_disable - stop a PWM output toggling",
Which is what the exynos driver does.
Thierry, could you clearify what the intention is here? I'm happy to
prepare a pwm driver patch if needed to solve this?
> If you resubmit the patch I would expect you to explain this in the
> commit log.
>
> Guenter
>
> > -Anand Moon
> >
> >
> > On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> >> Hey Anand,
> >>
> >> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> >>> Hi Guenter/Lukasz,
> >>>
> >>> Earlier I send v2 version of the patch spiking this one.
> >>>
> >>> Markus Riechl came back to me with below mail.
> >>> So This patch confirms fixes the bug.
> >>>
> >>> I will send v3 version of the patch. Earlier I was in delima about the bug.
> >>>
> >>> -Anand Moon
> >>> -------------------------------------------
> >>> Hi Anand,
> >>>
> >>> I tested your patch.
> >>>
> >>> After booting the fan is spinning despite only 44°C.
> >>>
> >>> /sys/class/thermal/cooling_device0/curstate is 0.
> >>> /sys/class/hwmon/hwmon4/pwm1 is 0
> >>>
> >>> when I echo 1 > cur_state and then echo 0 > cur_state again,
> >>> the fan switches to off and behaves as expected.
> >>>
> >>> It looks like there is a bug in initializing the pwm output
> >>> immediately after booting.
> >>
> >> The problem here will be that at boot the PWM runs at full duty. With
> >> the current exynos PWM drive if you disable the PWM it will stop pulsing
> >> but remain high if it was at 100% duty. My patch on which you depend
> >> upon fixed a race where disabling the pwm right after changing the duty
> >> cycle (e.g. to 0%) also kept the signal high.
> >>
> >> From looking at other PWM users at the time it seemed that most if not
> >> all always first set to duty to 0% and then disable the pwm. Which
> >> should work fine on exynos now. However iirc Thierry recently clarified
> >> that the expected result of pwm_disable is not just that the modulation
> >> stops but also that the output signal goes low, although that's not very
> >> explicit in the current pwm documentation.. The exynos PWM driver will
> >> need another fix tweak to make that true.
> >>
> >>
> >>
> >>> Best Regards,
> >>
> >>
> >>
> >>> --
> >>> Markus Reichl
> >>>
> >>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> >>>> Hi Guenter,
> >>>>
> >>>> Sorry my blunder mistake. Sorry for the noise.
> >>>>
> >>>> I just tested with spiking this patch and my observation and testing
> >>>> were wrong we can skip this patch.
> >>>>
> >>>> I will send an v2 patch series removing the patch 5 and patch 6.
> >>>>
> >>>> With correct dts changes.
> >>>>
> >>>> Thanks for pointing my mistake.
> >>>>
> >>>> -Anand Moon
> >>>>
> >>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> >>>>>> Hi Guenter,
> >>>>>>
> >>>>>> Initially the board bootup the cooling level state is 0.
> >>>>>> So update the duty cycle and this power off the fan.
> >>>>>> As their is no state change the fan will not spin.
> >>>>>>
> >>>>>> Once the temperature sensor is reached to alert temperature it changes state.
> >>>>>> With the state change the fan cools the CPU and then stop's
> >>>>>>
> >>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> >>>>>>
> >>>>> Sorry, I am missing something. I still don't see what problem you are fixing
> >>>>> with this patch. What behavior is wrong with the current code, and how does your
> >>>>> patch fix it ?
> >>>>>
> >>>>> Guenter
> >>>>>
> >>>>>> -Anand Moon
> >>>>>>
> >>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>
> >>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
> >>>>>>>
> >>>>>>> The original code presumably did not update the duty cycle because
> >>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
> >>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
> >>>>>>> afterwards does not immediately make sense.
> >>>>>>>
> >>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
> >>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> >>>>>>> purpose of this patch ?
> >>>>>>>
> >>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> >>>>>>> if so, the reationale will be needed in the changelog to explain to future
> >>>>>>> developers why this change was made.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Guenter
> >>>>>>>
> >>>>>>>>> Tested on OdroidXU3 board.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >>>>>>>>> ---
> >>>>>>>>> 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);
> >>>>>>>>> +
> >>>>>>>
> >>>>>>> [ please refrain from unnecessary whitespace changes ]
> >>>>>>>
> >>>>>>>>> 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 <l.majewski@samsung.com>
> >>>>>>>>
> >>>>>>>> BTW: I've added Guenter to CC.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>> Lukasz Majewski
> >>>>>>>>
> >>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >>
> >>
> >
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:30 ` Sjoerd Simons
0 siblings, 0 replies; 86+ messages in thread
From: Sjoerd Simons @ 2015-04-10 13:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2015-04-10 at 06:09 -0700, Guenter Roeck wrote:
> On 04/10/2015 05:59 AM, Anand Moon wrote:
> > Hi Sjoerd,
> >
> > I don't much advance knowledge on internal signaling of pwm-samsung module.
> >
> > So do I need to send this patch again ?
> >
>
> From the context, it seems that the fix in hwmon would only paint
> over a problem in the actual pwm driver, correct ?
Yes/no/maybe :). Imho this is something to clarify in the pwm API
documentation. As currently all it says is:
"pwm_disable - stop a PWM output toggling",
Which is what the exynos driver does.
Thierry, could you clearify what the intention is here? I'm happy to
prepare a pwm driver patch if needed to solve this?
> If you resubmit the patch I would expect you to explain this in the
> commit log.
>
> Guenter
>
> > -Anand Moon
> >
> >
> > On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> >> Hey Anand,
> >>
> >> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> >>> Hi Guenter/Lukasz,
> >>>
> >>> Earlier I send v2 version of the patch spiking this one.
> >>>
> >>> Markus Riechl came back to me with below mail.
> >>> So This patch confirms fixes the bug.
> >>>
> >>> I will send v3 version of the patch. Earlier I was in delima about the bug.
> >>>
> >>> -Anand Moon
> >>> -------------------------------------------
> >>> Hi Anand,
> >>>
> >>> I tested your patch.
> >>>
> >>> After booting the fan is spinning despite only 44?C.
> >>>
> >>> /sys/class/thermal/cooling_device0/curstate is 0.
> >>> /sys/class/hwmon/hwmon4/pwm1 is 0
> >>>
> >>> when I echo 1 > cur_state and then echo 0 > cur_state again,
> >>> the fan switches to off and behaves as expected.
> >>>
> >>> It looks like there is a bug in initializing the pwm output
> >>> immediately after booting.
> >>
> >> The problem here will be that at boot the PWM runs at full duty. With
> >> the current exynos PWM drive if you disable the PWM it will stop pulsing
> >> but remain high if it was at 100% duty. My patch on which you depend
> >> upon fixed a race where disabling the pwm right after changing the duty
> >> cycle (e.g. to 0%) also kept the signal high.
> >>
> >> From looking at other PWM users at the time it seemed that most if not
> >> all always first set to duty to 0% and then disable the pwm. Which
> >> should work fine on exynos now. However iirc Thierry recently clarified
> >> that the expected result of pwm_disable is not just that the modulation
> >> stops but also that the output signal goes low, although that's not very
> >> explicit in the current pwm documentation.. The exynos PWM driver will
> >> need another fix tweak to make that true.
> >>
> >>
> >>
> >>> Best Regards,
> >>
> >>
> >>
> >>> --
> >>> Markus Reichl
> >>>
> >>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> >>>> Hi Guenter,
> >>>>
> >>>> Sorry my blunder mistake. Sorry for the noise.
> >>>>
> >>>> I just tested with spiking this patch and my observation and testing
> >>>> were wrong we can skip this patch.
> >>>>
> >>>> I will send an v2 patch series removing the patch 5 and patch 6.
> >>>>
> >>>> With correct dts changes.
> >>>>
> >>>> Thanks for pointing my mistake.
> >>>>
> >>>> -Anand Moon
> >>>>
> >>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> >>>>>> Hi Guenter,
> >>>>>>
> >>>>>> Initially the board bootup the cooling level state is 0.
> >>>>>> So update the duty cycle and this power off the fan.
> >>>>>> As their is no state change the fan will not spin.
> >>>>>>
> >>>>>> Once the temperature sensor is reached to alert temperature it changes state.
> >>>>>> With the state change the fan cools the CPU and then stop's
> >>>>>>
> >>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> >>>>>>
> >>>>> Sorry, I am missing something. I still don't see what problem you are fixing
> >>>>> with this patch. What behavior is wrong with the current code, and how does your
> >>>>> patch fix it ?
> >>>>>
> >>>>> Guenter
> >>>>>
> >>>>>> -Anand Moon
> >>>>>>
> >>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> >>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>
> >>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
> >>>>>>>
> >>>>>>> The original code presumably did not update the duty cycle because
> >>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
> >>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
> >>>>>>> afterwards does not immediately make sense.
> >>>>>>>
> >>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
> >>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> >>>>>>> purpose of this patch ?
> >>>>>>>
> >>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> >>>>>>> if so, the reationale will be needed in the changelog to explain to future
> >>>>>>> developers why this change was made.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Guenter
> >>>>>>>
> >>>>>>>>> Tested on OdroidXU3 board.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >>>>>>>>> ---
> >>>>>>>>> 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);
> >>>>>>>>> +
> >>>>>>>
> >>>>>>> [ please refrain from unnecessary whitespace changes ]
> >>>>>>>
> >>>>>>>>> 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 <l.majewski@samsung.com>
> >>>>>>>>
> >>>>>>>> BTW: I've added Guenter to CC.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>> Lukasz Majewski
> >>>>>>>>
> >>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >>
> >>
> >
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 13:30 ` Sjoerd Simons
(?)
@ 2015-04-10 13:58 ` Thierry Reding
-1 siblings, 0 replies; 86+ messages in thread
From: Thierry Reding @ 2015-04-10 13:58 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Guenter Roeck, Anand Moon, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
[-- Attachment #1: Type: text/plain, Size: 8941 bytes --]
On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
> On Fri, 2015-04-10 at 06:09 -0700, Guenter Roeck wrote:
> > On 04/10/2015 05:59 AM, Anand Moon wrote:
> > > Hi Sjoerd,
> > >
> > > I don't much advance knowledge on internal signaling of pwm-samsung module.
> > >
> > > So do I need to send this patch again ?
> > >
> >
> > From the context, it seems that the fix in hwmon would only paint
> > over a problem in the actual pwm driver, correct ?
>
> Yes/no/maybe :). Imho this is something to clarify in the pwm API
> documentation. As currently all it says is:
> "pwm_disable - stop a PWM output toggling",
>
> Which is what the exynos driver does.
>
> Thierry, could you clearify what the intention is here? I'm happy to
> prepare a pwm driver patch if needed to solve this?
I think the safest thing to do is for users to do both. You call
pwm_config() with a zero duty cycle to make it clear what the status is
that you want. Then you call pwm_disable() to state that you don't need
the output signal anymore, so that any clocks needed by the PWM can be
stopped. Doing so gives the driver the most information and should make
the user more resilient against any possible quirks in drivers.
Drivers that on pwm_disable() still invert the signal should still be
fixed, though. In the cases that I'm aware of the sequence of setting
the duty cycle to 0 and calling pwm_disable() won't actually paper over
any bugs. It's precisely that sequence that triggers the bug. Merely
calling pwm_disable() should trigger it as well, pwm_config(0) without
pwm_disable() would hide it.
Thierry
> > If you resubmit the patch I would expect you to explain this in the
> > commit log.
> >
> > Guenter
> >
> > > -Anand Moon
> > >
> > >
> > > On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> > >> Hey Anand,
> > >>
> > >> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> > >>> Hi Guenter/Lukasz,
> > >>>
> > >>> Earlier I send v2 version of the patch spiking this one.
> > >>>
> > >>> Markus Riechl came back to me with below mail.
> > >>> So This patch confirms fixes the bug.
> > >>>
> > >>> I will send v3 version of the patch. Earlier I was in delima about the bug.
> > >>>
> > >>> -Anand Moon
> > >>> -------------------------------------------
> > >>> Hi Anand,
> > >>>
> > >>> I tested your patch.
> > >>>
> > >>> After booting the fan is spinning despite only 44°C.
> > >>>
> > >>> /sys/class/thermal/cooling_device0/curstate is 0.
> > >>> /sys/class/hwmon/hwmon4/pwm1 is 0
> > >>>
> > >>> when I echo 1 > cur_state and then echo 0 > cur_state again,
> > >>> the fan switches to off and behaves as expected.
> > >>>
> > >>> It looks like there is a bug in initializing the pwm output
> > >>> immediately after booting.
> > >>
> > >> The problem here will be that at boot the PWM runs at full duty. With
> > >> the current exynos PWM drive if you disable the PWM it will stop pulsing
> > >> but remain high if it was at 100% duty. My patch on which you depend
> > >> upon fixed a race where disabling the pwm right after changing the duty
> > >> cycle (e.g. to 0%) also kept the signal high.
> > >>
> > >> From looking at other PWM users at the time it seemed that most if not
> > >> all always first set to duty to 0% and then disable the pwm. Which
> > >> should work fine on exynos now. However iirc Thierry recently clarified
> > >> that the expected result of pwm_disable is not just that the modulation
> > >> stops but also that the output signal goes low, although that's not very
> > >> explicit in the current pwm documentation.. The exynos PWM driver will
> > >> need another fix tweak to make that true.
> > >>
> > >>
> > >>
> > >>> Best Regards,
> > >>
> > >>
> > >>
> > >>> --
> > >>> Markus Reichl
> > >>>
> > >>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> > >>>> Hi Guenter,
> > >>>>
> > >>>> Sorry my blunder mistake. Sorry for the noise.
> > >>>>
> > >>>> I just tested with spiking this patch and my observation and testing
> > >>>> were wrong we can skip this patch.
> > >>>>
> > >>>> I will send an v2 patch series removing the patch 5 and patch 6.
> > >>>>
> > >>>> With correct dts changes.
> > >>>>
> > >>>> Thanks for pointing my mistake.
> > >>>>
> > >>>> -Anand Moon
> > >>>>
> > >>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> > >>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> > >>>>>> Hi Guenter,
> > >>>>>>
> > >>>>>> Initially the board bootup the cooling level state is 0.
> > >>>>>> So update the duty cycle and this power off the fan.
> > >>>>>> As their is no state change the fan will not spin.
> > >>>>>>
> > >>>>>> Once the temperature sensor is reached to alert temperature it changes state.
> > >>>>>> With the state change the fan cools the CPU and then stop's
> > >>>>>>
> > >>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> > >>>>>>
> > >>>>> Sorry, I am missing something. I still don't see what problem you are fixing
> > >>>>> with this patch. What behavior is wrong with the current code, and how does your
> > >>>>> patch fix it ?
> > >>>>>
> > >>>>> Guenter
> > >>>>>
> > >>>>>> -Anand Moon
> > >>>>>>
> > >>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> > >>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> > >>>>>>>> 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.
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
> > >>>>>>>
> > >>>>>>> The original code presumably did not update the duty cycle because
> > >>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
> > >>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
> > >>>>>>> afterwards does not immediately make sense.
> > >>>>>>>
> > >>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
> > >>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> > >>>>>>> purpose of this patch ?
> > >>>>>>>
> > >>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> > >>>>>>> if so, the reationale will be needed in the changelog to explain to future
> > >>>>>>> developers why this change was made.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Guenter
> > >>>>>>>
> > >>>>>>>>> Tested on OdroidXU3 board.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > >>>>>>>>> ---
> > >>>>>>>>> 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);
> > >>>>>>>>> +
> > >>>>>>>
> > >>>>>>> [ please refrain from unnecessary whitespace changes ]
> > >>>>>>>
> > >>>>>>>>> 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 <l.majewski@samsung.com>
> > >>>>>>>>
> > >>>>>>>> BTW: I've added Guenter to CC.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Best regards,
> > >>>>>>>>
> > >>>>>>>> Lukasz Majewski
> > >>>>>>>>
> > >>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> > >>
> > >>
> > >
> >
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:58 ` Thierry Reding
0 siblings, 0 replies; 86+ messages in thread
From: Thierry Reding @ 2015-04-10 13:58 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Guenter Roeck, Anand Moon, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
[-- Attachment #1: Type: text/plain, Size: 8941 bytes --]
On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
> On Fri, 2015-04-10 at 06:09 -0700, Guenter Roeck wrote:
> > On 04/10/2015 05:59 AM, Anand Moon wrote:
> > > Hi Sjoerd,
> > >
> > > I don't much advance knowledge on internal signaling of pwm-samsung module.
> > >
> > > So do I need to send this patch again ?
> > >
> >
> > From the context, it seems that the fix in hwmon would only paint
> > over a problem in the actual pwm driver, correct ?
>
> Yes/no/maybe :). Imho this is something to clarify in the pwm API
> documentation. As currently all it says is:
> "pwm_disable - stop a PWM output toggling",
>
> Which is what the exynos driver does.
>
> Thierry, could you clearify what the intention is here? I'm happy to
> prepare a pwm driver patch if needed to solve this?
I think the safest thing to do is for users to do both. You call
pwm_config() with a zero duty cycle to make it clear what the status is
that you want. Then you call pwm_disable() to state that you don't need
the output signal anymore, so that any clocks needed by the PWM can be
stopped. Doing so gives the driver the most information and should make
the user more resilient against any possible quirks in drivers.
Drivers that on pwm_disable() still invert the signal should still be
fixed, though. In the cases that I'm aware of the sequence of setting
the duty cycle to 0 and calling pwm_disable() won't actually paper over
any bugs. It's precisely that sequence that triggers the bug. Merely
calling pwm_disable() should trigger it as well, pwm_config(0) without
pwm_disable() would hide it.
Thierry
> > If you resubmit the patch I would expect you to explain this in the
> > commit log.
> >
> > Guenter
> >
> > > -Anand Moon
> > >
> > >
> > > On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> > >> Hey Anand,
> > >>
> > >> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> > >>> Hi Guenter/Lukasz,
> > >>>
> > >>> Earlier I send v2 version of the patch spiking this one.
> > >>>
> > >>> Markus Riechl came back to me with below mail.
> > >>> So This patch confirms fixes the bug.
> > >>>
> > >>> I will send v3 version of the patch. Earlier I was in delima about the bug.
> > >>>
> > >>> -Anand Moon
> > >>> -------------------------------------------
> > >>> Hi Anand,
> > >>>
> > >>> I tested your patch.
> > >>>
> > >>> After booting the fan is spinning despite only 44°C.
> > >>>
> > >>> /sys/class/thermal/cooling_device0/curstate is 0.
> > >>> /sys/class/hwmon/hwmon4/pwm1 is 0
> > >>>
> > >>> when I echo 1 > cur_state and then echo 0 > cur_state again,
> > >>> the fan switches to off and behaves as expected.
> > >>>
> > >>> It looks like there is a bug in initializing the pwm output
> > >>> immediately after booting.
> > >>
> > >> The problem here will be that at boot the PWM runs at full duty. With
> > >> the current exynos PWM drive if you disable the PWM it will stop pulsing
> > >> but remain high if it was at 100% duty. My patch on which you depend
> > >> upon fixed a race where disabling the pwm right after changing the duty
> > >> cycle (e.g. to 0%) also kept the signal high.
> > >>
> > >> From looking at other PWM users at the time it seemed that most if not
> > >> all always first set to duty to 0% and then disable the pwm. Which
> > >> should work fine on exynos now. However iirc Thierry recently clarified
> > >> that the expected result of pwm_disable is not just that the modulation
> > >> stops but also that the output signal goes low, although that's not very
> > >> explicit in the current pwm documentation.. The exynos PWM driver will
> > >> need another fix tweak to make that true.
> > >>
> > >>
> > >>
> > >>> Best Regards,
> > >>
> > >>
> > >>
> > >>> --
> > >>> Markus Reichl
> > >>>
> > >>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> > >>>> Hi Guenter,
> > >>>>
> > >>>> Sorry my blunder mistake. Sorry for the noise.
> > >>>>
> > >>>> I just tested with spiking this patch and my observation and testing
> > >>>> were wrong we can skip this patch.
> > >>>>
> > >>>> I will send an v2 patch series removing the patch 5 and patch 6.
> > >>>>
> > >>>> With correct dts changes.
> > >>>>
> > >>>> Thanks for pointing my mistake.
> > >>>>
> > >>>> -Anand Moon
> > >>>>
> > >>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> > >>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> > >>>>>> Hi Guenter,
> > >>>>>>
> > >>>>>> Initially the board bootup the cooling level state is 0.
> > >>>>>> So update the duty cycle and this power off the fan.
> > >>>>>> As their is no state change the fan will not spin.
> > >>>>>>
> > >>>>>> Once the temperature sensor is reached to alert temperature it changes state.
> > >>>>>> With the state change the fan cools the CPU and then stop's
> > >>>>>>
> > >>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> > >>>>>>
> > >>>>> Sorry, I am missing something. I still don't see what problem you are fixing
> > >>>>> with this patch. What behavior is wrong with the current code, and how does your
> > >>>>> patch fix it ?
> > >>>>>
> > >>>>> Guenter
> > >>>>>
> > >>>>>> -Anand Moon
> > >>>>>>
> > >>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> > >>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> > >>>>>>>> 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.
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
> > >>>>>>>
> > >>>>>>> The original code presumably did not update the duty cycle because
> > >>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
> > >>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
> > >>>>>>> afterwards does not immediately make sense.
> > >>>>>>>
> > >>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
> > >>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> > >>>>>>> purpose of this patch ?
> > >>>>>>>
> > >>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> > >>>>>>> if so, the reationale will be needed in the changelog to explain to future
> > >>>>>>> developers why this change was made.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Guenter
> > >>>>>>>
> > >>>>>>>>> Tested on OdroidXU3 board.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > >>>>>>>>> ---
> > >>>>>>>>> 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);
> > >>>>>>>>> +
> > >>>>>>>
> > >>>>>>> [ please refrain from unnecessary whitespace changes ]
> > >>>>>>>
> > >>>>>>>>> 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 <l.majewski@samsung.com>
> > >>>>>>>>
> > >>>>>>>> BTW: I've added Guenter to CC.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Best regards,
> > >>>>>>>>
> > >>>>>>>> Lukasz Majewski
> > >>>>>>>>
> > >>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> > >>
> > >>
> > >
> >
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 13:58 ` Thierry Reding
0 siblings, 0 replies; 86+ messages in thread
From: Thierry Reding @ 2015-04-10 13:58 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
> On Fri, 2015-04-10 at 06:09 -0700, Guenter Roeck wrote:
> > On 04/10/2015 05:59 AM, Anand Moon wrote:
> > > Hi Sjoerd,
> > >
> > > I don't much advance knowledge on internal signaling of pwm-samsung module.
> > >
> > > So do I need to send this patch again ?
> > >
> >
> > From the context, it seems that the fix in hwmon would only paint
> > over a problem in the actual pwm driver, correct ?
>
> Yes/no/maybe :). Imho this is something to clarify in the pwm API
> documentation. As currently all it says is:
> "pwm_disable - stop a PWM output toggling",
>
> Which is what the exynos driver does.
>
> Thierry, could you clearify what the intention is here? I'm happy to
> prepare a pwm driver patch if needed to solve this?
I think the safest thing to do is for users to do both. You call
pwm_config() with a zero duty cycle to make it clear what the status is
that you want. Then you call pwm_disable() to state that you don't need
the output signal anymore, so that any clocks needed by the PWM can be
stopped. Doing so gives the driver the most information and should make
the user more resilient against any possible quirks in drivers.
Drivers that on pwm_disable() still invert the signal should still be
fixed, though. In the cases that I'm aware of the sequence of setting
the duty cycle to 0 and calling pwm_disable() won't actually paper over
any bugs. It's precisely that sequence that triggers the bug. Merely
calling pwm_disable() should trigger it as well, pwm_config(0) without
pwm_disable() would hide it.
Thierry
> > If you resubmit the patch I would expect you to explain this in the
> > commit log.
> >
> > Guenter
> >
> > > -Anand Moon
> > >
> > >
> > > On 10 April 2015 at 17:30, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> > >> Hey Anand,
> > >>
> > >> On Fri, 2015-04-10 at 16:58 +0530, Anand Moon wrote:
> > >>> Hi Guenter/Lukasz,
> > >>>
> > >>> Earlier I send v2 version of the patch spiking this one.
> > >>>
> > >>> Markus Riechl came back to me with below mail.
> > >>> So This patch confirms fixes the bug.
> > >>>
> > >>> I will send v3 version of the patch. Earlier I was in delima about the bug.
> > >>>
> > >>> -Anand Moon
> > >>> -------------------------------------------
> > >>> Hi Anand,
> > >>>
> > >>> I tested your patch.
> > >>>
> > >>> After booting the fan is spinning despite only 44?C.
> > >>>
> > >>> /sys/class/thermal/cooling_device0/curstate is 0.
> > >>> /sys/class/hwmon/hwmon4/pwm1 is 0
> > >>>
> > >>> when I echo 1 > cur_state and then echo 0 > cur_state again,
> > >>> the fan switches to off and behaves as expected.
> > >>>
> > >>> It looks like there is a bug in initializing the pwm output
> > >>> immediately after booting.
> > >>
> > >> The problem here will be that at boot the PWM runs at full duty. With
> > >> the current exynos PWM drive if you disable the PWM it will stop pulsing
> > >> but remain high if it was at 100% duty. My patch on which you depend
> > >> upon fixed a race where disabling the pwm right after changing the duty
> > >> cycle (e.g. to 0%) also kept the signal high.
> > >>
> > >> From looking at other PWM users at the time it seemed that most if not
> > >> all always first set to duty to 0% and then disable the pwm. Which
> > >> should work fine on exynos now. However iirc Thierry recently clarified
> > >> that the expected result of pwm_disable is not just that the modulation
> > >> stops but also that the output signal goes low, although that's not very
> > >> explicit in the current pwm documentation.. The exynos PWM driver will
> > >> need another fix tweak to make that true.
> > >>
> > >>
> > >>
> > >>> Best Regards,
> > >>
> > >>
> > >>
> > >>> --
> > >>> Markus Reichl
> > >>>
> > >>> On 8 April 2015 at 23:19, Anand Moon <linux.amoon@gmail.com> wrote:
> > >>>> Hi Guenter,
> > >>>>
> > >>>> Sorry my blunder mistake. Sorry for the noise.
> > >>>>
> > >>>> I just tested with spiking this patch and my observation and testing
> > >>>> were wrong we can skip this patch.
> > >>>>
> > >>>> I will send an v2 patch series removing the patch 5 and patch 6.
> > >>>>
> > >>>> With correct dts changes.
> > >>>>
> > >>>> Thanks for pointing my mistake.
> > >>>>
> > >>>> -Anand Moon
> > >>>>
> > >>>> On 8 April 2015 at 22:23, Guenter Roeck <linux@roeck-us.net> wrote:
> > >>>>> On Wed, Apr 08, 2015 at 09:32:05PM +0530, Anand Moon wrote:
> > >>>>>> Hi Guenter,
> > >>>>>>
> > >>>>>> Initially the board bootup the cooling level state is 0.
> > >>>>>> So update the duty cycle and this power off the fan.
> > >>>>>> As their is no state change the fan will not spin.
> > >>>>>>
> > >>>>>> Once the temperature sensor is reached to alert temperature it changes state.
> > >>>>>> With the state change the fan cools the CPU and then stop's
> > >>>>>>
> > >>>>>> I have observed this state change with tmon utility in linux/tools/thermal/tmon/
> > >>>>>>
> > >>>>> Sorry, I am missing something. I still don't see what problem you are fixing
> > >>>>> with this patch. What behavior is wrong with the current code, and how does your
> > >>>>> patch fix it ?
> > >>>>>
> > >>>>> Guenter
> > >>>>>
> > >>>>>> -Anand Moon
> > >>>>>>
> > >>>>>> On 8 April 2015 at 21:02, Guenter Roeck <linux@roeck-us.net> wrote:
> > >>>>>>> On Wed, Apr 08, 2015 at 10:44:15AM +0200, Lukasz Majewski wrote:
> > >>>>>>>> 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.
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>> Unfortunately, the patch does not include an explanation why it is needed.
> > >>>>>>>
> > >>>>>>> The original code presumably did not update the duty cycle because
> > >>>>>>> pwm was about to be disabled anyway. That kind of made sense to me.
> > >>>>>>> Updating the duty cycle to 0 just to disable the pwm channel right
> > >>>>>>> afterwards does not immediately make sense.
> > >>>>>>>
> > >>>>>>> Given that, I would expect to see a rationale here. Why is this patch needed ?
> > >>>>>>> Does it fix a bug ? If yes, pelase describe the bug. If not, what is the
> > >>>>>>> purpose of this patch ?
> > >>>>>>>
> > >>>>>>> Maybe that is all explained in patch 0/6, which I was not copied on. Even
> > >>>>>>> if so, the reationale will be needed in the changelog to explain to future
> > >>>>>>> developers why this change was made.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Guenter
> > >>>>>>>
> > >>>>>>>>> Tested on OdroidXU3 board.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > >>>>>>>>> ---
> > >>>>>>>>> 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);
> > >>>>>>>>> +
> > >>>>>>>
> > >>>>>>> [ please refrain from unnecessary whitespace changes ]
> > >>>>>>>
> > >>>>>>>>> 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 <l.majewski@samsung.com>
> > >>>>>>>>
> > >>>>>>>> BTW: I've added Guenter to CC.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Best regards,
> > >>>>>>>>
> > >>>>>>>> Lukasz Majewski
> > >>>>>>>>
> > >>>>>>>> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> > >>
> > >>
> > >
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150410/d3cba63e/attachment-0001.sig>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 13:58 ` Thierry Reding
(?)
@ 2015-04-10 17:25 ` Ben Gamari
-1 siblings, 0 replies; 86+ messages in thread
From: Ben Gamari @ 2015-04-10 17:25 UTC (permalink / raw)
To: Thierry Reding, Sjoerd Simons
Cc: Guenter Roeck, Anand Moon, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Thierry Reding <thierry.reding@gmail.com> writes:
> On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
>>
>> Yes/no/maybe :). Imho this is something to clarify in the pwm API
>> documentation. As currently all it says is:
>> "pwm_disable - stop a PWM output toggling",
>>
>> Which is what the exynos driver does.
>>
>> Thierry, could you clearify what the intention is here? I'm happy to
>> prepare a pwm driver patch if needed to solve this?
>
> I think the safest thing to do is for users to do both. You call
> pwm_config() with a zero duty cycle to make it clear what the status is
> that you want. Then you call pwm_disable() to state that you don't need
> the output signal anymore, so that any clocks needed by the PWM can be
> stopped. Doing so gives the driver the most information and should make
> the user more resilient against any possible quirks in drivers.
>
It would be great if the documentation were more clear on this matter
regardless. This is something I can imagine having to spend substantial
amounts of time Googling whereas a simple note in the documentation would
have removed all ambiguity.
Cheers,
- Ben
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 17:25 ` Ben Gamari
0 siblings, 0 replies; 86+ messages in thread
From: Ben Gamari @ 2015-04-10 17:25 UTC (permalink / raw)
To: Thierry Reding, Sjoerd Simons
Cc: Guenter Roeck, Anand Moon, Lukasz Majewski, Eduardo Valentin,
Russell King, Kukjin Kim, devicetree, linux-samsung-soc,
linux-pwm, linux-kernel, linux-arm-kernel, Markus Reichl
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Thierry Reding <thierry.reding@gmail.com> writes:
> On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
>>
>> Yes/no/maybe :). Imho this is something to clarify in the pwm API
>> documentation. As currently all it says is:
>> "pwm_disable - stop a PWM output toggling",
>>
>> Which is what the exynos driver does.
>>
>> Thierry, could you clearify what the intention is here? I'm happy to
>> prepare a pwm driver patch if needed to solve this?
>
> I think the safest thing to do is for users to do both. You call
> pwm_config() with a zero duty cycle to make it clear what the status is
> that you want. Then you call pwm_disable() to state that you don't need
> the output signal anymore, so that any clocks needed by the PWM can be
> stopped. Doing so gives the driver the most information and should make
> the user more resilient against any possible quirks in drivers.
>
It would be great if the documentation were more clear on this matter
regardless. This is something I can imagine having to spend substantial
amounts of time Googling whereas a simple note in the documentation would
have removed all ambiguity.
Cheers,
- Ben
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 17:25 ` Ben Gamari
0 siblings, 0 replies; 86+ messages in thread
From: Ben Gamari @ 2015-04-10 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Thierry Reding <thierry.reding@gmail.com> writes:
> On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
>>
>> Yes/no/maybe :). Imho this is something to clarify in the pwm API
>> documentation. As currently all it says is:
>> "pwm_disable - stop a PWM output toggling",
>>
>> Which is what the exynos driver does.
>>
>> Thierry, could you clearify what the intention is here? I'm happy to
>> prepare a pwm driver patch if needed to solve this?
>
> I think the safest thing to do is for users to do both. You call
> pwm_config() with a zero duty cycle to make it clear what the status is
> that you want. Then you call pwm_disable() to state that you don't need
> the output signal anymore, so that any clocks needed by the PWM can be
> stopped. Doing so gives the driver the most information and should make
> the user more resilient against any possible quirks in drivers.
>
It would be great if the documentation were more clear on this matter
regardless. This is something I can imagine having to spend substantial
amounts of time Googling whereas a simple note in the documentation would
have removed all ambiguity.
Cheers,
- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150410/698d67eb/attachment.sig>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
2015-04-10 17:25 ` Ben Gamari
(?)
@ 2015-04-10 17:58 ` Guenter Roeck
-1 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-10 17:58 UTC (permalink / raw)
To: Ben Gamari
Cc: Thierry Reding, Sjoerd Simons, Anand Moon, Lukasz Majewski,
Eduardo Valentin, Russell King, Kukjin Kim, devicetree,
linux-samsung-soc, linux-pwm, linux-kernel, linux-arm-kernel,
Markus Reichl
On Fri, Apr 10, 2015 at 01:25:52PM -0400, Ben Gamari wrote:
> Thierry Reding <thierry.reding@gmail.com> writes:
>
> > On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
> >>
> >> Yes/no/maybe :). Imho this is something to clarify in the pwm API
> >> documentation. As currently all it says is:
> >> "pwm_disable - stop a PWM output toggling",
> >>
> >> Which is what the exynos driver does.
> >>
> >> Thierry, could you clearify what the intention is here? I'm happy to
> >> prepare a pwm driver patch if needed to solve this?
> >
> > I think the safest thing to do is for users to do both. You call
> > pwm_config() with a zero duty cycle to make it clear what the status is
> > that you want. Then you call pwm_disable() to state that you don't need
> > the output signal anymore, so that any clocks needed by the PWM can be
> > stopped. Doing so gives the driver the most information and should make
> > the user more resilient against any possible quirks in drivers.
> >
> It would be great if the documentation were more clear on this matter
> regardless. This is something I can imagine having to spend substantial
> amounts of time Googling whereas a simple note in the documentation would
> have removed all ambiguity.
>
Especially since, in this case, the output signal _is_ still needed.
It appears that pwm_disable() is only expected to stop the clock, not
the signal itself.
Guenter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 17:58 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-10 17:58 UTC (permalink / raw)
To: Ben Gamari
Cc: Thierry Reding, Sjoerd Simons, Anand Moon, Lukasz Majewski,
Eduardo Valentin, Russell King, Kukjin Kim, devicetree,
linux-samsung-soc, linux-pwm, linux-kernel, linux-arm-kernel,
Markus Reichl
On Fri, Apr 10, 2015 at 01:25:52PM -0400, Ben Gamari wrote:
> Thierry Reding <thierry.reding@gmail.com> writes:
>
> > On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
> >>
> >> Yes/no/maybe :). Imho this is something to clarify in the pwm API
> >> documentation. As currently all it says is:
> >> "pwm_disable - stop a PWM output toggling",
> >>
> >> Which is what the exynos driver does.
> >>
> >> Thierry, could you clearify what the intention is here? I'm happy to
> >> prepare a pwm driver patch if needed to solve this?
> >
> > I think the safest thing to do is for users to do both. You call
> > pwm_config() with a zero duty cycle to make it clear what the status is
> > that you want. Then you call pwm_disable() to state that you don't need
> > the output signal anymore, so that any clocks needed by the PWM can be
> > stopped. Doing so gives the driver the most information and should make
> > the user more resilient against any possible quirks in drivers.
> >
> It would be great if the documentation were more clear on this matter
> regardless. This is something I can imagine having to spend substantial
> amounts of time Googling whereas a simple note in the documentation would
> have removed all ambiguity.
>
Especially since, in this case, the output signal _is_ still needed.
It appears that pwm_disable() is only expected to stop the clock, not
the signal itself.
Guenter
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan
@ 2015-04-10 17:58 ` Guenter Roeck
0 siblings, 0 replies; 86+ messages in thread
From: Guenter Roeck @ 2015-04-10 17:58 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 10, 2015 at 01:25:52PM -0400, Ben Gamari wrote:
> Thierry Reding <thierry.reding@gmail.com> writes:
>
> > On Fri, Apr 10, 2015 at 03:30:01PM +0200, Sjoerd Simons wrote:
> >>
> >> Yes/no/maybe :). Imho this is something to clarify in the pwm API
> >> documentation. As currently all it says is:
> >> "pwm_disable - stop a PWM output toggling",
> >>
> >> Which is what the exynos driver does.
> >>
> >> Thierry, could you clearify what the intention is here? I'm happy to
> >> prepare a pwm driver patch if needed to solve this?
> >
> > I think the safest thing to do is for users to do both. You call
> > pwm_config() with a zero duty cycle to make it clear what the status is
> > that you want. Then you call pwm_disable() to state that you don't need
> > the output signal anymore, so that any clocks needed by the PWM can be
> > stopped. Doing so gives the driver the most information and should make
> > the user more resilient against any possible quirks in drivers.
> >
> It would be great if the documentation were more clear on this matter
> regardless. This is something I can imagine having to spend substantial
> amounts of time Googling whereas a simple note in the documentation would
> have removed all ambiguity.
>
Especially since, in this case, the output signal _is_ still needed.
It appears that pwm_disable() is only expected to stop the clock, not
the signal itself.
Guenter
^ permalink raw reply [flat|nested] 86+ messages in thread
end of thread, other threads:[~2015-04-10 17:58 UTC | newest]
Thread overview: 86+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-26 16:39 Exynos5422 odroidxu3 pwm-fan control using thermal sensors Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-03-26 16:39 ` [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-04-08 7:46 ` Lukasz Majewski
2015-04-08 7:46 ` Lukasz Majewski
2015-03-26 16:39 ` [PATCH 2/6] ARM: dts exynos5420 update the cooling cells for core cpu0 Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-04-08 7:47 ` Lukasz Majewski
2015-04-08 7:47 ` Lukasz Majewski
2015-03-26 16:39 ` [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0 Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-04-08 8:02 ` Lukasz Majewski
2015-04-08 8:02 ` Lukasz Majewski
2015-04-08 8:02 ` Lukasz Majewski
2015-04-08 9:12 ` Anand Moon
2015-04-08 9:12 ` Anand Moon
2015-04-08 9:12 ` Anand Moon
2015-04-08 9:30 ` Lukasz Majewski
2015-04-08 9:30 ` Lukasz Majewski
2015-04-08 9:30 ` Lukasz Majewski
2015-04-08 9:44 ` Anand Moon
2015-04-08 9:44 ` Anand Moon
2015-04-08 9:44 ` Anand Moon
2015-03-26 16:39 ` [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-04-08 8:03 ` Lukasz Majewski
2015-04-08 8:03 ` Lukasz Majewski
2015-03-26 16:39 ` [PATCH 5/6] pwm: samsung: Fix output race on disabling Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-04-08 8:28 ` Lukasz Majewski
2015-04-08 8:28 ` Lukasz Majewski
2015-04-08 8:42 ` Sjoerd Simons
2015-04-08 8:42 ` Sjoerd Simons
2015-04-08 8:53 ` Anand Moon
2015-04-08 8:53 ` Anand Moon
2015-04-08 8:53 ` Anand Moon
2015-03-26 16:39 ` [PATCH 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan Anand Moon
2015-03-26 16:39 ` Anand Moon
2015-04-08 8:44 ` Lukasz Majewski
2015-04-08 8:44 ` Lukasz Majewski
2015-04-08 13:11 ` Guenter Roeck
2015-04-08 13:11 ` Guenter Roeck
2015-04-08 15:32 ` Guenter Roeck
2015-04-08 15:32 ` Guenter Roeck
2015-04-08 16:02 ` Anand Moon
2015-04-08 16:02 ` Anand Moon
2015-04-08 16:02 ` Anand Moon
2015-04-08 16:53 ` Guenter Roeck
2015-04-08 16:53 ` Guenter Roeck
2015-04-08 16:53 ` Guenter Roeck
2015-04-08 17:49 ` Anand Moon
2015-04-08 17:49 ` Anand Moon
2015-04-08 17:49 ` Anand Moon
2015-04-10 11:28 ` Anand Moon
2015-04-10 11:28 ` Anand Moon
2015-04-10 11:28 ` Anand Moon
2015-04-10 12:00 ` Sjoerd Simons
2015-04-10 12:00 ` Sjoerd Simons
2015-04-10 12:00 ` Sjoerd Simons
2015-04-10 12:59 ` Anand Moon
2015-04-10 12:59 ` Anand Moon
2015-04-10 12:59 ` Anand Moon
2015-04-10 13:09 ` Guenter Roeck
2015-04-10 13:09 ` Guenter Roeck
2015-04-10 13:09 ` Guenter Roeck
2015-04-10 13:17 ` Anand Moon
2015-04-10 13:17 ` Anand Moon
2015-04-10 13:17 ` Anand Moon
2015-04-10 13:30 ` Sjoerd Simons
2015-04-10 13:30 ` Sjoerd Simons
2015-04-10 13:30 ` Sjoerd Simons
2015-04-10 13:58 ` Thierry Reding
2015-04-10 13:58 ` Thierry Reding
2015-04-10 13:58 ` Thierry Reding
2015-04-10 17:25 ` Ben Gamari
2015-04-10 17:25 ` Ben Gamari
2015-04-10 17:25 ` Ben Gamari
2015-04-10 17:58 ` Guenter Roeck
2015-04-10 17:58 ` Guenter Roeck
2015-04-10 17:58 ` Guenter Roeck
2015-04-02 10:02 ` Exynos5422 odroidxu3 pwm-fan control using thermal sensors Markus Reichl
2015-04-02 10:02 ` Markus Reichl
2015-04-02 10:06 ` Markus Reichl
2015-04-02 10:06 ` Markus Reichl
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.