[RFC] cpufreq: Make sure target freq is within limits
Hi Rafael,
__cpufreq_driver_target() must not pass target frequency beyond the limits of
current policy.
Today most of cpufreq platform drivers are doing this check in their target
routines. Why not move it to __cpufreq_driver_target().
I wanted to get your opinion on this before making changes in all driver files.
That's why this is an RFC.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index f552d5f..59264f1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy
*policy,
unsigned int relation)
{
int retval = -EINVAL;
+ unsigned int old_target_freq = target_freq;
if (cpufreq_disabled())
return -ENODEV;
- pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
- target_freq, relation);
+ /* Make sure that target_freq is within supported range */
+ if (target_freq > policy->max)
+ target_freq = policy->max;
+ if (target_freq < policy->min)
+ target_freq = policy->min;
+
+ pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+ policy->cpu, target_freq, relation, old_target_freq);
if (cpu_online(policy->cpu) && cpufreq_driver->target)
retval = cpufreq_driver->target(policy, target_freq, relation);
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge
From: "Rajanikanth H.V"
- This patch adds device tree support for fuelgauge driver
- optimize bm devices platform_data usage and of_probe(...)
Note: of_probe() routine for battery managed devices is made
common across all bm drivers.
- test status:
- interrupt numbers assigned differs between legacy and FDT mode.
Signed-off-by: Rajanikanth H.V
---
Documentation/devicetree/bindings/mfd/ab8500.txt |7 +-
.../devicetree/bindings/power_supply/ab8500/fg.txt | 58 +++
arch/arm/boot/dts/dbx5x0.dtsi | 12 +-
drivers/mfd/ab8500-core.c |5 +
drivers/power/Makefile |2 +-
drivers/power/ab8500_bmdata.c | 513
drivers/power/ab8500_btemp.c | 16 +-
drivers/power/ab8500_charger.c | 16 +-
drivers/power/ab8500_fg.c | 80 +--
drivers/power/abx500_chargalg.c|8 +-
include/linux/mfd/abx500.h | 36 +-
11 files changed, 659 insertions(+), 94 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
create mode 100644 drivers/power/ab8500_bmdata.c
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt
b/Documentation/devicetree/bindings/mfd/ab8500.txt
index ce83c8d..6ca8d81 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -24,7 +24,12 @@ ab8500-bm: :
: Battery Manager
ab8500-btemp : : : Battery
Temperature
ab8500-charger : : : Battery
Charger
ab8500-codec : : : Audio Codec
-ab8500-fg: : : Fuel Gauge
+ab8500-fg: : vddadc : Fuel Gauge
+: NCONV_ACCU : : Accumulate N
Sample Conversion
+: BATT_OVV : : Battery Over
Voltage
+: LOW_BAT_F: : LOW threshold
battery voltage
+: CC_INT_CALIB : : Coulomb
Counter Internal Calibration
+: CCEOC: : Coulomb
Counter End of Conversion
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to
Digital Converter
SW_CONV_END : :
ab8500-gpio : : : GPIO
Controller
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
new file mode 100644
index 000..28eaf35
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
@@ -0,0 +1,58 @@
+=== AB8500 Fuel Gauge Driver ===
+
+AB8500 is a mixed signal multimedia and power management
+device comprising: power and energy-management-module,
+wall-charger, usb-charger, audio codec, general purpose adc,
+tvout, clock management and sim card interface.
+
+Fuelgauge support is part of energy-management-modules, other
+components of this module are:
+main-charger, usb-combo-charger and battery-temperature-monitoring.
+
+The properties below describes the node for fuelgauge driver.
+
+Required Properties:
+- compatible = This shall be: "stericsson,ab8500-fg"
+- battery = Shall be battery specific information
+ Example:
+ ab8500_fg {
+ compatible = "stericsson,ab8500-fg";
+ battery= <&ab8500_battery>;
+ };
+
+dependent node:
+ ab8500_battery: ab8500_battery {
+ };
+ This node will provide information on 'thermistor interface' and
+ 'battery technology type' used.
+
+Properties of this node are:
+thermistor-on-batctrl:
+ A boolean value indicating thermistor interface to battery
+
+ Note:
+ 'btemp' and 'batctrl' are the pins interfaced for battery temperature
+ measurement, 'btemp' signal is used when NTC(negative temperature
+ coefficient) resister is interfaced external to battery whereas
+ 'batctrl' pin is used when NTC resister is internal to battery.
+
+ Example:
+ ab8500_battery: ab8500_battery {
+ thermistor-on-batctrl;
+ };
+ indiactes: NTC resister is internal to battery, 'batctrl' is used
+ for thermal measurement.
+
+ The absence of property 'thermal-on-batctrl' indicates
+ NTC resister is external to battery and 'btemp' signal is used
+ for thermal measurement.
+
+battery-type:
+ This shall be the battery manufacturing technology type,
+ allowed types are:
+ "UNKNOWN" "NiMH" "LION" "LIPO" "LiFe" "NiCd" "LiMn"
+ Example:
+ a
[PATCH 0/4] Implement device tree support for ab8500 BM Devices
From: "Rajanikanth H.V" This patch-set adds device tree binding for ab8500 battery-managed devices. Removes the redundant platform structure maintained across bm devices and implements common DT probe routine across all the modules. Test status: a) Tested across 'legacy platform data' and DT binding support a.1) ab8500_charger driver fails to get regulator in the legacy platform mode. b) Interrupt numbers assigned differs between legacy and FDT mode. (a) Legacy platform_data Mode: root@ME:/ cat /proc/interrupts CPU0 CPU1 483: 0 0ab8500 ab8500-ponkey-dbf 484: 0 0ab8500 ab8500-ponkey-dbr 485: 0 0ab8500 BATT_OVV 494: 0 1ab8500 495: 0 0ab8500 ab8500-rtc 501: 0 13ab8500 NCONV_ACCU 503: 7 22ab8500 CCEOC 504: 0 1ab8500 CC_INT_CALIB 505: 0 0ab8500 LOW_BAT_F 516: 0 34ab8500 ab8500-gpadc 556: 0 0ab8500 usb-link-status (b) FDT Mode: root@ME:/ cat /proc/interrupts CPU0 CPU1 6: 0 0ab8500 ab8500-ponkey-dbf 7: 0 0ab8500 ab8500-ponkey-dbr 8: 0 0ab8500 BATT_OVV 162: 0 7ab8500 ab8500-gpadc 163: 0 1ab8500 164: 0 0ab8500 ab8500-rtc 484: 0 0ab8500 usb-link-status 499: 0 4ab8500 NCONV_ACCU 500: 0 0ab8500 LOW_BAT_F 502: 0 1ab8500 CC_INT_CALIB 503: 0 6ab8500 CCEOC c) Event handlers across bm-modules have been verified only during 'battery discharge process' as 'battery charging process' depends on ab8500-usb code Rajanikanth H.V (4): mfd: ab8500: add devicetree support for fuelgauge mfd: ab8500: add devicetree support for btemp mfd: ab8500: add devicetree support for charger mfd: ab8500: add devicetree support for chargalg Documentation/devicetree/bindings/mfd/ab8500.txt | 27 +- .../bindings/power_supply/ab8500/btemp.txt | 16 + .../bindings/power_supply/ab8500/chargalg.txt | 16 + .../bindings/power_supply/ab8500/charger.txt | 25 + .../devicetree/bindings/power_supply/ab8500/fg.txt | 58 +++ arch/arm/boot/dts/dbx5x0.dtsi | 28 +- drivers/mfd/ab8500-core.c | 20 + drivers/power/Kconfig |6 - drivers/power/Makefile |2 +- drivers/power/ab8500_bmdata.c | 513 drivers/power/ab8500_btemp.c | 76 +-- drivers/power/ab8500_charger.c | 82 ++-- drivers/power/ab8500_fg.c | 80 +-- drivers/power/abx500_chargalg.c| 56 ++- include/linux/mfd/abx500.h | 34 +- 15 files changed, 876 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/charger.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt create mode 100644 drivers/power/ab8500_bmdata.c -- 1.7.10.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/4] mfd: ab8500: add devicetree support for btemp
From: "Rajanikanth H.V"
This patch adds device tree support for
battery-temperature-monitor driver
Signed-off-by: Rajanikanth H.V
---
Documentation/devicetree/bindings/mfd/ab8500.txt |6 ++
.../bindings/power_supply/ab8500/btemp.txt | 16 +
arch/arm/boot/dts/dbx5x0.dtsi |5 ++
drivers/mfd/ab8500-core.c |5 ++
drivers/power/Kconfig |6 --
drivers/power/ab8500_bmdata.c |4 +-
drivers/power/ab8500_btemp.c | 66
7 files changed, 73 insertions(+), 35 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt
b/Documentation/devicetree/bindings/mfd/ab8500.txt
index 6ca8d81..179c802 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -30,6 +30,12 @@ ab8500-fg: : vddadc
: Fuel Gauge
: LOW_BAT_F: : LOW threshold
battery voltage
: CC_INT_CALIB : : Coulomb
Counter Internal Calibration
: CCEOC: : Coulomb
Counter End of Conversion
+ab8500-btemp: : vtvout : Battery
Temperature
+: BAT_CTRL_INDB: : Battery
Removal Indicator
+: BTEMP_LOW: : Btemp <
BtempLow, if battery temperature is lower than -10°C
+: BTEMP_HIGH : : BtempLow <
Btemp < BtempMedium,if battery temperature is between -10 and 0°C
+: BTEMP_LOW_MEDIUM : : BtempMedium <
Btemp < BtempHigh,if battery temperature is between 0°C and“MaxTemp
+: BTEMP_MEDIUM_HIGH: : Btemp >
BtempHigh, if battery temperature is higher than “MaxTemp”
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to
Digital Converter
SW_CONV_END : :
ab8500-gpio : : : GPIO
Controller
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
new file mode 100644
index 000..0ba1bcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
@@ -0,0 +1,16 @@
+=== AB8500 Battery Temperature Monitor Driver ===
+
+The properties below describes the node for btemp driver.
+
+Required Properties:
+- compatible = Shall be: "stericsson,ab8500-btemp"
+- battery = Shall be battery specific information
+
+ Example:
+ ab8500_btemp {
+ compatible = "stericsson,ab8500-btemp";
+ battery= <&ab8500_battery>;
+ };
+
+For information on battery specific node, Ref:
+Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 68317f5..79fdee4 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -362,6 +362,11 @@
battery= <&ab8500_battery>;
};
+ ab8500_btemp {
+ compatible = "stericsson,ab8500-btemp";
+ battery= <&ab8500_battery>;
+ };
+
ab8500_usb {
compatible = "stericsson,ab8500-usb";
interrupts = < 90 0x4
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 7c3017b..94d45be 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1046,8 +1046,13 @@ static struct mfd_cell __devinitdata ab8500_bm_devs[] = {
},
{
.name = "ab8500-btemp",
+ .of_compatible = "stericsson,ab8500-btemp",
.num_resources = ARRAY_SIZE(ab8500_btemp_resources),
.resources = ab8500_btemp_resources,
+#ifndef CONFIG_OF
+ .platform_data = &ab8500_bm_data,
+ .pdata_size = sizeof(ab8500_bm_data),
+#endif
},
{
.name = "ab8500-fg",
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index c1892f3..1434871 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -304,12 +304,6 @@ config AB8500_BM
help
Say Y to include support for AB8500 battery management.
-config AB8500_BATTERY_THERM_ON_BATCTRL
- bool "Thermistor connected on BATCTRL ADC"
- depends on AB8500_BM
- help
- Say Y to enable battery temperature measu
[PATCH 3/4] mfd: ab8500: add devicetree support for charger
From: "Rajanikanth H.V"
This patch adds device tree support for ab8500-charger
driver
Signed-off-by: Rajanikanth H.V
---
Documentation/devicetree/bindings/mfd/ab8500.txt | 14
.../bindings/power_supply/ab8500/charger.txt | 25 +++
arch/arm/boot/dts/dbx5x0.dtsi |6 ++
drivers/mfd/ab8500-core.c |5 ++
drivers/power/ab8500_charger.c | 72
5 files changed, 94 insertions(+), 28 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power_supply/ab8500/charger.txt
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt
b/Documentation/devicetree/bindings/mfd/ab8500.txt
index 179c802..045dd87 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -36,6 +36,20 @@ ab8500-btemp : : vtvout
: Battery Temperature
: BTEMP_HIGH : : BtempLow <
Btemp < BtempMedium,if battery temperature is between -10 and 0°C
: BTEMP_LOW_MEDIUM : : BtempMedium <
Btemp < BtempHigh,if battery temperature is between 0°C and“MaxTemp
: BTEMP_MEDIUM_HIGH: : Btemp >
BtempHigh, if battery temperature is higher than “MaxTemp”
+ab8500-charger : : vddadc : Charger
interface
+: MAIN_CH_UNPLUG_DET : : main charger
unplug detection management (not in 8505)
+: MAIN_CHARGE_PLUG_DET : : main charger
plug detection management (not in 8505)
+: MAIN_EXT_CH_NOT_OK : : main charger
not OK
+: MAIN_CH_TH_PROT_R: : Die temp is
above main charger
+: MAIN_CH_TH_PROT_F: : Die temp is
below main charger
+: VBUS_DET_F : : VBUS falling
detected
+: VBUS_DET_R : : VBUS rising
detected
+: USB_LINK_STATUS : : USB link
status has changed
+: USB_CH_TH_PROT_R : : Die temp is
above usb charger
+: USB_CH_TH_PROT_F : : Die temp is
below usb charger
+: USB_CHARGER_NOT_OKR : : allowed USB
charger not ok detection
+: VBUS_OVV : : Overvoltage on
Vbus ball detected (USB charge is stopped)
+: CH_WD_EXP: : Charger
watchdog detected
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to
Digital Converter
SW_CONV_END : :
ab8500-gpio : : : GPIO
Controller
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt
b/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt
new file mode 100644
index 000..6bdbb08
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt
@@ -0,0 +1,25 @@
+=== AB8500 Charger Driver ===
+
+Required Properties:
+- compatible = Shall be "stericsson,ab8500-charger"
+- battery = Shall be battery specific information
+ Example:
+ ab8500_charger {
+ compatible = "stericsson,ab8500-charger";
+ battery= <&ab8500_battery>;
+ };
+
+- vddadc-supply: Supply for USB and Main charger
+ Example:
+ ab8500-charger {
+ vddadc-supply = <&ab8500_ldo_tvout_reg>;
+ }
+- autopower_cfg:
+ Boolean value depicting the presence of 'automatic poweron after
powerloss'
+ Example:
+ ab8500-charger {
+ autopower_cfg;
+ };
+
+For information on battery specific node, Ref:
+Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 79fdee4..b1ecb5d 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -367,6 +367,12 @@
battery= <&ab8500_battery>;
};
+ ab8500_charger {
+ compatible =
"stericsson,ab8500-charger";
+ battery = <&ab8500_battery>;
+ vddadc-supply =
<&ab8500_ldo_tvout_reg>;
+ };
+
ab8500_usb {
compatible = "stericsson,ab8500-usb";
interrupts = < 90 0x4
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 94d45be..c7a12
[PATCH 4/4] mfd: ab8500: add devicetree support for chargalg
From: "Rajanikanth H.V"
This patch adds device tree support for charging algorithm
driver
Signed-off-by: Rajanikanth H.V
---
.../bindings/power_supply/ab8500/chargalg.txt | 16 ++
arch/arm/boot/dts/dbx5x0.dtsi |5 ++
drivers/mfd/ab8500-core.c |5 ++
drivers/power/abx500_chargalg.c| 54 ++--
include/linux/mfd/abx500.h |6 ---
5 files changed, 65 insertions(+), 21 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt
b/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt
new file mode 100644
index 000..ef53283
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt
@@ -0,0 +1,16 @@
+=== AB8500 Charging Algorithm Driver ===
+
+The properties below describes the node for chargalg driver.
+
+Required Properties:
+- compatible = Shall be: "stericsson,ab8500-chargalg"
+- battery = Shall be battery specific information
+
+Example:
+ab8500_chargalg {
+ compatible = "stericsson,ab8500-chargalg";
+ battery= <&ab8500_battery>;
+};
+
+For information on battery specific node, Ref:
+Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index b1ecb5d..a678afa 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -373,6 +373,11 @@
vddadc-supply =
<&ab8500_ldo_tvout_reg>;
};
+ ab8500_chargalg {
+ compatible =
"stericsson,ab8500-chargalg";
+ battery = <&ab8500_battery>;
+ };
+
ab8500_usb {
compatible = "stericsson,ab8500-usb";
interrupts = < 90 0x4
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index c7a120b..afe835b 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1071,8 +1071,13 @@ static struct mfd_cell __devinitdata ab8500_bm_devs[] = {
},
{
.name = "ab8500-chargalg",
+ .of_compatible = "stericsson,ab8500-chargalg",
.num_resources = ARRAY_SIZE(ab8500_chargalg_resources),
.resources = ab8500_chargalg_resources,
+#ifndef CONFIG_USE_OF
+ .platform_data = &ab8500_bm_data,
+ .pdata_size = sizeof(ab8500_bm_data),
+#endif
},
};
diff --git a/drivers/power/abx500_chargalg.c b/drivers/power/abx500_chargalg.c
index 88b5cc1..829fcfd 100644
--- a/drivers/power/abx500_chargalg.c
+++ b/drivers/power/abx500_chargalg.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -231,7 +233,6 @@ struct abx500_chargalg {
struct abx500_chargalg_charger_info chg_info;
struct abx500_chargalg_battery_data batt_data;
struct abx500_chargalg_suspension_status susp_status;
- struct abx500_bmdevs_plat_data *pdata;
struct abx500_bm_data *bat;
struct power_supply chargalg_psy;
struct ux500_charger *ac_chg;
@@ -1795,25 +1796,45 @@ static int __devexit abx500_chargalg_remove(struct
platform_device *pdev)
flush_scheduled_work();
power_supply_unregister(&di->chargalg_psy);
platform_set_drvdata(pdev, NULL);
- kfree(di);
return 0;
}
+static char *supply_interface[] = {
+ "ab8500_fg",
+};
+
static int __devinit abx500_chargalg_probe(struct platform_device *pdev)
{
- struct abx500_bmdevs_plat_data *plat_data;
+ struct device_node *np = pdev->dev.of_node;
+ struct abx500_chargalg *di;
int ret = 0;
- struct abx500_chargalg *di =
- kzalloc(sizeof(struct abx500_chargalg), GFP_KERNEL);
- if (!di)
+ di = devm_kzalloc(&pdev->dev, sizeof(*di), GFP_KERNEL);
+ if (!di) {
+ dev_err(&pdev->dev, "%s no mem for ab8500_chargalg\n",
__func__);
return -ENOMEM;
+ }
+ di->bat = pdev->mfd_cell->platform_data;
+ if (!di->bat) {
+ if (np) {
+ ret = bmdevs_of_probe(&pdev->dev, np, &di->bat);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to get battery information\n");
+ return ret;
+ }
+ } else {
+ dev_err(&pdev->dev, "missing dt node for
ab8500_chargalg\n");
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&pdev->dev, "falling bac
Re: [PATCH V2 6/6] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
[...]
>> /*
>> + * Thermal Sensor
>> + */
>> +
>> +static struct resource db8500_thsens_resources[] = {
>> + {
>> + .name = "IRQ_HOTMON_LOW",
>> + .start = IRQ_PRCMU_HOTMON_LOW,
>> + .end= IRQ_PRCMU_HOTMON_LOW,
>> + .flags = IORESOURCE_IRQ,
>> + },
>> + {
>
> I prefer }, {
I just follow the style of all the other definitions, let's keep a
uniform style.
>
>> + .name = "IRQ_HOTMON_HIGH",
>> + .start = IRQ_PRCMU_HOTMON_HIGH,
>> + .end= IRQ_PRCMU_HOTMON_HIGH,
>> + .flags = IORESOURCE_IRQ,
>> + },
>> +};
[...]
>>
>>
>> ___
>> linaro-dev mailing list
>> linaro-dev@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 6/6] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
On 24 October 2012 22:32, Joe Perches wrote:
> On Wed, 2012-10-24 at 19:58 +0800, hongbo.zhang wrote:
>> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
>> also adds the platform data to support the old fashion.
>
> Just a trivial note:
>
>> diff --git a/arch/arm/mach-ux500/board-mop500.c
>> b/arch/arm/mach-ux500/board-mop500.c
>
>> @@ -229,6 +230,67 @@ static struct ab8500_platform_data ab8500_platdata = {
>> };
>>
>> /*
>> + * Thermal Sensor
>> + */
>> +
>> +static struct resource db8500_thsens_resources[] = {
>
> should there be a const in any of these?
There will be warnings from gcc:
warning: initialization discards 'const' qualifier from pointer target
type [enabled by default]
>
>> +static struct db8500_thsens_platform_data db8500_thsens_data = {
> []
>> +static struct platform_device u8500_thsens_device = {
> []
>> +static struct platform_device u8500_cpufreq_cooling_device = {
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] cpufreq: Fix sparse warnings by updating cputime64_t to u64
On 25 October 2012 02:44, Rafael J. Wysocki wrote: > On Wednesday 24 of October 2012 13:15:58 Viresh Kumar wrote: >> There were few sparse warnings due to mismatch of type on function arguments. >> Two types were used u64 and cputime64_t. Both are actually u64, so use u64 >> only. >> >> Reported-by: Fengguang Wu >> Signed-off-by: Viresh Kumar > > This series appears to be based on your "cpufreq: governors: remove > redundant code" patch that hasn't been applied yet. > > Please rebase it on top of linux-pm/linux-next or on top of v3.7-rc2, > whichever is more convenient, and resend. Please apply it after applying the latest cpufreq: governors patch i have sent. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] cpufreq: return early from __cpufreq_driver_getavg()
On Saturday 20 of October 2012 10:12:07 Viresh Kumar wrote: > On Oct 20, 2012 3:37 AM, "Rafael J. Wysocki" wrote: > > > > On Saturday 20 of October 2012 01:42:05 Viresh Kumar wrote: > > > There is no need to do cpufreq_get_cpu() and cpufreq_put_cpu() for > drivers that > > > don't support getavg() routine. > > > > > > Signed-off-by: Viresh Kumar > > > > The patch doesn't seem to follow the changelog or the other way around. > > Sorry if my log isn't clear enough. > But i could still see it matching the code :) > > I have moved the check for drivers capabilities at the top > of routine, so that there is no need to call mentioned routines. OK Applied to linux-pm.git/linux-next as v3.8 material. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] cpufreq: Improve debug prints
On Wednesday 17 of October 2012 12:03:31 Viresh Kumar wrote: > On 17 October 2012 11:56, Joe Perches wrote: > > Oh good, but please use a space between KBUILD_MODNAME > > and the quoted ": ". > > Anything technical behind it or just for code formatting? As output is > same in both cases :) > > 8<--8<--- > > From: Viresh Kumar > Date: Wed, 17 Oct 2012 10:38:31 +0530 > Subject: [PATCH] cpufreq: Improve debug prints > > With debug options on, it is difficult to locate cpufreq core's debug prints. > Fix this by prefixing debug prints with KBUILD_MODNAME. > > Signed-off-by: Viresh Kumar Applied to linux-pm.git/linux-next as v3.8 material. Thanks, Rafael > --- > drivers/cpufreq/cpufreq.c | 2 ++ > drivers/cpufreq/cpufreq_performance.c | 2 ++ > drivers/cpufreq/cpufreq_powersave.c | 2 ++ > drivers/cpufreq/cpufreq_userspace.c | 2 ++ > drivers/cpufreq/freq_table.c | 2 ++ > 5 files changed, 10 insertions(+) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index db6e337..85df538 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -15,6 +15,8 @@ > * > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > #include > #include > diff --git a/drivers/cpufreq/cpufreq_performance.c > b/drivers/cpufreq/cpufreq_performance.c > index f13a8a9..ceee068 100644 > --- a/drivers/cpufreq/cpufreq_performance.c > +++ b/drivers/cpufreq/cpufreq_performance.c > @@ -10,6 +10,8 @@ > * > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > #include > #include > diff --git a/drivers/cpufreq/cpufreq_powersave.c > b/drivers/cpufreq/cpufreq_powersave.c > index 4c2eb51..2d948a1 100644 > --- a/drivers/cpufreq/cpufreq_powersave.c > +++ b/drivers/cpufreq/cpufreq_powersave.c > @@ -10,6 +10,8 @@ > * > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > #include > #include > diff --git a/drivers/cpufreq/cpufreq_userspace.c > b/drivers/cpufreq/cpufreq_userspace.c > index bedac1a..c8c3d29 100644 > --- a/drivers/cpufreq/cpufreq_userspace.c > +++ b/drivers/cpufreq/cpufreq_userspace.c > @@ -11,6 +11,8 @@ > * > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > #include > #include > diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c > index 90431cb..49cda25 100644 > --- a/drivers/cpufreq/freq_table.c > +++ b/drivers/cpufreq/freq_table.c > @@ -9,6 +9,8 @@ > * > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > #include > #include > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Energy/power monitoring within the kernel
On Wed, Oct 24, 2012 at 05:37:27PM +0100, Pawel Moll wrote: > On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote: > > > Traditionally such data should be exposed to the user via hwmon sysfs > > > interface, and that's exactly what I did for "my" platform - I have > > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > > > enough to draw pretty graphs in userspace. Everyone was happy... > > > > > Only driver supporting "energy" output so far is ibmaem, and the reported > > energy > > is supposed to be cumulative, as in energy = power * time. Do you mean > > power, > > possibly ? > > So the vexpress would be the second one, than :-) as the energy > "monitor" actually on the latest tiles reports 64-bit value of > microJoules consumed (or produced) since the power-up. > > Some of the older boards were able to report instant power, but this > metrics is less useful in our case. > > > > Now I am getting new requests to do more with this data. In particular > > > I'm asked how to add such information to ftrace/perf output. The second > > > most frequent request is about providing it to a "energy aware" > > > cpufreq governor. > > > > Anything energy related would have to be along the line of "do something > > after a > > certain amount of work has been performed", which at least at the surface > > does > > not make much sense to me, unless you mean something along the line of a > > process scheduler which schedules a process not based on time slices but > > based > > on energy consumed, ie if you want to define a time slice not in > > milli-seconds > > but in Joule. > > Actually there is some research being done in this direction, but it's > way too early to draw any conclusions... > > > If so, I would argue that a similar behavior could be achieved by varying > > the > > duration of time slices with the current CPU speed, or simply by using cycle > > count instead of time as time slice parameter. Not that I am sure if such an > > approach would really be of interest for anyone. > > > > Or do you really mean power, not energy, such as in "reduce CPU speed if its > > power consumption is above X Watt" ? > > Uh. To be completely honest I must answer: I'm not sure how the "energy > aware" cpufreq governor is supposed to work. I have been simply asked to > provide the data in some standard way, if possible. > > > I am not sure how this would be expected to work. hwmon is, by its very > > nature, > > a passive subsystem: It doesn't do anything unless data is explicitly > > requested > > from it. It does not update an attribute unless that attribute is read. > > That does not seem to fit well with the idea of tracing - which assumes > > that some activity is happening, ultimately, all by itself, presumably > > periodically. The idea to have a user space application read hwmon data only > > for it to trigger trace events does not seem to be very compelling to me. > > What I had in mind was similar to what adt7470 driver does. The driver > would automatically access the device every now and then to update it's > internal state and generate the trace event on the way. This > auto-refresh "feature" is particularly appealing for me, as on some of > "my" platforms can take up to 500 microseconds to actually get the data. > So doing this in background (and providing users with the last known > value in the meantime) seems attractive. > A bad example doesn't mean it should be used elsewhere. adt7470 needs up to two seconds for a temperature measurement cycle, and it can not perform automatic cycles all by itself. In this context, executing temperature measurement cycles in the background makes a lot of sense, especially since one does not want to wait for two seconds when reading a sysfs attribute. But that only means that the chip is most likely not a good choice when selecting a temperature sensor, not that the code necessary to get it working should be used as an example for other drivers. Guenter > > An exception is if a monitoring device suppports interrupts, and if its > > driver > > actually implements those interrupts. This is, however, not the case for > > most of > > the current drivers (if any), mostly because interrupt support for hardware > > monitoring devices is very platform dependent and thus difficult to > > implement. > > Interestingly enough the newest version of our platform control micro > (doing the energy monitoring as well) can generate and interrupt when a > transaction is finished, so I was planning to periodically update the > all sort of values. And again, generating a trace event on this > opportunity would be trivial. > > > > Of course a particular driver could register its own perf PMU on its > > > own. It's certainly an option, just very suboptimal in my opinion. > > > Or maybe not? Maybe the task is so specialized that it makes sense? > > > > > We had a couple of attempts to provide an in-kernel API. Unfortunately, > > the result was, at
Re: [PATCH 1/2] cpufreq: Fix sparse warnings by updating cputime64_t to u64
On Wednesday 24 of October 2012 13:15:58 Viresh Kumar wrote:
> There were few sparse warnings due to mismatch of type on function arguments.
> Two types were used u64 and cputime64_t. Both are actually u64, so use u64
> only.
>
> Reported-by: Fengguang Wu
> Signed-off-by: Viresh Kumar
This series appears to be based on your "cpufreq: governors: remove
redundant code" patch that hasn't been applied yet.
Please rebase it on top of linux-pm/linux-next or on top of v3.7-rc2,
whichever is more convenient, and resend.
Thanks,
Rafael
> ---
>
> This solution was discussed here:
>
> http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg13744.html
>
> drivers/cpufreq/cpufreq_governor.c | 4 ++--
> drivers/cpufreq/cpufreq_governor.h | 11 +--
> drivers/cpufreq/cpufreq_stats.c| 4 ++--
> 3 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index cd5fe57..e39bf81 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -49,7 +49,7 @@ static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu,
> u64 *wall)
> return jiffies_to_usecs(idle_time);
> }
>
> -cputime64_t get_cpu_idle_time(unsigned int cpu, cputime64_t *wall)
> +u64 get_cpu_idle_time(unsigned int cpu, u64 *wall)
> {
> u64 idle_time = get_cpu_idle_time_us(cpu, NULL);
>
> @@ -81,7 +81,7 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
> /* Get Absolute Load (in terms of freq for ondemand gov) */
> for_each_cpu(j, policy->cpus) {
> struct cpu_dbs_common_info *j_cdbs;
> - cputime64_t cur_wall_time, cur_idle_time, cur_iowait_time;
> + u64 cur_wall_time, cur_idle_time, cur_iowait_time;
> unsigned int idle_time, wall_time, iowait_time;
> unsigned int load;
>
> diff --git a/drivers/cpufreq/cpufreq_governor.h
> b/drivers/cpufreq/cpufreq_governor.h
> index 34e14ad..f661654 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -17,7 +17,6 @@
> #ifndef _CPUFREQ_GOVERNER_H
> #define _CPUFREQ_GOVERNER_H
>
> -#include
> #include
> #include
> #include
> @@ -72,9 +71,9 @@ static void *get_cpu_dbs_info_s(int cpu)
> \
> /* Per cpu structures */
> struct cpu_dbs_common_info {
> int cpu;
> - cputime64_t prev_cpu_idle;
> - cputime64_t prev_cpu_wall;
> - cputime64_t prev_cpu_nice;
> + u64 prev_cpu_idle;
> + u64 prev_cpu_wall;
> + u64 prev_cpu_nice;
> struct cpufreq_policy *cur_policy;
> struct delayed_work work;
> /*
> @@ -87,7 +86,7 @@ struct cpu_dbs_common_info {
>
> struct od_cpu_dbs_info_s {
> struct cpu_dbs_common_info cdbs;
> - cputime64_t prev_cpu_iowait;
> + u64 prev_cpu_iowait;
> struct cpufreq_frequency_table *freq_table;
> unsigned int freq_lo;
> unsigned int freq_lo_jiffies;
> @@ -170,7 +169,7 @@ static inline int delay_for_sampling_rate(unsigned int
> sampling_rate)
> return delay;
> }
>
> -cputime64_t get_cpu_idle_time(unsigned int cpu, cputime64_t *wall);
> +u64 get_cpu_idle_time(unsigned int cpu, u64 *wall);
> void dbs_check_cpu(struct dbs_data *dbs_data, int cpu);
> int cpufreq_governor_dbs(struct dbs_data *dbs_data,
> struct cpufreq_policy *policy, unsigned int event);
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index b40ee14..683a48f 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -37,7 +37,7 @@ struct cpufreq_stats {
> unsigned int max_state;
> unsigned int state_num;
> unsigned int last_index;
> - cputime64_t *time_in_state;
> + u64 *time_in_state;
> unsigned int *freq_table;
> #ifdef CONFIG_CPU_FREQ_STAT_DETAILS
> unsigned int *trans_table;
> @@ -223,7 +223,7 @@ static int cpufreq_stats_create_table(struct
> cpufreq_policy *policy,
> count++;
> }
>
> - alloc_size = count * sizeof(int) + count * sizeof(cputime64_t);
> + alloc_size = count * sizeof(int) + count * sizeof(u64);
>
> #ifdef CONFIG_CPU_FREQ_STAT_DETAILS
> alloc_size += count * count * sizeof(int);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] cpufreq: governors: remove redundant code
On Wednesday 24 of October 2012 21:43:46 Rafael J. Wysocki wrote: > On Wednesday 24 of October 2012 11:37:13 Viresh Kumar wrote: > > On 22 October 2012 14:16, Viresh Kumar wrote: > > > On 20 October 2012 01:42, Viresh Kumar wrote: > > >> Initially ondemand governor was written and then using its code > > >> conservative > > >> governor is written. It used a lot of code from ondemand governor, but > > >> copy of > > >> code was created instead of using the same routines from both governors. > > >> Which > > >> increased code redundancy, which is difficult to manage. > > >> > > >> This patch is an attempt to move common part of both the governors to > > >> cpufreq_governor.c file to come over above mentioned issues. > > >> > > >> This shouldn't change anything from functionality point of view. > > >> > > >> Signed-off-by: Viresh Kumar > > > > For everybody else, this patch is already pushed by Rafael in his linux-next > > branch. > > Well, not yet, although I'm going to do that. Or I would if it still applied. Unfortunately, though, it doesn't apply any more to my linux-next branch due to some previous changes in it. Care to rebase? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] cpufreq: governors: remove redundant code
On Wednesday 24 of October 2012 11:37:13 Viresh Kumar wrote: > On 22 October 2012 14:16, Viresh Kumar wrote: > > On 20 October 2012 01:42, Viresh Kumar wrote: > >> Initially ondemand governor was written and then using its code > >> conservative > >> governor is written. It used a lot of code from ondemand governor, but > >> copy of > >> code was created instead of using the same routines from both governors. > >> Which > >> increased code redundancy, which is difficult to manage. > >> > >> This patch is an attempt to move common part of both the governors to > >> cpufreq_governor.c file to come over above mentioned issues. > >> > >> This shouldn't change anything from functionality point of view. > >> > >> Signed-off-by: Viresh Kumar > > For everybody else, this patch is already pushed by Rafael in his linux-next > branch. Well, not yet, although I'm going to do that. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Energy/power monitoring within the kernel
On Wed, 2012-10-24 at 01:40 +0100, Thomas Renninger wrote: > > More and more of people are getting interested in the subject of power > > (energy) consumption monitoring. We have some external tools like > > "battery simulators", energy probes etc., but some targets can measure > > their power usage on their own. > > > > Traditionally such data should be exposed to the user via hwmon sysfs > > interface, and that's exactly what I did for "my" platform - I have > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > > enough to draw pretty graphs in userspace. Everyone was happy... > > > > Now I am getting new requests to do more with this data. In particular > > I'm asked how to add such information to ftrace/perf output. > Why? What is the gain? > > Perf events can be triggered at any point in the kernel. > A cpufreq event is triggered when the frequency gets changed. > CPU idle events are triggered when the kernel requests to enter an idle state > or exits one. > > When would you trigger a thermal or a power event? > There is the possibility of (critical) thermal limits. > But if I understand this correctly you want this for debugging and > I guess you have everything interesting one can do with temperature > values: > - read the temperature > - draw some nice graphs from the results > > Hm, I guess I know what you want to do: > In your temperature/energy graph, you want to have some dots > when relevant HW states (frequency, sleep states, DDR power,...) > changed. Then you are able to see the effects over a timeline. > > So you have to bring the existing frequency/idle perf events together > with temperature readings > > Cleanest solution could be to enhance the exisiting userspace apps > (pytimechart/perf timechart) and let them add another line > (temperature/energy), but the data would not come from perf, but > from sysfs/hwmon. > Not sure whether this works out with the timechart tools. > Anyway, this sounds like a userspace only problem. Ok, so it is actually what I'm working on right now. Not with the standard perf tool (there are other users of that API ;-) but indeed I'm trying to "enrich" the data stream coming from kernel with user-space originating values. I am a little bit concerned about effect of extra syscalls (accessing the value and gettimeofday to generate a timestamp) at a higher sampling rates, but most likely it won't be a problem. Can report once I know more, if this is of interest to anyone. Anyway, there are at least two debug/trace related use cases that can not be satisfied that way (of course one could argue about their usefulness): 1. ftrace-over-network (https://lwn.net/Articles/410200/) which is particularly appealing for "embedded users", where there's virtually no useful userspace available (think Android). Here a (functional) trace event is embedded into a normal trace and available "for free" at the host side. 2. perf groups - the general idea is that one event (let it be cycle counter interrupt or even a timer) triggers read of other values (eg. cache counter or - in this case - energy counter). The aim is to have a regular "snapshots" of the system state. I'm not sure if the standard perf tool can do this, but I do :-) And last, but not least, there are the non-debug/trace clients for energy data as discussed in other mails in this thread. Of course the trace event won't really satisfy their needs either. Thanks for your feedback! Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Energy/power monitoring within the kernel
On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote: > > Traditionally such data should be exposed to the user via hwmon sysfs > > interface, and that's exactly what I did for "my" platform - I have > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > > enough to draw pretty graphs in userspace. Everyone was happy... > > > Only driver supporting "energy" output so far is ibmaem, and the reported > energy > is supposed to be cumulative, as in energy = power * time. Do you mean power, > possibly ? So the vexpress would be the second one, than :-) as the energy "monitor" actually on the latest tiles reports 64-bit value of microJoules consumed (or produced) since the power-up. Some of the older boards were able to report instant power, but this metrics is less useful in our case. > > Now I am getting new requests to do more with this data. In particular > > I'm asked how to add such information to ftrace/perf output. The second > > most frequent request is about providing it to a "energy aware" > > cpufreq governor. > > Anything energy related would have to be along the line of "do something > after a > certain amount of work has been performed", which at least at the surface does > not make much sense to me, unless you mean something along the line of a > process scheduler which schedules a process not based on time slices but based > on energy consumed, ie if you want to define a time slice not in milli-seconds > but in Joule. Actually there is some research being done in this direction, but it's way too early to draw any conclusions... > If so, I would argue that a similar behavior could be achieved by varying the > duration of time slices with the current CPU speed, or simply by using cycle > count instead of time as time slice parameter. Not that I am sure if such an > approach would really be of interest for anyone. > > Or do you really mean power, not energy, such as in "reduce CPU speed if its > power consumption is above X Watt" ? Uh. To be completely honest I must answer: I'm not sure how the "energy aware" cpufreq governor is supposed to work. I have been simply asked to provide the data in some standard way, if possible. > I am not sure how this would be expected to work. hwmon is, by its very > nature, > a passive subsystem: It doesn't do anything unless data is explicitly > requested > from it. It does not update an attribute unless that attribute is read. > That does not seem to fit well with the idea of tracing - which assumes > that some activity is happening, ultimately, all by itself, presumably > periodically. The idea to have a user space application read hwmon data only > for it to trigger trace events does not seem to be very compelling to me. What I had in mind was similar to what adt7470 driver does. The driver would automatically access the device every now and then to update it's internal state and generate the trace event on the way. This auto-refresh "feature" is particularly appealing for me, as on some of "my" platforms can take up to 500 microseconds to actually get the data. So doing this in background (and providing users with the last known value in the meantime) seems attractive. > An exception is if a monitoring device suppports interrupts, and if its driver > actually implements those interrupts. This is, however, not the case for most > of > the current drivers (if any), mostly because interrupt support for hardware > monitoring devices is very platform dependent and thus difficult to implement. Interestingly enough the newest version of our platform control micro (doing the energy monitoring as well) can generate and interrupt when a transaction is finished, so I was planning to periodically update the all sort of values. And again, generating a trace event on this opportunity would be trivial. > > Of course a particular driver could register its own perf PMU on its > > own. It's certainly an option, just very suboptimal in my opinion. > > Or maybe not? Maybe the task is so specialized that it makes sense? > > > We had a couple of attempts to provide an in-kernel API. Unfortunately, > the result was, at least so far, more complexity on the driver side. > So the difficulty is really to define an API which is really simple, and does > not just complicate driver development for a (presumably) rare use case. Yes, I appreciate this. That's why this option is actually my least favourite. Anyway, what I was thinking about was just a thin shin that *can* be used by a driver to register some particular value with the core (so it can be enumerated and accessed by in-kernel clients) and the core could (or not) create a sysfs attribute for this value on behalf of the driver. Seems lightweight enough, unless previous experience suggests otherwise? Cheers! Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Pawel Moll wrote: > On Tue, 2012-10-23 at 22:56 -0400, Nicolas Pitre wrote: > > The script to generate a boot script to generate an ATAGS block is a > > rather nice hack. > > These days are, fortunately, long gone :-) I deduced as much, given your example boot log reported a RTC time in 2004. Still, that was a nice piece of art IMHO. > New-ish Boot Monitors (5.x.x versions in particular) speak initrd, > ATAG _and_ DTB "natively", so one can boot the board with > > > fl linux initrd busybox > > fl linux fdt ca9 > > fl linux boot zimage console=ttyAMA0,38400 > > It still can't do TFTP though, so it's just a formal remark - I'm not > trying to "convert" anyone. I think it is not wrong to have second stage bootloaders. No need to duplicate functionality if an existing piece of software does it well already. Eventually this is down to personal work habits and preferences. Having the choice is good. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Energy/power monitoring within the kernel
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote: > A thought on that... from an SoC perspective there are other interesting > power rails than go to just the CPU core. For example DDR power and > rails involved with other IP units on the SoC such as 3D graphics unit. > So tying one number to specifically a CPU core does not sound like > it's enough. I do realize this. I just didn't want to try to cover too much ground, and cpufreq governor would be interested in cpu-related data anyway... > If you turn the problem upside down to solve the representation question > first, maybe there's a way forward defining the "power tree" in terms of > regulators, and then adding something in struct regulator that spams > readers with timestamped results if the regulator has a power monitoring > capability. > > Then you can map the regulators in the power tree to real devices by the > names or the supply stuff. Just a thought. Hm. Interesting idea indeed - if a regulator device was able to report the energy being produced by it (instead of looking at cumulative energy consumed by more than one device), defining "power domains" (by adding selected cpus as consumers) would be straight forward and the cpufreq could request the information that way. I'll look into it, thanks! Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Ryan Harkin wrote: > On 24 October 2012 09:29, Jon Medhurst (Tixy) wrote: > > > Personally (and unofficially), I find that the simplest and most > > reliable way to use vexpress is to flash the kernel/dtb/initrd images > > into NOR flash and use the bootmonitor supplied with the board to load > > these. > > No you don't. The party line is: we all use UEFI. > ;-) If it does TFTP and can be scripted then I don't mind. Otherwise, if I'm going to still use U-Boot in the end then UEFI will be just an extra roundtrip into another to-be-despised bootloader in lack of visibility and attention since it'll do nothing but increase my kernel boot latency. Did I mention already that I hate bootloaders? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Energy/power monitoring within the kernel
On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote: > > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361 > > > > One issue with this is that some external knowledge is required to > > relate a number to a processor core. Or maybe it's not an issue at all > > because it should be left for the user(space)? > > If the external knowledge can be characterized in a userspace tool with > the given data here, I see no issues with this. Ok, fine. > > TP_fast_assign( > > memcpy(__entry->cpus, cpus, sizeof(struct cpumask)); > > Copying the entire cpumask seems like overkill. Especially when you have > 4096 CPU machines. Uh, right. I didn't consider such use case... > Perhaps making a field that can be a subset of cpus may be better. That > way we don't waste the ring buffer with lots of zeros. I'm guessing that > it will only be a group of cpus, and not a scattered list? Of course, > I've seen boxes where the cpu numbers went from core to core. That is, > cpu 0 was on core 1, cpu 1 was on core 2, and then it would repeat. > cpu 8 was on core 1, cpu 9 was on core 2, etc. > > But still, this could be compressed somehow. Sure thing. Or I could simply use cpumask_scnprintf() on the assign stage and keep an already-formatted string. Or, as the cpumask per sensor would be de-facto constant, I could assume keep only a pointer to it. Will keep it in mind if this event was supposed to happen. Thanks! Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Tue, 2012-10-23 at 22:56 -0400, Nicolas Pitre wrote: > The script to generate a boot script to generate an ATAGS block is a > rather nice hack. These days are, fortunately, long gone :-) New-ish Boot Monitors (5.x.x versions in particular) speak initrd, ATAG _and_ DTB "natively", so one can boot the board with > fl linux initrd busybox > fl linux fdt ca9 > fl linux boot zimage console=ttyAMA0,38400 It still can't do TFTP though, so it's just a formal remark - I'm not trying to "convert" anyone. Cheers! Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Jon Medhurst (Tixy) wrote: > The official release pages will include _some_ similar (and more up to > date information), however you won't find any mention of any bootloader > other than UEFI. Another bootloader to hate. Joy! > And, at least for now, no mention of how to boot a > kernel other than by removing the SD card and copying it over. Maybe good for production, but abominable for development. I'm not buying. > Personally (and unofficially), I find that the simplest and most > reliable way to use vexpress is to flash the kernel/dtb/initrd images > into NOR flash and use the bootmonitor supplied with the board to load > these. Yes, did that before. The reflashing is still relatively long, enough to annoy me. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Viresh Kumar wrote: > Nice article! Thanks. > On 24 October 2012 08:26, Nicolas Pitre wrote: > > > > When working on low level kernel code, the indication that something > > went wrong is often noticed as a kernel oops, or even a totally silent > > system. This usually implies a modify-recompile-reboot cycle which can > > become very very annoying if the reboot step implies popping out an SD > > card from the board, inserting it into the work PC, mounting it, copying > > the newly compiled kernel over, unmounting, moving the SD card back to > > the board, to finally hit the reset button. > > You can also connect vexpress board with your PC with a USB cable, and > the uSD card will be shown on your PC as data storage, as soon as > bootloader or bootmonitor is on. You can simply copy files from your > linux pc to this storage and reboot :) I know. But that implies mounting and unmounting the device (unless you have an auto-mounter set up which I haven't). Also, this makes the boot very long when large files have to be reflashed, especially ramdisk images. And this is not very flexible when requiring runtime changes to the DTB. And for me, the deal breaker is the fact that all the other boards on my desk don't have such fancy USB storage connection and they are set up for booting over the network already. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH RESEND] xen/arm: use the __HVC macro
Use the new __HVC macro in hypercall.S.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/hypercall.S | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 074f5ed..71f7239 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -48,20 +48,16 @@
#include
#include
+#include
#include
-/* HVC 0xEA1 */
-#ifdef CONFIG_THUMB2_KERNEL
-#define xen_hvc .word 0xf7e08ea1
-#else
-#define xen_hvc .word 0xe140ea71
-#endif
+#define XEN_IMM 0xEA1
#define HYPERCALL_SIMPLE(hypercall)\
ENTRY(HYPERVISOR_##hypercall) \
mov r12, #__HYPERVISOR_##hypercall; \
- xen_hvc;\
+ __HVC(XEN_IMM); \
mov pc, lr; \
ENDPROC(HYPERVISOR_##hypercall)
@@ -76,7 +72,7 @@ ENTRY(HYPERVISOR_##hypercall) \
stmdb sp!, {r4} \
ldr r4, [sp, #4]\
mov r12, #__HYPERVISOR_##hypercall; \
- xen_hvc \
+ __HVC(XEN_IMM); \
ldm sp!, {r4} \
mov pc, lr \
ENDPROC(HYPERVISOR_##hypercall)
@@ -100,7 +96,7 @@ ENTRY(privcmd_call)
mov r2, r3
ldr r3, [sp, #8]
ldr r4, [sp, #4]
- xen_hvc
+ __HVC(XEN_IMM)
ldm sp!, {r4}
mov pc, lr
ENDPROC(privcmd_call);
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 6/6] ARM: sched: clear SD_SHARE_POWERLINE
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can't be powergated
independently.
Signed-off-by: Vincent Guittot
---
arch/arm/kernel/topology.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 26c12c6..00511d0 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -226,6 +226,11 @@ static inline void update_cpu_power(unsigned int cpuid,
unsigned int mpidr) {}
*/
struct cputopo_arm cpu_topology[NR_CPUS];
+int arch_sd_share_power_line(void)
+{
+ return 0*SD_SHARE_POWERLINE;
+}
Making this selection of policy based on sched domain will better. Just
gives the flexibility to choose a separate scheme for big and little
systems which will be very convenient.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 5/6] sched: pack the idle load balance
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
Look for an idle CPU close the pack buddy CPU whenever possible.
s/close/close to
The goal is to prevent the wake up of a CPU which doesn't share the power
line of the pack CPU
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6df53b5..f76acdc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5158,7 +5158,25 @@ static struct {
static inline int find_new_ilb(int call_cpu)
{
+ struct sched_domain *sd;
int ilb = cpumask_first(nohz.idle_cpus_mask);
+ int buddy = per_cpu(sd_pack_buddy, call_cpu);
+
+ /*
+* If we have a pack buddy CPU, we try to run load balance on a CPU
+* that is close to the buddy.
+*/
+ if (buddy != -1)
+ for_each_domain(buddy, sd) {
+ if (sd->flags & SD_SHARE_CPUPOWER)
+ continue;
Do you mean SD_SHARE_POWERLINE here ?
+
+ ilb = cpumask_first_and(sched_domain_span(sd),
+ nohz.idle_cpus_mask);
+
+ if (ilb < nr_cpu_ids)
+ break;
+ }
if (ilb < nr_cpu_ids && idle_cpu(ilb))
return ilb;
Can you please expand "idle CPU _close_ the pack buddy CPU" ?
Regards
santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 4/6] sched: secure access to other CPU statistics
$subject is bit confusing here.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The atomic update of runnable_avg_sum and runnable_avg_period are ensured
by their size and the toolchain. But we must ensure to not read an old value
for one field and a newly updated value for the other field. As we don't
want to lock other CPU while reading these fields, we read twice each fields
and check that no change have occured in the middle.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8c9d3ed..6df53b5 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3133,13 +3133,28 @@ static int select_idle_sibling(struct task_struct *p,
int target)
static inline bool is_buddy_busy(int cpu)
{
struct rq *rq = cpu_rq(cpu);
+ volatile u32 *psum = &rq->avg.runnable_avg_sum;
+ volatile u32 *pperiod = &rq->avg.runnable_avg_period;
+ u32 sum, new_sum, period, new_period;
+ int timeout = 10;
So it can be 2 times read or more as well.
+
+ while (timeout) {
+ sum = *psum;
+ period = *pperiod;
+ new_sum = *psum;
+ new_period = *pperiod;
+
+ if ((sum == new_sum) && (period == new_period))
+ break;
+
+ timeout--;
+ }
Seems like you did notice incorrect pair getting read
for rq runnable_avg_sum and runnable_avg_period. Seems
like the fix is to update them together under some lock
to avoid such issues.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 3/6] sched: pack small tasks
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
During sched_domain creation, we define a pack buddy CPU if available.
On a system that share the powerline at all level, the buddy is set to -1
On a dual clusters / dual cores system which can powergate each core and
cluster independantly, the buddy configuration will be :
| CPU0 | CPU1 | CPU2 | CPU3 |
---
buddy | CPU0 | CPU0 | CPU0 | CPU2 |
^
Is that a typo ? Should it be CPU2 instead of
CPU0 ?
Small tasks tend to slip out of the periodic load balance.
The best place to choose to migrate them is at their wake up.
I have tried this series since I was looking at some of these packing
bits. On Mobile workloads like OSIdle with Screen ON, MP3, gallary,
I did see some additional filtering of threads with this series
but its not making much difference in power. More on this below.
Signed-off-by: Vincent Guittot
---
kernel/sched/core.c |1 +
kernel/sched/fair.c | 109 ++
kernel/sched/sched.h |1 +
3 files changed, 111 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dab7908..70cadbe 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
root_domain *rd, int cpu)
rcu_assign_pointer(rq->sd, sd);
destroy_sched_domains(tmp, cpu);
+ update_packing_domain(cpu);
update_top_cache_domain(cpu);
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4f4a4f6..8c9d3ed 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -157,6 +157,63 @@ void sched_init_granularity(void)
update_sysctl();
}
+
+/*
+ * Save the id of the optimal CPU that should be used to pack small tasks
+ * The value -1 is used when no buddy has been found
+ */
+DEFINE_PER_CPU(int, sd_pack_buddy);
+
+/* Look for the best buddy CPU that can be used to pack small tasks
+ * We make the assumption that it doesn't wort to pack on CPU that share the
s/wort/worth
+ * same powerline. We looks for the 1st sched_domain without the
+ * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the lowest
+ * power per core based on the assumption that their power efficiency is
+ * better */
Commenting style..
/*
*
*/
Can you please expand the why the assumption is right ?
"it doesn't wort to pack on CPU that share the same powerline"
Think about a scenario where you have quad core, ducal cluster system
|Cluster1| |cluster 2|
| CPU0 | CPU1 | CPU2 | CPU3 | | CPU0 | CPU1 | CPU2 | CPU3 |
Both clusters run from same voltage rail and have same PLL
clocking them. But the cluster have their own power domain
and all CPU's can power gate them-self to low power states.
Clusters also have their own level2 caches.
In this case, you will still save power if you try to pack
load on one cluster. No ?
+void update_packing_domain(int cpu)
+{
+ struct sched_domain *sd;
+ int id = -1;
+
+ sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
+ if (!sd)
+ sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
+ else
+ sd = sd->parent;
+
+ while (sd) {
+ struct sched_group *sg = sd->groups;
+ struct sched_group *pack = sg;
+ struct sched_group *tmp = sg->next;
+
+ /* 1st CPU of the sched domain is a good candidate */
+ if (id == -1)
+ id = cpumask_first(sched_domain_span(sd));
+
+ /* loop the sched groups to find the best one */
+ while (tmp != sg) {
+ if (tmp->sgp->power * sg->group_weight <
+ sg->sgp->power * tmp->group_weight)
+ pack = tmp;
+ tmp = tmp->next;
+ }
+
+ /* we have found a better group */
+ if (pack != sg)
+ id = cpumask_first(sched_group_cpus(pack));
+
+ /* Look for another CPU than itself */
+ if ((id != cpu)
+|| ((sd->parent) && !(sd->parent->flags && SD_LOAD_BALANCE)))
Is the condition "!(sd->parent->flags && SD_LOAD_BALANCE)" for
big.LITTLE kind of system where SD_LOAD_BALANCE may not be used ?
+ break;
+
+ sd = sd->parent;
+ }
+
+ pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
+ per_cpu(sd_pack_buddy, cpu) = id;
+}
+
#if BITS_PER_LONG == 32
# define WMULT_CONST (~0UL)
#else
@@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct *p,
int target)
return target;
}
+static inline bool is_buddy_busy(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+
+ /*
+* A busy buddy is a CPU with a high load or a small load with a lot of
Re: [RFC 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
This new flag SD SHARE_POWERLINE reflects the sharing of the power rail
between the members of a domain. As this is the current assumption of the
scheduler, the flag is added to all sched_domain
Signed-off-by: Vincent Guittot
---
arch/ia64/include/asm/topology.h |1 +
arch/tile/include/asm/topology.h |1 +
include/linux/sched.h|1 +
include/linux/topology.h |3 +++
kernel/sched/core.c |5 +
5 files changed, 11 insertions(+)
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index a2496e4..065c720 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
| SD_BALANCE_EXEC \
| SD_BALANCE_FORK \
| SD_WAKE_AFFINE, \
+ | arch_sd_share_power_line()\
.last_balance = jiffies, \
.balance_interval = 1,\
.nr_balance_failed = 0,\
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index 7a7ce39..d39ed0b 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -72,6 +72,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
| 0*SD_PREFER_LOCAL \
| 0*SD_SHARE_CPUPOWER \
| 0*SD_SHARE_PKG_RESOURCES \
+ | arch_sd_share_power_line()\
| 0*SD_SERIALIZE\
, \
.last_balance = jiffies, \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4786b20..74f2daf 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -862,6 +862,7 @@ enum cpu_idle_type {
#define SD_WAKE_AFFINE0x0020 /* Wake task to waking CPU */
#define SD_PREFER_LOCAL 0x0040 /* Prefer to keep tasks local
to this domain */
#define SD_SHARE_CPUPOWER 0x0080 /* Domain members share cpu power */
+#define SD_SHARE_POWERLINE 0x0100 /* Domain members share power domain */
If you ignore the current use of SD_SHARE_CPUPOWER, isn't the meaning of
CPUPOWER and POWERLINE is same here. Just trying to understand the clear
meaning of this new flag. Have you not considered SD_SHARE_CPUPOWER
because it is being used for cpu_power and needs at least minimum two
domains ? SD_PACKING would have been probably more appropriate based
on the way it is being used in further series.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 6/6] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
On 24 October 2012 17:28, hongbo.zhang wrote:
> From: "hongbo.zhang"
>
> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
> also adds the platform data to support the old fashion.
>
> Signed-off-by: hongbo.zhang
> ---
> .../devicetree/bindings/thermal/db8500-thermal.txt | 40 ++
It must be included in patch 5/6
> arch/arm/boot/dts/dbx5x0.dtsi | 14 +
> arch/arm/boot/dts/snowball.dts | 31 +++
> arch/arm/mach-ux500/board-mop500.c | 64
> ++
> 4 files changed, 149 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/db8500-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> new file mode 100644
> index 000..80d53e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> @@ -0,0 +1,40 @@
> +* ST-Ericsson DB8500 Thermal
> +
> +** Thermal node properties:
> +
> +- compatible : "stericsson,db8500-thermal";
> +- reg : address range of the thermal sensor registers;
> +- interrupts : interrupts generated form PRCMU;
> +- interrupt-names : "IRQ_HOTMON_LOW" and "IRQ_HOTMON_HIGH";
> +- num-trips : number of total trip points;
> +- tripN-temp : temperature of trip point N;
> +- tripN-type : type of trip point N, should be one of "active" "passive"
> "hot" "critical";
> +- tripN-cdev-num : number of the cooling devices which can be bound to trip
> point N;
> +- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
> +
> +Usually the num-trips and tripN-*** are seperated in board related dts files.
s/seperated/separated
> +
> +Example:
> +thermal@801573c0 {
> + compatible = "stericsson,db8500-thermal";
> + reg = <0x801573c0 0x40>;
> + interrupts = <21 0x4>, <22 0x4>;
> + interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH";
> +
> + num-trips = <3>;
> +
> + trip0-temp = <7>;
> + trip0-type = "active";
> + trip0-cdev-num = <1>;
> + trip0-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip1-temp = <75000>;
> + trip1-type = "active";
> + trip1-cdev-num = <2>;
> + trip1-cdev-name0 = "thermal-cpufreq-0";
> + trip1-cdev-name1 = "thermal-fan";
> +
> + trip2-temp = <85000>;
> + trip2-type = "critical";
> + trip2-cdev-num = <0>;
> +}
> diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
> index 748ba7a..949edc2 100644
> --- a/arch/arm/boot/dts/dbx5x0.dtsi
> +++ b/arch/arm/boot/dts/dbx5x0.dtsi
> @@ -203,6 +203,14 @@
> reg = <0x80157450 0xC>;
> };
>
> + thermal@801573c0 {
> + compatible = "stericsson,db8500-thermal";
> + reg = <0x801573c0 0x40>;
> + interrupts = <21 0x4>, <22 0x4>;
> + interrupt-names = "IRQ_HOTMON_LOW",
> "IRQ_HOTMON_HIGH";
> + status = "disabled";
> +};
> +
> db8500-prcmu-regulators {
> compatible =
> "stericsson,db8500-prcmu-regulator";
>
> @@ -645,5 +653,11 @@
> ranges = <0 0x5000 0x400>;
> status = "disabled";
> };
> +
> + cpufreq-cooling {
> + compatible = "stericsson,db8500-cpufreq-cooling";
> + status = "disabled";
> +};
> +
> };
> };
> diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
> index 702c0ba..c6f85f0 100644
> --- a/arch/arm/boot/dts/snowball.dts
> +++ b/arch/arm/boot/dts/snowball.dts
> @@ -99,6 +99,33 @@
> status = "okay";
> };
>
> + prcmu@80157000 {
> + thermal@801573c0 {
> + num-trips = <4>;
> +
> + trip0-temp = <7>;
> + trip0-type = "active";
> + trip0-cdev-num = <1>;
> + trip0-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip1-temp = <75000>;
> + trip1-type = "active";
> + trip1-cdev-num = <1>;
> + trip1-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip2-temp = <8>;
> + trip2-type = "active";
> + trip2-cdev-num = <1>;
> + trip2-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip3-temp = <85000>;
> + trip3-type = "critical";
> +
Re: [PATCH V2 6/6] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
On Wed, 2012-10-24 at 19:58 +0800, hongbo.zhang wrote:
> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
> also adds the platform data to support the old fashion.
Just a trivial note:
> diff --git a/arch/arm/mach-ux500/board-mop500.c
> b/arch/arm/mach-ux500/board-mop500.c
> @@ -229,6 +230,67 @@ static struct ab8500_platform_data ab8500_platdata = {
> };
>
> /*
> + * Thermal Sensor
> + */
> +
> +static struct resource db8500_thsens_resources[] = {
should there be a const in any of these?
> +static struct db8500_thsens_platform_data db8500_thsens_data = {
[]
> +static struct platform_device u8500_thsens_device = {
[]
> +static struct platform_device u8500_cpufreq_cooling_device = {
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 5/6] Thermal: Add ST-Ericsson DB8500 thermal dirver.
On 24 October 2012 17:28, hongbo.zhang wrote:
> From: "hongbo.zhang"
>
> This diver is based on the thermal management framework in thermal_sys.c. A
> thermal zone device is created with the trip points to which cooling devices
> can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
> clipped down to cool the CPU, and other cooling devices can be added and bound
> to the trip points dynamically. The platform specific PRCMU interrupts are
> used to active thermal update when trip points are reached.
>
> Signed-off-by: hongbo.zhang
> Reviewed-by: Viresh Kumar
> Reviewed-by: Francesco Lavra
You can't add these lines, until somebody has replied you with them in
earlier mails.
They don't show that somebody has put effort in reviewing them, but that current
patch looks Ok to these guys.
> ---
> arch/arm/configs/u8500_defconfig | 4 +
This is considered as platform part. So it must be part of next patch.
> drivers/thermal/Kconfig | 20 +
> drivers/thermal/Makefile | 2 +
> drivers/thermal/db8500_cpufreq_cooling.c | 123 ++
> drivers/thermal/db8500_thermal.c | 557
> +++
> include/linux/platform_data/db8500_thermal.h | 39 ++
> 6 files changed, 745 insertions(+)
> create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
> create mode 100644 drivers/thermal/db8500_thermal.c
> create mode 100644 include/linux/platform_data/db8500_thermal.h
>
> diff --git a/arch/arm/configs/u8500_defconfig
> b/arch/arm/configs/u8500_defconfig
> index cc5e7a8..34918c4 100644
> --- a/arch/arm/configs/u8500_defconfig
> +++ b/arch/arm/configs/u8500_defconfig
> @@ -118,3 +118,7 @@ CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_INFO=y
> # CONFIG_FTRACE is not set
> CONFIG_DEBUG_USER=y
> +CONFIG_THERMAL=y
> +CONFIG_CPU_THERMAL=y
> +CONFIG_DB8500_THERMAL=y
> +CONFIG_DB8500_CPUFREQ_COOLING=y
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e1cb6bd..54c8fd0 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -31,6 +31,26 @@ config CPU_THERMAL
> and not the ACPI interface.
> If you want this support, you should say Y here.
>
> +config DB8500_THERMAL
> + bool "DB8500 thermal management"
> + depends on THERMAL
> + default y
> + help
> + Adds DB8500 thermal management implementation according to the
> thermal
> + management framework. A thermal zone with several trip points will
> be
> + created. Cooling devices can be bound to the trip points to cool
> this
> + thermal zone if trip points reached.
> +
> +config DB8500_CPUFREQ_COOLING
> + tristate "DB8500 cpufreq cooling"
> + depends on CPU_THERMAL
> + default y
> + help
> + Adds DB8500 cpufreq cooling devices, and these cooling devices can
> be
> + bound to thermal zone trip points. When a trip point reached, the
> + bound cpufreq cooling device turns active to set CPU frequency low
> to
> + cool down the CPU.
> +
> config SPEAR_THERMAL
> bool "SPEAr thermal sensor driver"
> depends on THERMAL
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 885550d..c7a8dab 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -7,3 +7,5 @@ obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
> obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> +obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
> +obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
> diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
> b/drivers/thermal/db8500_cpufreq_cooling.c
> new file mode 100644
> index 000..e4eddfd
> --- /dev/null
> +++ b/drivers/thermal/db8500_cpufreq_cooling.c
> @@ -0,0 +1,123 @@
> +/*
> + * db8500_cpufreq_cooling.c - db8500 cpufreq works as cooling device.
> + *
> + * Copyright (C) 2012 ST-Ericsson
> + * Copyright (C) 2012 Linaro Ltd.
> + *
> + * Author: Hongbo Zhang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
remove extra blank line.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static LIST_HEAD(db8500_cpufreq_cdev_list);
> +
> +struct db8500_cpufreq_cdev {
> + struct thermal_cooling_device *cdev;
> + struct list_head node;
> +};
>
git.l.o: please add post-update hooks to run git-update-server-info
Hi all! An user reported problems cloning a tree from git.linaro.org today with a /git-ro URL: git clone http://git.linaro.org/git-ro/people/foo/bar.git He was getting: fatal: http://git.linaro.org/git-ro/people/foo/bar.git/info/refs not found: did you run git update-server-info on the server? This is because by default, git repos wont be kept up-to-date for http access. The fix is trivial, it's a matter of enabling a "post-update hook" which will run "git update-server-info" in this repo whenever you push new commits. There should already be a template to do this readily available just after you create a new git repo; just remember to run: cd /srv/git.linaro.org/git/foo/bar.git mv hooks/post-update.sample hooks/post-update Below is a list of affected repos; I prefer not fixing them because I don't have enough permissions to do this on all repos, and because you will have to do it for new repos anyway :-) find -L /srv/git.linaro.org/git -iname \*.git -type d | while read d; do [ -e $d/hooks/post-update ] || echo $d; done people/danilo/android-manifest.git people/danilo/android.git people/mansson/snowball/ltp.git people/afrantzis/apitrace.git people/dlezcano/pm-qa.git people/dlezcano/cpuidle-next.git people/dlezcano/linux-next.git people/kurt-r-taylor/android-ucm.git people/kurt-r-taylor/alsa-ucm.git people/kurt-r-taylor/alsa-ucm-utils.git people/dmart/linux-3-arm.git people/dmart/linux-2.6.git people/dmart/linux-2.6-arm.git people/dmart/tunsetup.git people/dmart/arm-virt-bl.git people/dmart/boot-wrapper.git people/arnd/flashbench.git people/arnd/imx.git people/arnd/demo.git people/arnd/arm-soc.git people/niklashernaeus/snowball-device-tree.git people/ljones/linux-2.6.38-ux500.git people/ljones/landingteamtools.git people/ljones/linux-3.0-ux500.git people/ljones/linux-2.6.35-ux500.git people/sariohu/ffmpeg-0.6.1.git people/sariohu/gstreamer0-11.git people/sariohu/xbmc.git people/sariohu/gst-plugins-base0-11.git people/sariohu/gst-plugins-good0-11.git people/sariohu/aacenc.git people/mszyprowski/linux-archive.git people/gesha/mynewproject/.git people/bgaignard/ion_test_application.git people/bgaignard/gst-openmax-0.10.x.git people/bgaignard/lava_realvideo_test.git people/tushar/umm-zero-copy-demo.git people/fboudra/ioquake3.git people/fboudra/irrlicht-gles.git people/fboudra/release-and-project-management.git people/fboudra/ogre3d-gles.git people/fboudra/ioquake3-gles.git people/sumitsemwal/linux-3.x.git people/sumitsemwal/linux-dma-buf.git people/vingu/kernel.git people/shawnguo/linux-2.6.git people/tomgall/meego/libresource.git people/tomgall/meego/contextkit.git people/tomgall/meego/libresourceqt.git people/tomgall/meego/libmeegotouch.git people/tomgall/meego/libjpeg-turbo.git people/tomgall/meego/meegotouch-compositor.git people/tomgall/libjpeg-turbo-leb/libjpeg-turbo.git people/pawelmoll/linux.git people/jstultz/android-dev.git people/jstultz/linux.git people/jstultz/android.git people/jcrigby/kernel-package-info.git people/jcrigby/ubuntu-packaging-ci-upstreams.git people/jcrigby/linaro-boot-utils.git people/jcrigby/linux-lt-ci-pack-info.git people/jcrigby/ubuntu/linux-linaro-oneiric.git people/jcrigby/ubuntu/future-linux-linaro-precise-3.2.git people/jcrigby/ubuntu/linux-history.git people/jcrigby/ubuntu/linux-linaro-quantal.git people/jcrigby/ubuntu/linux-linaro-precise.git people/jcrigby/ubuntu/linux-meta-linaro-natty.git people/jcrigby/linux-lt.git people/jcrigby/null-packaging.git people/jcrigby/ubuntu-kernel-ci.git people/nico/linux.git people/weifeng/bellagio_components.git people/weifeng/gst-plugins-gl.git people/weifeng/gst-openmax.git people/weifeng/kernel.git people/weifeng/alsa-ucm-test.git people/weifeng/pulseaudio.git people/pfalcon/android/platform/manifest.git people/pfalcon/android/linaro/build-configs.git people/andygreen/arm-probe.git people/andygreen/repo-branch-archive.git people/andygreen/lt-tools.git people/chaoyang/jpeg.git people/chaoyang/libpng.git people/bernhardrosenkranzer/repo-branch-archive.git people/salgado/patchwork.git people/mpoirier/snowball/linux-integration-3.0-ux500-androidized.git people/mpoirier/u-boot-v2011.06.git people/mpoirier/linux-ubuntu-3.0.n900.git people/ryanharkin/stm.git people/ryanharkin/repo-branch-archive.git people/ryanharkin/uefi-config.git people/mwaddel/u-boot.git people/rmk/linux-arm.git people/tixy/u-boot.git people/tixy/linux.git people/tixy/android-common.git people/tixy/uefi.git people/tixy/android-manifest.git people/tixy/android-vexpress-a9.git people/tixy/kernel.git people/tixy/android-kernel.git people/triad/linux-stericsson.git people/triad/linux-pinctrl.git people/planglais/linux-tb-ux500.git people/paulliu/linux-2.6.git people/rsalveti/linux-linaro-3.0.git people/mbriand/linux-2.6-arm.git people/pmaydell/qemu-arm.git people/pmaydell/boot-wrapper.git people/hrw/cross-toolchain-packaging.git people/asac/android/external/skia.git people/asac/android/packages/apps/Launcher.git people/asac/android/kerne
Re: [PATCH V2 3/6] Thermal: fix bug of counting cpu frequencies.
On 24 October 2012 17:28, hongbo.zhang wrote: > From: "hongbo.zhang" > > In the while loop for counting cpu frequencies, if table[i].frequency equals > CPUFREQ_ENTRY_INVALID, index i won't be increased, so this leads to an endless > loop, what's more the index i cannot be referred as cpu frequencies number if > there is CPUFREQ_ENTRY_INVALID case. > > Signed-off-by: hongbo.zhang Good one. Reviewed-by: Viresh Kumar ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
TC2s offline
Hi All, Due to a glitch with UEFI and the latest kernels, we are forced to leave the TC2s offline until the issue is resolved. Ryan Harkin and I have been working to try and resolve this, but the best we could do is to get them to pass their health check (using sticking plaster, string and a large hammer) but they would then fail every test that was submitted to them, which would be kind of pointless. We're working actively to fix this problem, and I'll let you know when we're back up and running. Thanks, and apologies once again, Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 5/6] Thermal: Add ST-Ericsson DB8500 thermal dirver.
From: "hongbo.zhang"
This diver is based on the thermal management framework in thermal_sys.c. A
thermal zone device is created with the trip points to which cooling devices
can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
clipped down to cool the CPU, and other cooling devices can be added and bound
to the trip points dynamically. The platform specific PRCMU interrupts are
used to active thermal update when trip points are reached.
Signed-off-by: hongbo.zhang
Reviewed-by: Viresh Kumar
Reviewed-by: Francesco Lavra
---
arch/arm/configs/u8500_defconfig | 4 +
drivers/thermal/Kconfig | 20 +
drivers/thermal/Makefile | 2 +
drivers/thermal/db8500_cpufreq_cooling.c | 123 ++
drivers/thermal/db8500_thermal.c | 557 +++
include/linux/platform_data/db8500_thermal.h | 39 ++
6 files changed, 745 insertions(+)
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index cc5e7a8..34918c4 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -118,3 +118,7 @@ CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO=y
# CONFIG_FTRACE is not set
CONFIG_DEBUG_USER=y
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_DB8500_THERMAL=y
+CONFIG_DB8500_CPUFREQ_COOLING=y
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e1cb6bd..54c8fd0 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -31,6 +31,26 @@ config CPU_THERMAL
and not the ACPI interface.
If you want this support, you should say Y here.
+config DB8500_THERMAL
+ bool "DB8500 thermal management"
+ depends on THERMAL
+ default y
+ help
+ Adds DB8500 thermal management implementation according to the thermal
+ management framework. A thermal zone with several trip points will be
+ created. Cooling devices can be bound to the trip points to cool this
+ thermal zone if trip points reached.
+
+config DB8500_CPUFREQ_COOLING
+ tristate "DB8500 cpufreq cooling"
+ depends on CPU_THERMAL
+ default y
+ help
+ Adds DB8500 cpufreq cooling devices, and these cooling devices can be
+ bound to thermal zone trip points. When a trip point reached, the
+ bound cpufreq cooling device turns active to set CPU frequency low to
+ cool down the CPU.
+
config SPEAR_THERMAL
bool "SPEAr thermal sensor driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 885550d..c7a8dab 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,3 +7,5 @@ obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
+obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
+obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
b/drivers/thermal/db8500_cpufreq_cooling.c
new file mode 100644
index 000..e4eddfd
--- /dev/null
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -0,0 +1,123 @@
+/*
+ * db8500_cpufreq_cooling.c - db8500 cpufreq works as cooling device.
+ *
+ * Copyright (C) 2012 ST-Ericsson
+ * Copyright (C) 2012 Linaro Ltd.
+ *
+ * Author: Hongbo Zhang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static LIST_HEAD(db8500_cpufreq_cdev_list);
+
+struct db8500_cpufreq_cdev {
+ struct thermal_cooling_device *cdev;
+ struct list_head node;
+};
+
+static int __devinit db8500_cpufreq_cooling_probe(struct platform_device *pdev)
+{
+ struct db8500_cpufreq_cdev *cooling_dev;
+ struct cpumask mask_val;
+
+ cooling_dev = devm_kzalloc(&pdev->dev,
+ sizeof(*cooling_dev), GFP_KERNEL);
+ if (!cooling_dev)
+ return -ENOMEM;
+
+ cpumask_set_cpu(0, &mask_val);
+ cooling_dev->cdev = cpufreq_cooling_register(&mask_val);
+
+ if (IS_ERR_OR_NULL(cooling_dev->cdev)) {
+ dev_err(&pdev->dev,
+ "Failed to register cpufreq cooling device\n");
[PATCH V2 6/6] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
From: "hongbo.zhang"
This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
also adds the platform data to support the old fashion.
Signed-off-by: hongbo.zhang
---
.../devicetree/bindings/thermal/db8500-thermal.txt | 40 ++
arch/arm/boot/dts/dbx5x0.dtsi | 14 +
arch/arm/boot/dts/snowball.dts | 31 +++
arch/arm/mach-ux500/board-mop500.c | 64 ++
4 files changed, 149 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
new file mode 100644
index 000..80d53e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
@@ -0,0 +1,40 @@
+* ST-Ericsson DB8500 Thermal
+
+** Thermal node properties:
+
+- compatible : "stericsson,db8500-thermal";
+- reg : address range of the thermal sensor registers;
+- interrupts : interrupts generated form PRCMU;
+- interrupt-names : "IRQ_HOTMON_LOW" and "IRQ_HOTMON_HIGH";
+- num-trips : number of total trip points;
+- tripN-temp : temperature of trip point N;
+- tripN-type : type of trip point N, should be one of "active" "passive" "hot"
"critical";
+- tripN-cdev-num : number of the cooling devices which can be bound to trip
point N;
+- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
+
+Usually the num-trips and tripN-*** are seperated in board related dts files.
+
+Example:
+thermal@801573c0 {
+ compatible = "stericsson,db8500-thermal";
+ reg = <0x801573c0 0x40>;
+ interrupts = <21 0x4>, <22 0x4>;
+ interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH";
+
+ num-trips = <3>;
+
+ trip0-temp = <7>;
+ trip0-type = "active";
+ trip0-cdev-num = <1>;
+ trip0-cdev-name0 = "thermal-cpufreq-0";
+
+ trip1-temp = <75000>;
+ trip1-type = "active";
+ trip1-cdev-num = <2>;
+ trip1-cdev-name0 = "thermal-cpufreq-0";
+ trip1-cdev-name1 = "thermal-fan";
+
+ trip2-temp = <85000>;
+ trip2-type = "critical";
+ trip2-cdev-num = <0>;
+}
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 748ba7a..949edc2 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -203,6 +203,14 @@
reg = <0x80157450 0xC>;
};
+ thermal@801573c0 {
+ compatible = "stericsson,db8500-thermal";
+ reg = <0x801573c0 0x40>;
+ interrupts = <21 0x4>, <22 0x4>;
+ interrupt-names = "IRQ_HOTMON_LOW",
"IRQ_HOTMON_HIGH";
+ status = "disabled";
+};
+
db8500-prcmu-regulators {
compatible =
"stericsson,db8500-prcmu-regulator";
@@ -645,5 +653,11 @@
ranges = <0 0x5000 0x400>;
status = "disabled";
};
+
+ cpufreq-cooling {
+ compatible = "stericsson,db8500-cpufreq-cooling";
+ status = "disabled";
+};
+
};
};
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 702c0ba..c6f85f0 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -99,6 +99,33 @@
status = "okay";
};
+ prcmu@80157000 {
+ thermal@801573c0 {
+ num-trips = <4>;
+
+ trip0-temp = <7>;
+ trip0-type = "active";
+ trip0-cdev-num = <1>;
+ trip0-cdev-name0 = "thermal-cpufreq-0";
+
+ trip1-temp = <75000>;
+ trip1-type = "active";
+ trip1-cdev-num = <1>;
+ trip1-cdev-name0 = "thermal-cpufreq-0";
+
+ trip2-temp = <8>;
+ trip2-type = "active";
+ trip2-cdev-num = <1>;
+ trip2-cdev-name0 = "thermal-cpufreq-0";
+
+ trip3-temp = <85000>;
+ trip3-type = "critical";
+ trip3-cdev-num = <0>;
+
+ status = "okay";
+};
+ };
+
external-bus@5000 {
status = "okay";
@@ -183,5 +210,9 @@
reg = <0x33>;
};
};
+
+ cpufreq-cooling {
+
[PATCH V2 3/6] Thermal: fix bug of counting cpu frequencies.
From: "hongbo.zhang"
In the while loop for counting cpu frequencies, if table[i].frequency equals
CPUFREQ_ENTRY_INVALID, index i won't be increased, so this leads to an endless
loop, what's more the index i cannot be referred as cpu frequencies number if
there is CPUFREQ_ENTRY_INVALID case.
Signed-off-by: hongbo.zhang
---
drivers/thermal/cpu_cooling.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 7519a0b..415b041 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -245,6 +245,7 @@ static int cpufreq_get_max_state(struct
thermal_cooling_device *cdev,
struct cpumask *maskPtr;
unsigned int cpu;
struct cpufreq_frequency_table *table;
+ unsigned long count = 0;
mutex_lock(&cooling_cpufreq_lock);
list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
@@ -263,13 +264,14 @@ static int cpufreq_get_max_state(struct
thermal_cooling_device *cdev,
goto return_get_max_state;
}
- while (table[i].frequency != CPUFREQ_TABLE_END) {
+ for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
continue;
- i++;
+ count++;
}
- if (i > 0) {
- *state = --i;
+
+ if (count > 0) {
+ *state = --count;
ret = 0;
}
--
1.7.11.3
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.
From: "hongbo.zhang"
Problem of using this list is that the cpufreq_get_max_state callback will be
called when register cooling device by thermal_cooling_device_register, but
this list isn't ready at this moment. What's more, there is no need to maintain
such a list, we can get cpufreq_cooling_device instance by the private
thermal_cooling_device.devdata.
Signed-off-by: hongbo.zhang
---
drivers/thermal/cpu_cooling.c | 81 +--
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 415b041..cc80d29 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -58,8 +58,9 @@ struct cpufreq_cooling_device {
};
static LIST_HEAD(cooling_cpufreq_list);
static DEFINE_IDR(cpufreq_idr);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
-static struct mutex cooling_cpufreq_lock;
+static unsigned int cpufreq_dev_count;
/* notify_table passes value to the CPUFREQ_ADJUST callback function. */
#define NOTIFY_INVALID NULL
@@ -241,20 +242,12 @@ static int cpufreq_get_max_state(struct
thermal_cooling_device *cdev,
unsigned long *state)
{
int ret = -EINVAL, i = 0;
- struct cpufreq_cooling_device *cpufreq_device;
+ struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
struct cpumask *maskPtr;
unsigned int cpu;
struct cpufreq_frequency_table *table;
unsigned long count = 0;
- mutex_lock(&cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
- if (cpufreq_device && cpufreq_device->cool_dev == cdev)
- break;
- }
- if (cpufreq_device == NULL)
- goto return_get_max_state;
-
maskPtr = &cpufreq_device->allowed_cpus;
cpu = cpumask_any(maskPtr);
table = cpufreq_frequency_get_table(cpu);
@@ -276,7 +269,6 @@ static int cpufreq_get_max_state(struct
thermal_cooling_device *cdev,
}
return_get_max_state:
- mutex_unlock(&cooling_cpufreq_lock);
return ret;
}
@@ -288,20 +280,10 @@ return_get_max_state:
static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- int ret = -EINVAL;
- struct cpufreq_cooling_device *cpufreq_device;
-
- mutex_lock(&cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
- if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
- *state = cpufreq_device->cpufreq_state;
- ret = 0;
- break;
- }
- }
- mutex_unlock(&cooling_cpufreq_lock);
+ struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
- return ret;
+ *state = cpufreq_device->cpufreq_state;
+ return 0;
}
/**
@@ -312,22 +294,9 @@ static int cpufreq_get_cur_state(struct
thermal_cooling_device *cdev,
static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
unsigned long state)
{
- int ret = -EINVAL;
- struct cpufreq_cooling_device *cpufreq_device;
-
- mutex_lock(&cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
- if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
- ret = 0;
- break;
- }
- }
- if (!ret)
- ret = cpufreq_apply_cooling(cpufreq_device, state);
+ struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
- mutex_unlock(&cooling_cpufreq_lock);
-
- return ret;
+ return cpufreq_apply_cooling(cpufreq_device, state);
}
/* Bind cpufreq callbacks to thermal cooling device ops */
@@ -351,7 +320,7 @@ struct thermal_cooling_device *cpufreq_cooling_register(
{
struct thermal_cooling_device *cool_dev;
struct cpufreq_cooling_device *cpufreq_dev = NULL;
- unsigned int cpufreq_dev_count = 0, min = 0, max = 0;
+ unsigned int min = 0, max = 0;
char dev_name[THERMAL_NAME_LENGTH];
int ret = 0, i;
struct cpufreq_policy policy;
@@ -360,9 +329,6 @@ struct thermal_cooling_device *cpufreq_cooling_register(
if (!cpufreq_frequency_get_table(cpumask_any(clip_cpus)))
return ERR_PTR(-EPROBE_DEFER);
- list_for_each_entry(cpufreq_dev, &cooling_cpufreq_list, node)
- cpufreq_dev_count++;
-
/*Verify that all the clip cpus have same freq_min, freq_max limit*/
for_each_cpu(i, clip_cpus) {
/*continue if cpufreq policy not found and not return error*/
@@ -384,9 +350,6 @@ struct thermal_cooling_device *cpufreq_cooling_register(
cpumask_copy(&cpufreq_dev->allowed_cpus, clip_cpus);
- if (cpufreq_dev_count == 0)
-
[PATCH V2 2/6] Thermal: make sure cpufreq cooling register after cpufreq driver
From: "hongbo.zhang" The cpufreq works as a cooling device, so the cooling layer should check if the cpufreq driver is initialized or not. Signed-off-by: hongbo.zhang --- drivers/thermal/cpu_cooling.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index b6b4c2a..7519a0b 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -354,6 +354,10 @@ struct thermal_cooling_device *cpufreq_cooling_register( int ret = 0, i; struct cpufreq_policy policy; + /* make sure cpufreq driver has been initialized */ + if (!cpufreq_frequency_get_table(cpumask_any(clip_cpus))) + return ERR_PTR(-EPROBE_DEFER); + list_for_each_entry(cpufreq_dev, &cooling_cpufreq_list, node) cpufreq_dev_count++; -- 1.7.11.3 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 1/6] Thermal: add indent for code alignment.
From: "hongbo.zhang" The curly bracket should be aligned with corresponding if else statements. Signed-off-by: hongbo.zhang Reviewed-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index cc1c930..b6b4c2a 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -369,7 +369,7 @@ struct thermal_cooling_device *cpufreq_cooling_register( if (min != policy.cpuinfo.min_freq || max != policy.cpuinfo.max_freq) return ERR_PTR(-EINVAL); -} + } } cpufreq_dev = kzalloc(sizeof(struct cpufreq_cooling_device), GFP_KERNEL); -- 1.7.11.3 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 0/6] Fix thermal bugs and Upstream ST-Ericsson thermal driver
From: "hongbo.zhang" V1->V2 Changes: DB8500 thermal dirver: Accept comments from Francesco Lavra and Viresh Kumar, and split platform and driver parts into separate patches. Thermal layer: Cancel the patch for deferring bind due to new patch for generic cpu cooling layer to fix this issue. CPU cooling layer: New patch "Remove the cooling_cpufreq_list" added, thus old patch to fix empty list checking is also removed. hongbo.zhang (6): Thermal: add indent for code alignment. Thermal: make sure cpufreq cooling register after cpufreq driver Thermal: fix bug of counting cpu frequencies. Thermal: Remove the cooling_cpufreq_list. Thermal: Add ST-Ericsson DB8500 thermal dirver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 40 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 ++ arch/arm/configs/u8500_defconfig | 4 + arch/arm/mach-ux500/board-mop500.c | 64 +++ drivers/thermal/Kconfig| 20 + drivers/thermal/Makefile | 2 + drivers/thermal/cpu_cooling.c | 95 +--- drivers/thermal/db8500_cpufreq_cooling.c | 123 + drivers/thermal/db8500_thermal.c | 557 + include/linux/platform_data/db8500_thermal.h | 39 ++ 11 files changed, 920 insertions(+), 69 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On 24 October 2012 09:29, Jon Medhurst (Tixy) wrote: > On Tue, 2012-10-23 at 22:56 -0400, Nicolas Pitre wrote: >> I >> still recommend to read the following pages to get familiar with this >> beast: >> >> https://wiki.linaro.org/PawelMoll/BootingVEMadeEasy > >> https://wiki.linaro.org/ARM/VersatileExpressSetup >> >> This page shows how to install U-Boot on a Virtual Express and that's >> what we want here. > > We've been asked to 'garden' the wiki for vexpress related things, and I > suspect pages like these are due for the chop in a matter of hours. So I > recommend people grab themselves a copy quick. Luckily, Anmar and me agreed that we would leave the old pages there and put a huge ugly disclaimer on the top with a link redirecting to the updated content in most cases. > > The official release pages will include _some_ similar (and more up to > date information), however you won't find any mention of any bootloader > other than UEFI. And, at least for now, no mention of how to boot a > kernel other than by removing the SD card and copying it over. > > Personally (and unofficially), I find that the simplest and most > reliable way to use vexpress is to flash the kernel/dtb/initrd images > into NOR flash and use the bootmonitor supplied with the board to load > these. No you don't. The party line is: we all use UEFI. ;-) > Putting the images into NOR flash involves modifying the contents of the > on-board micro-SD card first, which can be done by mounting it over USB > from your PC, and so is easily scripted. And, if you have the > bootmonitor set to automatically run a bootscript to load the kernel > (DIP switch nearest USB cable down), then you can also use the same > method to modify this bootscript to change things like kernel > command-line args. > > As I've started now, I may as well attach my images.txt file for TC2 and > my bootscr.txt file from the internal SD card, so you get the idea. > > -- > Tixy > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 04/10] sched: Introduce priority-based task migration filter
在 2012-10-09二的 17:40 +0100，Morten Rasmussen写道：
> On Thu, Oct 04, 2012 at 07:27:00AM +0100, Viresh Kumar wrote:
> > On 22 September 2012 00:02, wrote:
> >
> > > +config SCHED_HMP_PRIO_FILTER
> > > + bool "(EXPERIMENTAL) Filter HMP migrations by task priority"
> > > + depends on SCHED_HMP
> >
> > Should it depend on EXPERIMENTAL?
> >
> > > + help
> > > + Enables task priority based HMP migration filter. Any task with
> > > + a NICE value above the threshold will always be on low-power
> > > cpus
> > > + with less compute capacity.
> > > +
> > > +config SCHED_HMP_PRIO_FILTER_VAL
> > > + int "NICE priority threshold"
> > > + default 5
> > > + depends on SCHED_HMP_PRIO_FILTER
> > > +
> > > config HAVE_ARM_SCU
> > > bool
> > > help
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 490f1f0..8f0f3b9 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -3129,9 +3129,12 @@ static int __init hmp_cpu_mask_setup(void)
> > > * hmp_down_threshold: max. load allowed for tasks migrating to a slower
> > > cpu
> > > * The default values (512, 256) offer good responsiveness, but may need
> > > * tweaking suit particular needs.
> > > + *
> > > + * hmp_up_prio: Only up migrate task with high priority ( > > */
> > > unsigned int hmp_up_threshold = 512;
> > > unsigned int hmp_down_threshold = 256;
hmp_*_threshold maybe sysctl_hmp_*_threshold,
and appear at /proc/sys/kernel,
so, can be adjusted to be rational.
> > > +unsigned int hmp_up_prio =
> > > NICE_TO_PRIO(CONFIG_SCHED_HMP_PRIO_FILTER_VAL);
> > >
> > > static unsigned int hmp_up_migration(int cpu, struct sched_entity *se);
> > > static unsigned int hmp_down_migration(int cpu, struct sched_entity *se);
> > > @@ -5491,6 +5494,12 @@ static unsigned int hmp_up_migration(int cpu,
> > > struct sched_entity *se)
> > > if (hmp_cpu_is_fastest(cpu))
> > > return 0;
> > >
> > > +#ifdef CONFIG_SCHED_HMP_PRIO_FILTER
> > > + /* Filter by task priority */
> > > + if (p->prio >= hmp_up_prio)
> > > + return 0;
> > > +#endif
> > > +
> > > if (cpumask_intersects(&hmp_faster_domain(cpu)->cpus,
> > > tsk_cpus_allowed(p))
> > > && se->avg.load_avg_ratio > hmp_up_threshold) {
> > > @@ -5507,6 +5516,12 @@ static unsigned int hmp_down_migration(int cpu,
> > > struct sched_entity *se)
> > > if (hmp_cpu_is_slowest(cpu))
> > > return 0;
> > >
> > > +#ifdef CONFIG_SCHED_HMP_PRIO_FILTER
> > > + /* Filter by task priority */
> > > + if (p->prio >= hmp_up_prio)
> > > + return 1;
> > > +#endif
> >
> > Even if below cpumask_intersects() fails?
> >
>
> No. Good catch :)
>
> > > if (cpumask_intersects(&hmp_slower_domain(cpu)->cpus,
> > > tsk_cpus_allowed(p))
> > > && se->avg.load_avg_ratio < hmp_down_threshold) {
> >
> > --
> > viresh
> >
>
> Thanks,
> Morten
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Tue, 2012-10-23 at 22:56 -0400, Nicolas Pitre wrote: > I > still recommend to read the following pages to get familiar with this > beast: > > https://wiki.linaro.org/PawelMoll/BootingVEMadeEasy > https://wiki.linaro.org/ARM/VersatileExpressSetup > > This page shows how to install U-Boot on a Virtual Express and that's > what we want here. We've been asked to 'garden' the wiki for vexpress related things, and I suspect pages like these are due for the chop in a matter of hours. So I recommend people grab themselves a copy quick. The official release pages will include _some_ similar (and more up to date information), however you won't find any mention of any bootloader other than UEFI. And, at least for now, no mention of how to boot a kernel other than by removing the SD card and copying it over. Personally (and unofficially), I find that the simplest and most reliable way to use vexpress is to flash the kernel/dtb/initrd images into NOR flash and use the bootmonitor supplied with the board to load these. Putting the images into NOR flash involves modifying the contents of the on-board micro-SD card first, which can be done by mounting it over USB from your PC, and so is easily scripted. And, if you have the bootmonitor set to automatically run a bootscript to load the kernel (DIP switch nearest USB cable down), then you can also use the same method to modify this bootscript to change things like kernel command-line args. As I've started now, I may as well attach my images.txt file for TC2 and my bootscr.txt file from the internal SD card, so you get the idea. -- Tixy VEMSD.tar.gz Description: application/compressed-tar ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] cpufreq: Fix sparse warnings by updating cputime64_t to u64
There were few sparse warnings due to mismatch of type on function arguments.
Two types were used u64 and cputime64_t. Both are actually u64, so use u64 only.
Reported-by: Fengguang Wu
Signed-off-by: Viresh Kumar
---
This solution was discussed here:
http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg13744.html
drivers/cpufreq/cpufreq_governor.c | 4 ++--
drivers/cpufreq/cpufreq_governor.h | 11 +--
drivers/cpufreq/cpufreq_stats.c| 4 ++--
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index cd5fe57..e39bf81 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -49,7 +49,7 @@ static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu,
u64 *wall)
return jiffies_to_usecs(idle_time);
}
-cputime64_t get_cpu_idle_time(unsigned int cpu, cputime64_t *wall)
+u64 get_cpu_idle_time(unsigned int cpu, u64 *wall)
{
u64 idle_time = get_cpu_idle_time_us(cpu, NULL);
@@ -81,7 +81,7 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
/* Get Absolute Load (in terms of freq for ondemand gov) */
for_each_cpu(j, policy->cpus) {
struct cpu_dbs_common_info *j_cdbs;
- cputime64_t cur_wall_time, cur_idle_time, cur_iowait_time;
+ u64 cur_wall_time, cur_idle_time, cur_iowait_time;
unsigned int idle_time, wall_time, iowait_time;
unsigned int load;
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index 34e14ad..f661654 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -17,7 +17,6 @@
#ifndef _CPUFREQ_GOVERNER_H
#define _CPUFREQ_GOVERNER_H
-#include
#include
#include
#include
@@ -72,9 +71,9 @@ static void *get_cpu_dbs_info_s(int cpu)
\
/* Per cpu structures */
struct cpu_dbs_common_info {
int cpu;
- cputime64_t prev_cpu_idle;
- cputime64_t prev_cpu_wall;
- cputime64_t prev_cpu_nice;
+ u64 prev_cpu_idle;
+ u64 prev_cpu_wall;
+ u64 prev_cpu_nice;
struct cpufreq_policy *cur_policy;
struct delayed_work work;
/*
@@ -87,7 +86,7 @@ struct cpu_dbs_common_info {
struct od_cpu_dbs_info_s {
struct cpu_dbs_common_info cdbs;
- cputime64_t prev_cpu_iowait;
+ u64 prev_cpu_iowait;
struct cpufreq_frequency_table *freq_table;
unsigned int freq_lo;
unsigned int freq_lo_jiffies;
@@ -170,7 +169,7 @@ static inline int delay_for_sampling_rate(unsigned int
sampling_rate)
return delay;
}
-cputime64_t get_cpu_idle_time(unsigned int cpu, cputime64_t *wall);
+u64 get_cpu_idle_time(unsigned int cpu, u64 *wall);
void dbs_check_cpu(struct dbs_data *dbs_data, int cpu);
int cpufreq_governor_dbs(struct dbs_data *dbs_data,
struct cpufreq_policy *policy, unsigned int event);
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index b40ee14..683a48f 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -37,7 +37,7 @@ struct cpufreq_stats {
unsigned int max_state;
unsigned int state_num;
unsigned int last_index;
- cputime64_t *time_in_state;
+ u64 *time_in_state;
unsigned int *freq_table;
#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
unsigned int *trans_table;
@@ -223,7 +223,7 @@ static int cpufreq_stats_create_table(struct cpufreq_policy
*policy,
count++;
}
- alloc_size = count * sizeof(int) + count * sizeof(cputime64_t);
+ alloc_size = count * sizeof(int) + count * sizeof(u64);
#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
alloc_size += count * count * sizeof(int);
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] cpufreq: Fix sparse warning by making local function static
cpufreq_disabled() is a local function, so should be marked static.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index f552d5f..261ef65 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -129,7 +129,7 @@ static int __init
init_cpufreq_transition_notifier_list(void)
pure_initcall(init_cpufreq_transition_notifier_list);
static int off __read_mostly;
-int cpufreq_disabled(void)
+static int cpufreq_disabled(void)
{
return off;
}
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
