Re: [PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Zhang Rui 
On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
 From: hongbo.zhang hongbo.zh...@linaro.com
 
 This driver 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 hongbo.zh...@linaro.com
 Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
 Reviewed-by: Francesco Lavra francescolavra...@gmail.com

 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

why is this bool?

thanks,
rui



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Hongbo Zhang 
On 15 November 2012 16:13, Zhang Rui rui.zh...@intel.com wrote:
 On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
 From: hongbo.zhang hongbo.zh...@linaro.com

 This driver 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 hongbo.zh...@linaro.com
 Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
 Reviewed-by: Francesco Lavra francescolavra...@gmail.com

 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

 why is this bool?

platform specific PRCMU interfaces are used, and those interfaces are
not exported, so my driver cannot be compiled as a module.


 thanks,
 rui


 --
 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/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Zhang Rui 
On Thu, 2012-11-15 at 16:32 +0800, Hongbo Zhang wrote:
 On 15 November 2012 16:13, Zhang Rui rui.zh...@intel.com wrote:
  On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
  From: hongbo.zhang hongbo.zh...@linaro.com
 
  This driver 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 hongbo.zh...@linaro.com
  Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
  Reviewed-by: Francesco Lavra francescolavra...@gmail.com
 
  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
 
  why is this bool?
 
 platform specific PRCMU interfaces are used, and those interfaces are
 not exported, so my driver cannot be compiled as a module.
 
ok.
But I still alway get this error message when set DB8500_THERMAL,
include/linux/mfd/dbx500-prcmu.h:459:19: error: redefinition of
‘prcmu_abb_read’
include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of
‘prcmu_abb_read’ was here
include/linux/mfd/dbx500-prcmu.h:464:19: error: redefinition of
‘prcmu_abb_write’
include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of
‘prcmu_abb_write’ was here
include/linux/mfd/dbx500-prcmu.h:475:19: error: redefinition of
‘prcmu_config_clkout’
include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of
‘prcmu_config_clkout’ was here
include/linux/mfd/dbx500-prcmu.h:537:19: error: redefinition of
‘prcmu_ac_wake_req’
include/linux/mfd/db8500-prcmu.h:683:19: note: previous definition of
‘prcmu_ac_wake_req’ was here
include/linux/mfd/dbx500-prcmu.h:542:20: error: redefinition of
‘prcmu_ac_sleep_req’
include/linux/mfd/db8500-prcmu.h:688:20: note: previous definition of
‘prcmu_ac_sleep_req’ was here

$ grep prcmu_abb_read include/linux/mfd/*
include/linux/mfd/db8500-prcmu.h:int prcmu_abb_read(u8 slave, u8 reg, u8
*value, u8 size);
include/linux/mfd/db8500-prcmu.h:static inline int prcmu_abb_read(u8
slave, u8 reg, u8 *value, u8 size)
include/linux/mfd/dbx500-prcmu.h:int prcmu_abb_read(u8 slave, u8 reg, u8
*value, u8 size);
include/linux/mfd/dbx500-prcmu.h:static inline int prcmu_abb_read(u8
slave, u8 reg, u8 *value, u8 size)

this functions are defined in both db8500-prmcu.h and dbx500-prcmu.h,
plus linux/mfd/dbx500-prcmu.h includes linux/mfd/db8500-prcmu.h.

I do not know how it works before, but this is a bug to me.

thanks,
rui


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 3/3] netfilter: xt_quota2: Remove extra parameter from netlink_kernel_create

2012-11-15 Thread Tushar Behera 
Required as per commit 9f00d9776bc5 (netlink: hide struct module
parameter in netlink_kernel_create).

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
 net/netfilter/xt_quota2.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/xt_quota2.c b/net/netfilter/xt_quota2.c
index 3a9c1f9..8163f37 100644
--- a/net/netfilter/xt_quota2.c
+++ b/net/netfilter/xt_quota2.c
@@ -350,14 +350,15 @@ static struct xt_match quota_mt2_reg[] __read_mostly = {
 static int __init quota_mt2_init(void)
 {
int ret;
+#ifdef CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG
struct netlink_kernel_cfg cfg = {
.groups = 1,
};
+#endif
pr_debug(xt_quota2: init());
 
 #ifdef CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG
-   nflognl = netlink_kernel_create(init_net, NETLINK_NFLOG,
-   THIS_MODULE, cfg);
+   nflognl = netlink_kernel_create(init_net, NETLINK_NFLOG, cfg);
if (!nflognl)
return -ENOMEM;
 #endif
-- 
1.7.4.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 0/3] Fixing build error with android-3.7

2012-11-15 Thread Tushar Behera 
Following patches are required on android-3.7 branch for the androidized
kernel for Origen to build.

Needs testing on USB gadget functionalities.

Tushar Behera (3):
  usb: gadget: android: Fix build error because of removal of
usb_gadget_controller_number
  usb: gadget: android: Fix build error because of change in composite
driver framework
  netfilter: xt_quota2: Remove extra parameter from
netlink_kernel_create

 drivers/usb/gadget/android.c   |   18 +-
 drivers/usb/gadget/composite.c |5 -
 net/netfilter/xt_quota2.c  |5 +++--
 3 files changed, 12 insertions(+), 16 deletions(-)

-- 
1.7.4.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/3] usb: gadget: android: Fix build error because of change in composite driver framework

2012-11-15 Thread Tushar Behera 
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
 drivers/usb/gadget/android.c   |7 ---
 drivers/usb/gadget/composite.c |5 -
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/android.c b/drivers/usb/gadget/android.c
index c26d7be..2b11055 100644
--- a/drivers/usb/gadget/android.c
+++ b/drivers/usb/gadget/android.c
@@ -1175,6 +1175,7 @@ static struct usb_composite_driver android_usb_driver = {
.name   = android_usb,
.dev= device_desc,
.strings= dev_strings,
+   .bind   = android_bind,
.unbind = android_usb_unbind,
.max_speed  = USB_SPEED_HIGH,
 };
@@ -1291,10 +1292,10 @@ static int __init init(void)
_android_dev = dev;
 
/* Override composite driver functions */
-   composite_driver.setup = android_setup;
-   composite_driver.disconnect = android_disconnect;
+   composite_driver_template.setup = android_setup;
+   composite_driver_template.disconnect = android_disconnect;
 
-   return usb_composite_probe(android_usb_driver, android_bind);
+   return usb_composite_probe(android_usb_driver);
 }
 module_init(init);
 
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 957f973..c4460a5 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1528,8 +1528,11 @@ composite_resume(struct usb_gadget *gadget)
 }
 
 /*-*/
-
+#if IS_ENABLED(CONFIG_USB_G_ANDROID)
+static struct usb_gadget_driver composite_driver_template = {
+#else
 static const struct usb_gadget_driver composite_driver_template = {
+#endif
.bind   = composite_bind,
.unbind = composite_unbind,
 
-- 
1.7.4.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 1/3] usb: gadget: android: Fix build error because of removal of usb_gadget_controller_number

2012-11-15 Thread Tushar Behera 
Required as per commit ed9cbda (usb: gadget: remove
usb_gadget_controller_number()).

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
 drivers/usb/gadget/android.c |   11 +--
 1 files changed, 1 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/android.c b/drivers/usb/gadget/android.c
index d2c3393..c26d7be 100644
--- a/drivers/usb/gadget/android.c
+++ b/drivers/usb/gadget/android.c
@@ -1118,7 +1118,7 @@ static int android_bind(struct usb_composite_dev *cdev)
 {
struct android_dev *dev = _android_dev;
struct usb_gadget   *gadget = cdev-gadget;
-   int gcnum, id, ret;
+   int id, ret;
 
/*
 * Start disconnected. Userspace will connect the gadget once
@@ -1156,15 +1156,6 @@ static int android_bind(struct usb_composite_dev *cdev)
strings_dev[STRING_SERIAL_IDX].id = id;
device_desc.iSerialNumber = id;
 
-   gcnum = usb_gadget_controller_number(gadget);
-   if (gcnum = 0)
-   device_desc.bcdDevice = cpu_to_le16(0x0200 + gcnum);
-   else {
-   pr_warning(%s: controller '%s' not recognized\n,
-   longname, gadget-name);
-   device_desc.bcdDevice = __constant_cpu_to_le16(0x);
-   }
-
usb_gadget_set_selfpowered(gadget);
dev-cdev = cdev;
 
-- 
1.7.4.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Hongbo Zhang 
this is a driver for ST-Ericsson u8500 board(Snowball), with a ARM core inside.
so you should compile like this:
make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- u8500_defconfig
make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage


On 15 November 2012 17:13, Zhang Rui rui.zh...@intel.com wrote:
 On Thu, 2012-11-15 at 16:32 +0800, Hongbo Zhang wrote:
 On 15 November 2012 16:13, Zhang Rui rui.zh...@intel.com wrote:
  On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
  From: hongbo.zhang hongbo.zh...@linaro.com
 
  This driver 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 hongbo.zh...@linaro.com
  Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
  Reviewed-by: Francesco Lavra francescolavra...@gmail.com
 
  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
 
  why is this bool?

 platform specific PRCMU interfaces are used, and those interfaces are
 not exported, so my driver cannot be compiled as a module.

 ok.
 But I still alway get this error message when set DB8500_THERMAL,
 include/linux/mfd/dbx500-prcmu.h:459:19: error: redefinition of
 ‘prcmu_abb_read’
 include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of
 ‘prcmu_abb_read’ was here
 include/linux/mfd/dbx500-prcmu.h:464:19: error: redefinition of
 ‘prcmu_abb_write’
 include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of
 ‘prcmu_abb_write’ was here
 include/linux/mfd/dbx500-prcmu.h:475:19: error: redefinition of
 ‘prcmu_config_clkout’
 include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of
 ‘prcmu_config_clkout’ was here
 include/linux/mfd/dbx500-prcmu.h:537:19: error: redefinition of
 ‘prcmu_ac_wake_req’
 include/linux/mfd/db8500-prcmu.h:683:19: note: previous definition of
 ‘prcmu_ac_wake_req’ was here
 include/linux/mfd/dbx500-prcmu.h:542:20: error: redefinition of
 ‘prcmu_ac_sleep_req’
 include/linux/mfd/db8500-prcmu.h:688:20: note: previous definition of
 ‘prcmu_ac_sleep_req’ was here

 $ grep prcmu_abb_read include/linux/mfd/*
 include/linux/mfd/db8500-prcmu.h:int prcmu_abb_read(u8 slave, u8 reg, u8
 *value, u8 size);
 include/linux/mfd/db8500-prcmu.h:static inline int prcmu_abb_read(u8
 slave, u8 reg, u8 *value, u8 size)
 include/linux/mfd/dbx500-prcmu.h:int prcmu_abb_read(u8 slave, u8 reg, u8
 *value, u8 size);
 include/linux/mfd/dbx500-prcmu.h:static inline int prcmu_abb_read(u8
 slave, u8 reg, u8 *value, u8 size)

 this functions are defined in both db8500-prmcu.h and dbx500-prcmu.h,
 plus linux/mfd/dbx500-prcmu.h includes linux/mfd/db8500-prcmu.h.

 I do not know how it works before, but this is a bug to me.

 thanks,
 rui


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] gpu: ion: Use RB_CLEAR_NODE instead of rb_init_node

2012-11-15 Thread Tushar Behera 
rb_init_node() has been removed from the kernel, use alternate macro.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---

This patch also needs to go into android-3.7 tree.

 drivers/gpu/ion/ion.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c
index 1002ec0..baab410 100644
--- a/drivers/gpu/ion/ion.c
+++ b/drivers/gpu/ion/ion.c
@@ -191,7 +191,7 @@ static struct ion_handle *ion_handle_create(struct 
ion_client *client,
if (!handle)
return ERR_PTR(-ENOMEM);
kref_init(handle-ref);
-   rb_init_node(handle-node);
+   RB_CLEAR_NODE(handle-node);
handle-client = client;
ion_buffer_get(buffer);
handle-buffer = buffer;
-- 
1.7.4.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Viresh Kumar 
On 15 November 2012 14:53, Hongbo Zhang hongbo.zh...@linaro.org wrote:
 this is a driver for ST-Ericsson u8500 board(Snowball), with a ARM core 
 inside.
 so you should compile like this:
 make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- u8500_defconfig
 make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage

Then we must have a DEPENDS_ON in Kconfig entry for these.


--
viresh

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] cpuidle: Measure idle state durations with monotonic clock

2012-11-15 Thread Daniel Lezcano 
On 11/15/2012 02:56 AM, Julius Werner wrote:
 Many cpuidle drivers measure their time spent in an idle state by
 reading the wallclock time before and after idling and calculating the
 difference. This leads to erroneous results when the wallclock time gets
 updated by another processor in the meantime, adding that clock
 adjustment to the idle state's time counter.
 
 If the clock adjustment was negative, the result is even worse due to an
 erroneous cast from int to unsigned long long of the last_residency
 variable. The negative 32 bit integer will zero-extend and result in a
 forward time jump of roughly four billion milliseconds or 1.3 hours on
 the idle state residency counter.
 
 This patch changes all affected cpuidle drivers to either use the
 monotonic clock for their measurements or make use of the generic time
 measurement wrapper in cpuidle.c, which was already working correctly.
 Some superfluous CLIs/STIs in the ACPI code are removed (interrupts
 should always already be disabled before entering the idle function, and
 not get reenabled until the generic wrapper has performed its second
 measurement). It also removes the erroneous cast, making sure that
 negative residency values are applied correctly even though they should
 not appear anymore.
 
 Signed-off-by: Julius Werner jwer...@chromium.org

Tested on a Core 2 Duo (processor_idle driver).

Tested-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org



-- 
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V6 2/2] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.

2012-11-15 Thread hongbo.zhang 
From: hongbo.zhang hongbo.zh...@linaro.com

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 hongbo.zh...@linaro.com
Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Linus Walleij linus.wall...@linaro.org
---
 arch/arm/boot/dts/dbx5x0.dtsi  | 14 +
 arch/arm/boot/dts/snowball.dts | 31 ++
 arch/arm/configs/u8500_defconfig   |  2 ++
 arch/arm/mach-ux500/board-mop500.c | 64 ++
 4 files changed, 111 insertions(+)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 4b0e0ca..731086b 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;
 
@@ -660,5 +668,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 {
+   status = okay;
+   };
};
 };
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index da68454..250625d 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -69,6 +69,8 @@ CONFIG_GPIO_TC3589X=y
 CONFIG_POWER_SUPPLY=y
 CONFIG_AB8500_BM=y
 CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL=y
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
 CONFIG_MFD_STMPE=y
 CONFIG_MFD_TC3589X=y
 CONFIG_AB5500_CORE=y
diff --git a/arch/arm/mach-ux500/board-mop500.c 
b/arch/arm/mach-ux500/board-mop500.c
index 416d436..b03216b 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -16,6 +16,7 @@
 #include linux/io.h
 #include linux/i2c.h
 #include linux/platform_data/i2c-nomadik.h
+#include linux/platform_data/db8500_thermal.h
 #include linux/gpio.h
 #include linux/amba/bus.h
 #include linux/amba/pl022.h
@@ -229,6 +230,67 @@ static struct ab8500_platform_data ab8500_platdata = {
 };
 
 /*
+ * 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,
+   },
+   {
+   .name = IRQ_HOTMON_HIGH,
+   .start  = IRQ_PRCMU_HOTMON_HIGH,
+   .end= IRQ_PRCMU_HOTMON_HIGH,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct db8500_thsens_platform_data db8500_thsens_data = {
+   .trip_points[0] = {
+   .temp = 7,
+   .type = THERMAL_TRIP_ACTIVE,
+   .cdev_name = {
+

[PATCH V6 0/2] Upstream ST-Ericsson thermal driver

2012-11-15 Thread hongbo.zhang 
From: hongbo.zhang hongbo.zh...@linaro.com

V5-V6 Changes:

In patch Thermal: Add ST-Ericsson DB8500 thermal driver:
 - Add depends on ARCH_U8500 in Kconfig

In patch Thermal: Add ST-Ericsson DB8500 thermal properties and platform
 - Add Acked-by: Linus Walleij linus.wall...@linaro.org


hongbo.zhang (2):
  Thermal: Add ST-Ericsson DB8500 thermal driver.
  Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.

 .../devicetree/bindings/thermal/db8500-thermal.txt |  44 ++
 arch/arm/boot/dts/dbx5x0.dtsi  |  14 +
 arch/arm/boot/dts/snowball.dts |  31 ++
 arch/arm/configs/u8500_defconfig   |   2 +
 arch/arm/mach-ux500/board-mop500.c |  64 +++
 drivers/thermal/Kconfig|  20 +
 drivers/thermal/Makefile   |   2 +
 drivers/thermal/db8500_cpufreq_cooling.c   | 108 +
 drivers/thermal/db8500_thermal.c   | 531 +
 include/linux/platform_data/db8500_thermal.h   |  38 ++
 10 files changed, 854 insertions(+)
 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.8.0


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V6 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread hongbo.zhang 
From: hongbo.zhang hongbo.zh...@linaro.com

This driver 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 hongbo.zh...@linaro.com
Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
Reviewed-by: Francesco Lavra francescolavra...@gmail.com
---
 .../devicetree/bindings/thermal/db8500-thermal.txt |  44 ++
 drivers/thermal/Kconfig|  20 +
 drivers/thermal/Makefile   |   2 +
 drivers/thermal/db8500_cpufreq_cooling.c   | 108 +
 drivers/thermal/db8500_thermal.c   | 531 +
 include/linux/platform_data/db8500_thermal.h   |  38 ++
 6 files changed, 743 insertions(+)
 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

diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt 
b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
new file mode 100644
index 000..2e1c06f
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
@@ -0,0 +1,44 @@
+* ST-Ericsson DB8500 Thermal
+
+** Thermal node properties:
+
+- compatible : stericsson,db8500-thermal;
+- reg : address range of the thermal sensor registers;
+- interrupts : interrupts generated from PRCMU;
+- interrupt-names : IRQ_HOTMON_LOW and IRQ_HOTMON_HIGH;
+- num-trips : number of total trip points, this is required, set it 0 if none,
+  if greater than 0, the following properties must be defined;
+- tripN-temp : temperature of trip point N, should be in ascending order;
+- 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, this is required if trip point N is defined, set it 0 if none,
+  otherwise the following cooling device names must be defined;
+- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
+
+Usually the num-trips and tripN-*** are separated 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 = 75000;
+   trip0-type = active;
+   trip0-cdev-num = 1;
+   trip0-cdev-name0 = thermal-cpufreq-0;
+
+   trip1-temp = 8;
+   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/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e1cb6bd..3d28c94 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 ARCH_U8500  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 ARCH_U8500  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

Re: [PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Hongbo Zhang 
On 15 November 2012 18:17, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 15 November 2012 14:53, Hongbo Zhang hongbo.zh...@linaro.org wrote:
 this is a driver for ST-Ericsson u8500 board(Snowball), with a ARM core 
 inside.
 so you should compile like this:
 make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- u8500_defconfig
 make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage

 Then we must have a DEPENDS_ON in Kconfig entry for these.
Sorry for the negligence.
A V6 iteration has been sent out with depends on ARCH_U8500 added.
Thank all of you.


 --
 viresh

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] cpuidle: Measure idle state durations with monotonic clock

2012-11-15 Thread Julius Werner 
Many cpuidle drivers measure their time spent in an idle state by
reading the wallclock time before and after idling and calculating the
difference. This leads to erroneous results when the wallclock time gets
updated by another processor in the meantime, adding that clock
adjustment to the idle state's time counter.

If the clock adjustment was negative, the result is even worse due to an
erroneous cast from int to unsigned long long of the last_residency
variable. The negative 32 bit integer will zero-extend and result in a
forward time jump of roughly four billion milliseconds or 1.3 hours on
the idle state residency counter.

This patch changes all affected cpuidle drivers to either use the
monotonic clock for their measurements or make use of the generic time
measurement wrapper in cpuidle.c, which was already working correctly.
Some superfluous CLIs/STIs in the ACPI code are removed (interrupts
should always already be disabled before entering the idle function, and
not get reenabled until the generic wrapper has performed its second
measurement). It also removes the erroneous cast, making sure that
negative residency values are applied correctly even though they should
not appear anymore.

Signed-off-by: Julius Werner jwer...@chromium.org
---
 arch/powerpc/platforms/pseries/processor_idle.c |4 +-
 drivers/acpi/processor_idle.c   |   57 +-
 drivers/cpuidle/cpuidle.c   |3 +-
 drivers/idle/intel_idle.c   |   14 +-
 4 files changed, 7 insertions(+), 71 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/processor_idle.c 
b/arch/powerpc/platforms/pseries/processor_idle.c
index 45d00e5..4d806b4 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -36,7 +36,7 @@ static struct cpuidle_state *cpuidle_state_table;
 static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
 {
 
-   *kt_before = ktime_get_real();
+   *kt_before = ktime_get();
*in_purr = mfspr(SPRN_PURR);
/*
 * Indicate to the HV that we are idle. Now would be
@@ -50,7 +50,7 @@ static inline  s64 idle_loop_epilog(unsigned long in_purr, 
ktime_t kt_before)
get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
get_lppaca()-idle = 0;
 
-   return ktime_to_us(ktime_sub(ktime_get_real(), kt_before));
+   return ktime_to_us(ktime_sub(ktime_get(), kt_before));
 }
 
 static int snooze_loop(struct cpuidle_device *dev,
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e8086c7..f1a5da4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -735,31 +735,18 @@ static inline void acpi_idle_do_entry(struct 
acpi_processor_cx *cx)
 static int acpi_idle_enter_c1(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
 {
-   ktime_t  kt1, kt2;
-   s64 idle_time;
struct acpi_processor *pr;
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
struct acpi_processor_cx *cx = cpuidle_get_statedata(state_usage);
 
pr = __this_cpu_read(processors);
-   dev-last_residency = 0;
 
if (unlikely(!pr))
return -EINVAL;
 
-   local_irq_disable();
-
-
lapic_timer_state_broadcast(pr, cx, 1);
-   kt1 = ktime_get_real();
acpi_idle_do_entry(cx);
-   kt2 = ktime_get_real();
-   idle_time =  ktime_to_us(ktime_sub(kt2, kt1));
-
-   /* Update device last_residency*/
-   dev-last_residency = (int)idle_time;
 
-   local_irq_enable();
lapic_timer_state_broadcast(pr, cx, 0);
 
return index;
@@ -806,19 +793,12 @@ static int acpi_idle_enter_simple(struct cpuidle_device 
*dev,
struct acpi_processor *pr;
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
struct acpi_processor_cx *cx = cpuidle_get_statedata(state_usage);
-   ktime_t  kt1, kt2;
-   s64 idle_time_ns;
-   s64 idle_time;
 
pr = __this_cpu_read(processors);
-   dev-last_residency = 0;
 
if (unlikely(!pr))
return -EINVAL;
 
-   local_irq_disable();
-
-
if (cx-entry_method != ACPI_CSTATE_FFH) {
current_thread_info()-status = ~TS_POLLING;
/*
@@ -829,7 +809,6 @@ static int acpi_idle_enter_simple(struct cpuidle_device 
*dev,
 
if (unlikely(need_resched())) {
current_thread_info()-status |= TS_POLLING;
-   local_irq_enable();
return -EINVAL;
}
}
@@ -843,22 +822,12 @@ static int acpi_idle_enter_simple(struct cpuidle_device 
*dev,
if (cx-type == ACPI_STATE_C3)
ACPI_FLUSH_CPU_CACHE();
 
-   kt1 = ktime_get_real();
/* Tell the scheduler that we are going deep-idle: */
sched_clock_idle_sleep_event();

Re: [PATCH] mtd: map: Fix compilation warning

2012-11-15 Thread Artem Bityutskiy 
On Mon, 2012-10-29 at 22:47 +0530, Viresh Kumar wrote:
 This patch is an attempt to fix following compilation warning.
 
 In file included from drivers/mtd/chips/cfi_cmdset_0001.c:35:0:
 drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words':
 include/linux/mtd/map.h:331:11: warning: 'r.x[0]' may be used uninitialized 
 in this function [-Wmaybe-uninitialized]
 
 I could have used uninitialized_var() too, but didn't used it as the final 
 else
 part of map_word_load() is missing. So there is a chance that it might be 
 passed
 uninitialized. Better initialize to zero.

Pushed to l2-mtd.git, thanks!

-- 
Best Regards,
Artem Bityutskiy


signature.asc
Description: This is a digitally signed message part
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge

2012-11-15 Thread Rajanikanth HV 


On Saturday 10 November 2012 10:23 PM, Francesco Lavra wrote:
 I don't get the point of declaring the char array and copying the string
 in it, when you could simply use just the pointer returned by
 of_get_property().

 I am considering a corner case where in 'battery-type' property is not
 present and battery is connected.In this case i promote battery to
 UNKNOWN from null.
 
 You could achieve the same result without using the char array, with
 this assignment:
 
 btech = UNKNOWN;
 
 FYI: Further, btemp driver will identify the connected battery based on
 resistance value and decide to use.
 Ref: ab8500_btemp_id(...) ab8500_btemp.c

 Anyway, if the string property is longer than 8 characters, you are
 writing past the size of the destination array.

 i believe it is safe as power_supply.h comprises defines having battery
 technology type in 4 characters length which is normally the case and
 7 chars length being UNKNOWN seldom referred
 
 You should be able to handle whatever the device tree contains, and if
 it contains unexpected data this is not a good excuse for locking up the
 system.
agreed, if we were to go by what device tree contains then explicit
assignment for battery type as UNKNOWN is not required, hence only 2
use case persist as :
a) property name with one of the said value be present
(as per documentation)
b) property name not present

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Jon Medhurst (Tixy) 
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
 On 11/14/2012 07:41 PM, Ryan Harkin wrote:
  On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:
[...]
  Now that the LT branches included in linux-linaro (ll) are based on
  llct, then they could modify the board configs in llct if required for
  the work in their topics. So at the moment, I can't think of a good
  reason not to pub all the board configs into llct. Can anyone else?
 
  I don't know if we need the board configs to be sourced from a single
  repo, or allow board configs to be included in llct from LT trees. One
  central repo means that people know where to go
  
  This seems like the easiest option to me.  Let's do it this way unless
  someone gives a valid objection.
  
  (Unless we had
  an official maintainer to manage all commits to the tree.)
  
  I assume this would have to be Andrey.  Andrey, are you OK with that?
  Or does someone else need to do it?
  
  Each LT that is using LLCT would have to send a patch to get their
  config updated.  So long as this happens in a timely manner, LTs
  should be able to live with that process.
  
 
 I suppose we are talking about the basic board config here. That should
 be ok. The new board enablement config fragments should always go in
 with the respective topic branches.

I agree.

-- 
Tixy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Ryan Harkin 
On 15 November 2012 11:37, Jon Medhurst (Tixy) t...@linaro.org wrote:
 On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
 On 11/14/2012 07:41 PM, Ryan Harkin wrote:
  On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:
 [...]
  Now that the LT branches included in linux-linaro (ll) are based on
  llct, then they could modify the board configs in llct if required for
  the work in their topics. So at the moment, I can't think of a good
  reason not to pub all the board configs into llct. Can anyone else?
 
  I don't know if we need the board configs to be sourced from a single
  repo, or allow board configs to be included in llct from LT trees. One
  central repo means that people know where to go
 
  This seems like the easiest option to me.  Let's do it this way unless
  someone gives a valid objection.
 
  (Unless we had
  an official maintainer to manage all commits to the tree.)
 
  I assume this would have to be Andrey.  Andrey, are you OK with that?
  Or does someone else need to do it?
 
  Each LT that is using LLCT would have to send a patch to get their
  config updated.  So long as this happens in a timely manner, LTs
  should be able to live with that process.
 

 I suppose we are talking about the basic board config here. That should
 be ok. The new board enablement config fragments should always go in
 with the respective topic branches.

 I agree.

OK, can we do it then?  We're freezing for release today, but it's not
a big change, so we can get it in, right?

At some point in the past, Andrey asked:
 My question is if this topic branch would be kernel/configs.git,

Sounds perfect


  config-boards-tracking branch or something else?

I don't have an opinion.  We'll probably have to live with it for a
long time, but as long as it looks sensible, I'm sure people will be
ok...

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Andrey Konovalov 

On 11/15/2012 07:50 AM, Tushar Behera wrote:

On 11/14/2012 07:41 PM, Ryan Harkin wrote:

On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:

Adding linaro-dev list and replying with some comments...
On Tue, 2012-11-13 at 20:20 +0400, Andrey Konovalov wrote:

The llct tree itself has no suitable .conf or defconfig for vexpress at
all. That's the problem (wrt the ci jobs).

The easier way seemed to be a single kernel/configs.git,
config-boards-tracking branch to provide the config fragments for all
the llct jobs.
But it creates several instances of the same board.conf files and adds
confusion. Agreed.
Should we do in the jenkins jobs something like 'git checkout
arm_lt/integration-linaro-vexpress.conf -- linaro/configs/vexpress.conf'
for vexpress and similar (but different and unique) command for the
other boards?


Yes, I see the problem. But getting CI jobs to pull configs direct from
an LT tree seems like the wrong solution. I guess what people really
need is configs in linux-linaro-core-tracking (llct) (I'm sure people
have told me that before and I possibly didn't listen enough).

Now that the LT branches included in linux-linaro (ll) are based on
llct, then they could modify the board configs in llct if required for
the work in their topics. So at the moment, I can't think of a good
reason not to pub all the board configs into llct. Can anyone else?

I don't know if we need the board configs to be sourced from a single
repo, or allow board configs to be included in llct from LT trees. One
central repo means that people know where to go


This seems like the easiest option to me.  Let's do it this way unless
someone gives a valid objection.


(Unless we had
an official maintainer to manage all commits to the tree.)


I assume this would have to be Andrey.  Andrey, are you OK with that?
Or does someone else need to do it?

Each LT that is using LLCT would have to send a patch to get their
config updated.  So long as this happens in a timely manner, LTs
should be able to live with that process.



I suppose we are talking about the basic board config here. That should
be ok. The new board enablement config fragments should always go in
with the respective topic branches.


Yes, only the basic board configs are for LLCT.


Or course, once Linaro's build and test infrastructure supports config
fragments fully, then we could have have separate config fragments for
- basic board config
- new board enablement
- special features (e.g. big.LITTLE MP)
- testing or benchmarking config
and the configs could live in the tree relevant to the code they apply
to rather than having a single central board config we have to manage.


That sounds scarey - there would be no one place to get a config, but
I guess, if you need a config for feature X, you'd also need the
branch for feature X that contained the source and config, so it would
work out fine.

Cheers,
Ryan.

___
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: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Jon Medhurst (Tixy) 
On Thu, 2012-11-15 at 11:37 +, Jon Medhurst (Tixy) wrote:
 On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
  On 11/14/2012 07:41 PM, Ryan Harkin wrote:
   On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:
 [...]
   Now that the LT branches included in linux-linaro (ll) are based on
   llct, then they could modify the board configs in llct if required for
   the work in their topics. So at the moment, I can't think of a good
   reason not to pub all the board configs into llct. Can anyone else?
  
   I don't know if we need the board configs to be sourced from a single
   repo, or allow board configs to be included in llct from LT trees. One
   central repo means that people know where to go
   
   This seems like the easiest option to me.  Let's do it this way unless
   someone gives a valid objection.
   
   (Unless we had
   an official maintainer to manage all commits to the tree.)
   
   I assume this would have to be Andrey.  Andrey, are you OK with that?
   Or does someone else need to do it?
   
   Each LT that is using LLCT would have to send a patch to get their
   config updated.  So long as this happens in a timely manner, LTs
   should be able to live with that process.
   
  
  I suppose we are talking about the basic board config here. That should
  be ok. The new board enablement config fragments should always go in
  with the respective topic branches.
 
 I agree.

Of course, this can't be done until Linaro's CI jobs and Ubuntu kernel
packaging jobs support multiple config fragments, so for now we're stuck
with one config per board. Shall we agree that all of these will live in
the central location of the config-boards-tracking branch of
git://git.linaro.org/kernel/configs.git ?

-- 
Tixy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Andrey Konovalov 

On 11/15/2012 04:01 PM, Ryan Harkin wrote:

On 15 November 2012 11:37, Jon Medhurst (Tixy) t...@linaro.org wrote:

On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:

On 11/14/2012 07:41 PM, Ryan Harkin wrote:

On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:

[...]

Now that the LT branches included in linux-linaro (ll) are based on
llct, then they could modify the board configs in llct if required for
the work in their topics. So at the moment, I can't think of a good
reason not to pub all the board configs into llct. Can anyone else?

I don't know if we need the board configs to be sourced from a single
repo, or allow board configs to be included in llct from LT trees. One
central repo means that people know where to go


This seems like the easiest option to me.  Let's do it this way unless
someone gives a valid objection.


(Unless we had
an official maintainer to manage all commits to the tree.)


I assume this would have to be Andrey.  Andrey, are you OK with that?
Or does someone else need to do it?

Each LT that is using LLCT would have to send a patch to get their
config updated.  So long as this happens in a timely manner, LTs
should be able to live with that process.



I suppose we are talking about the basic board config here. That should
be ok. The new board enablement config fragments should always go in
with the respective topic branches.


I agree.


OK, can we do it then?  We're freezing for release today,


Are we?
https://wiki.linaro.org/Cycles/1211/Release/Calendar?highlight=%28release%29|%2812.11%29


but it's not
a big change, so we can get it in, right?

At some point in the past, Andrey asked:

My question is if this topic branch would be kernel/configs.git,


Sounds perfect



  config-boards-tracking branch or something else?


I don't have an opinion.  We'll probably have to live with it for a
long time, but as long as it looks sensible, I'm sure people will be
ok...

___
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 V6 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

2012-11-15 Thread Zhang Rui 
On Thu, 2012-11-15 at 18:56 +0800, hongbo.zhang wrote:
 From: hongbo.zhang hongbo.zh...@linaro.com
 
 This driver 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 hongbo.zh...@linaro.com
 Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
 Reviewed-by: Francesco Lavra francescolavra...@gmail.com

Patch is refreshed and applied to thermal next.
refreshed patch attached.

From aa1acb0451bb27add173d9641d0b74c58889e693 Mon Sep 17 00:00:00 2001
From: hongbo.zhang hongbo.zh...@linaro.com
Date: Thu, 15 Nov 2012 18:56:42 +0800
Subject: [PATCH 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

This driver 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 hongbo.zh...@linaro.com
Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
Reviewed-by: Francesco Lavra francescolavra...@gmail.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 .../devicetree/bindings/thermal/db8500-thermal.txt |   44 ++
 drivers/thermal/Kconfig|   20 +
 drivers/thermal/Makefile   |2 +
 drivers/thermal/db8500_cpufreq_cooling.c   |  108 
 drivers/thermal/db8500_thermal.c   |  531 
 include/linux/platform_data/db8500_thermal.h   |   38 ++
 6 files changed, 743 insertions(+), 0 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

diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt 
b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
new file mode 100644
index 000..2e1c06f
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
@@ -0,0 +1,44 @@
+* ST-Ericsson DB8500 Thermal
+
+** Thermal node properties:
+
+- compatible : stericsson,db8500-thermal;
+- reg : address range of the thermal sensor registers;
+- interrupts : interrupts generated from PRCMU;
+- interrupt-names : IRQ_HOTMON_LOW and IRQ_HOTMON_HIGH;
+- num-trips : number of total trip points, this is required, set it 0 if none,
+  if greater than 0, the following properties must be defined;
+- tripN-temp : temperature of trip point N, should be in ascending order;
+- 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, this is required if trip point N is defined, set it 0 if none,
+  otherwise the following cooling device names must be defined;
+- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
+
+Usually the num-trips and tripN-*** are separated 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 = 75000;
+   trip0-type = active;
+   trip0-cdev-num = 1;
+   trip0-cdev-name0 = thermal-cpufreq-0;
+
+   trip1-temp = 8;
+   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/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 99b6587..d96da07 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -101,5 +101,25 @@ config EXYNOS_THERMAL
  If you say yes here you get support for TMU (Thermal Managment
  Unit) on SAMSUNG EXYNOS series of SoC.
 
+config DB8500_THERMAL
+   bool DB8500 thermal management
+   depends on ARCH_U8500
+   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
+

Re: [PATCH V6 2/2] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.

2012-11-15 Thread Zhang Rui 
On Thu, 2012-11-15 at 18:56 +0800, hongbo.zhang wrote:
 From: hongbo.zhang hongbo.zh...@linaro.com
 
 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 hongbo.zh...@linaro.com
 Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
 Acked-by: Linus Walleij linus.wall...@linaro.org

applied to thermal next.

thanks,
rui
 ---
  arch/arm/boot/dts/dbx5x0.dtsi  | 14 +
  arch/arm/boot/dts/snowball.dts | 31 ++
  arch/arm/configs/u8500_defconfig   |  2 ++
  arch/arm/mach-ux500/board-mop500.c | 64 
 ++
  4 files changed, 111 insertions(+)
 
 diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
 index 4b0e0ca..731086b 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;
  
 @@ -660,5 +668,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 {
 + status = okay;
 + };
   };
  };
 diff --git a/arch/arm/configs/u8500_defconfig 
 b/arch/arm/configs/u8500_defconfig
 index da68454..250625d 100644
 --- a/arch/arm/configs/u8500_defconfig
 +++ b/arch/arm/configs/u8500_defconfig
 @@ -69,6 +69,8 @@ CONFIG_GPIO_TC3589X=y
  CONFIG_POWER_SUPPLY=y
  CONFIG_AB8500_BM=y
  CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL=y
 +CONFIG_THERMAL=y
 +CONFIG_CPU_THERMAL=y
  CONFIG_MFD_STMPE=y
  CONFIG_MFD_TC3589X=y
  CONFIG_AB5500_CORE=y
 diff --git a/arch/arm/mach-ux500/board-mop500.c 
 b/arch/arm/mach-ux500/board-mop500.c
 index 416d436..b03216b 100644
 --- a/arch/arm/mach-ux500/board-mop500.c
 +++ b/arch/arm/mach-ux500/board-mop500.c
 @@ -16,6 +16,7 @@
  #include linux/io.h
  #include linux/i2c.h
  #include linux/platform_data/i2c-nomadik.h
 +#include linux/platform_data/db8500_thermal.h
  #include linux/gpio.h
  #include linux/amba/bus.h
  #include linux/amba/pl022.h
 @@ -229,6 +230,67 @@ static struct ab8500_platform_data ab8500_platdata = {
  };
  
  /*
 + * 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,
 + },
 + {
 + .name = IRQ_HOTMON_HIGH,
 + .start  = IRQ_PRCMU_HOTMON_HIGH,
 + .end= IRQ_PRCMU_HOTMON_HIGH,
 + .flags  = IORESOURCE_IRQ,
 + },
 +};
 +
 +static struct db8500_thsens_platform_data db8500_thsens_data = {
 + .trip_points[0]

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Ryan Harkin 
On 15 November 2012 12:38, Andrey Konovalov andrey.konova...@linaro.org wrote:
 On 11/15/2012 04:01 PM, Ryan Harkin wrote:
 OK, can we do it then?  We're freezing for release today,


 Are we?
 https://wiki.linaro.org/Cycles/1211/Release/Calendar?highlight=%28release%29|%2812.11%29

Doh!

Looks like I'm a week early... makes a change... ;-)

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[RFC v2 PATCH 1/2] sched: Revert temporary FAIR_GROUP_SCHED dependency for load-tracking

2012-11-15 Thread Preeti U Murthy 
Now that we need the per-entity load tracking for load balancing,
trivially revert the patch which introduced the FAIR_GROUP_SCHED
dependence for load tracking.

Signed-off-by: Preeti U Murthypre...@linux.vnet.ibm.com
---
 include/linux/sched.h |7 +--
 kernel/sched/core.c   |7 +--
 kernel/sched/fair.c   |   12 +---
 kernel/sched/sched.h  |7 ---
 4 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 03be150..087dd20 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1169,12 +1169,7 @@ struct sched_entity {
/* rq owned by this entity/group: */
struct cfs_rq   *my_q;
 #endif
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP)  defined(CONFIG_FAIR_GROUP_SCHED)
+#if defined(CONFIG_SMP)
/* Per-entity load-tracking */
struct sched_avgavg;
 #endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c2e077c..24d8b9b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1526,12 +1526,7 @@ static void __sched_fork(struct task_struct *p)
p-se.vruntime  = 0;
INIT_LIST_HEAD(p-se.group_node);
 
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP)  defined(CONFIG_FAIR_GROUP_SCHED)
+#if defined(CONFIG_SMP)
p-se.avg.runnable_avg_period = 0;
p-se.avg.runnable_avg_sum = 0;
 #endif
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2cebc81..a9cdc8f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1149,8 +1149,7 @@ static inline void update_cfs_shares(struct cfs_rq 
*cfs_rq)
 }
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
-/* Only depends on SMP, FAIR_GROUP_SCHED may be removed when useful in lb */
-#if defined(CONFIG_SMP)  defined(CONFIG_FAIR_GROUP_SCHED)
+#if defined(CONFIG_SMP)
 /*
  * We choose a half-life close to 1 scheduling period.
  * Note: The tables below are dependent on this value.
@@ -3503,12 +3502,6 @@ unlock:
 }
 
 /*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
  * Called immediately before a task is migrated to a new cpu; task_cpu(p) and
  * cfs_rq_of(p) references at time of call are still valid and identify the
  * previous cpu.  However, the caller only guarantees p-pi_lock is held; no
@@ -3531,7 +3524,6 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
atomic64_add(se-avg.load_avg_contrib, cfs_rq-removed_load);
}
 }
-#endif
 #endif /* CONFIG_SMP */
 
 static unsigned long
@@ -6416,9 +6408,7 @@ const struct sched_class fair_sched_class = {
 
 #ifdef CONFIG_SMP
.select_task_rq = select_task_rq_fair,
-#ifdef CONFIG_FAIR_GROUP_SCHED
.migrate_task_rq= migrate_task_rq_fair,
-#endif
.rq_online  = rq_online_fair,
.rq_offline = rq_offline_fair,
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 508e77e..bfd004a 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -226,12 +226,6 @@ struct cfs_rq {
 #endif
 
 #ifdef CONFIG_SMP
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
/*
 * CFS Load tracking
 * Under CFS, load is tracked on a per-entity basis and aggregated up.
@@ -241,7 +235,6 @@ struct cfs_rq {
u64 runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
-#endif /* CONFIG_FAIR_GROUP_SCHED */
 /* These always depend on CONFIG_FAIR_GROUP_SCHED */
 #ifdef CONFIG_FAIR_GROUP_SCHED
u32 tg_runnable_contrib;


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[RFC v2 PATCH 2/2] sched: Use Per-Entity-Load-Tracking metric for load balancing

2012-11-15 Thread Preeti U Murthy 
Currently the load balancer weighs a task based upon its priority,and this
weight consequently gets added up to the weight of the run queue that it is
on.It is this weight of the runqueue that sums up to a sched group's load
which is used to decide the busiest or the idlest group and the runqueue
thereof.

The Per-Entity-Load-Tracking metric however measures how long a task has
been runnable over the duration of its lifetime.This gives us a hint of
the amount of CPU time that the task can demand.This metric takes care of the
task priority as well.Therefore apart from the priority of a task we also
have an idea of the live behavior of the task.This seems to be a more
realistic metric to use to compute task weight which adds upto the run queue
weight and the weight of the sched group.Consequently they can be used for
load balancing.

The semantics of load balancing is left untouched.The two functions
load_balance() and select_task_rq_fair() perform the task of load
balancing.These two paths have been browsed through in this patch to make
necessary changes.

weighted_cpuload() and task_h_load() provide the run queue weight and the
weight of the task respectively.They have been modified to provide the
Per-Entity-Load-Tracking metric as relevant for each.
The rest of the modifications had to be made to suit these two changes.

Completely Fair Scheduler class is the only sched_class which contributes to
the run queue load.Therefore the rq-load.weight==cfs_rq-load.weight when
the cfs_rq is the root cfs_rq (rq-cfs) of the hierarchy.When replacing this
with Per-Entity-Load-Tracking metric,cfs_rq-runnable_load_avg needs to be
used as this is the right reflection of the run queue load when
the cfs_rq is the root cfs_rq (rq-cfs) of the hierarchy.This metric reflects
the percentage uptime of the tasks that are queued on it and hence that 
contribute
to the load.Thus cfs_rq-runnable_load_avg replaces the metric earlier used in
weighted_cpuload().

The task load is aptly captured by se.avg.load_avg_contrib which captures the
runnable time vs the alive time of the task against its priority.This metric
replaces the earlier metric used in task_h_load().

The consequent changes appear as data type changes for the helper variables;
they abound in number.Because cfs_rq-runnable_load_avg needs to be big enough
to capture the tasks' load often and accurately.

The following patch does not consider CONFIG_FAIR_GROUP_SCHED AND
CONFIG_SCHED_NUMA.This is done so as to evaluate this approach starting from the
simplest scenario.Earlier discussions can be found in the link below.

Link: https://lkml.org/lkml/2012/10/25/162
Signed-off-by: Preeti U Murthypre...@linux.vnet.ibm.com
---
 include/linux/sched.h |2 +-
 kernel/sched/core.c   |   12 +
 kernel/sched/fair.c   |   64 +
 kernel/sched/sched.h  |2 +-
 4 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 087dd20..302756e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -924,7 +924,7 @@ struct sched_domain {
unsigned int lb_count[CPU_MAX_IDLE_TYPES];
unsigned int lb_failed[CPU_MAX_IDLE_TYPES];
unsigned int lb_balanced[CPU_MAX_IDLE_TYPES];
-   unsigned int lb_imbalance[CPU_MAX_IDLE_TYPES];
+   u64 lb_imbalance[CPU_MAX_IDLE_TYPES];
unsigned int lb_gained[CPU_MAX_IDLE_TYPES];
unsigned int lb_hot_gained[CPU_MAX_IDLE_TYPES];
unsigned int lb_nobusyg[CPU_MAX_IDLE_TYPES];
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 24d8b9b..4dea057 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2415,8 +2415,8 @@ static const unsigned char
  * would be when CPU is idle and so we just decay the old load without
  * adding any new load.
  */
-static unsigned long
-decay_load_missed(unsigned long load, unsigned long missed_updates, int idx)
+static u64
+decay_load_missed(u64 load, unsigned long missed_updates, int idx)
 {
int j = 0;
 
@@ -2444,7 +2444,7 @@ decay_load_missed(unsigned long load, unsigned long 
missed_updates, int idx)
  * scheduler tick (TICK_NSEC). With tickless idle this will not be called
  * every tick. We fix it up based on jiffies.
  */
-static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
+static void __update_cpu_load(struct rq *this_rq, u64 this_load,
  unsigned long pending_updates)
 {
int i, scale;
@@ -2454,7 +2454,7 @@ static void __update_cpu_load(struct rq *this_rq, 
unsigned long this_load,
/* Update our load: */
this_rq-cpu_load[0] = this_load; /* Fasttrack for idx 0 */
for (i = 1, scale = 2; i  CPU_LOAD_IDX_MAX; i++, scale += scale) {
-   unsigned long old_load, new_load;
+   u64 old_load, new_load;
 
/* scale is effectively 1  i now, and  i divides by scale */
 
@@ -2496,7 +2496,7 @@ static void __update_cpu_load(struct rq

[RFC v2 PATCH 0/2] sched: Integrating Per-entity-load-tracking with the core scheduler

2012-11-15 Thread Preeti U Murthy 
This approach aims to retain the current behavior of load balancer with the
change being only in the metric consumed during load balancing,
without unnecessary introduction of new variables.This RFC has been posted to
evaluate its design;to see if this is the right way to go about introducing
per-entity-load-tracking metric for the consumers of the same; in this
specific case,the load balancer.Once the design has been approved off,I can
go around to testing it.

The patch has been based out of tip-master:HEAD at commit 8a1d31c703d
Subject:Merge branch 'x86/urgent'

Grateful to Peter Zijlstra and Ingo Molnar for their valuable feedback on v1
of the RFC which was the foundation for this version.

PATCH[1/2] Aims at enabling usage of Per-Entity-Load-Tracking for load balacing
PATCH[2/2] The crux of the patchset lies here.
---

Preeti U Murthy (2):
  sched: Revert temporary FAIR_GROUP_SCHED dependency for load-tracking
  sched: Use Per-Entity-Load-Tracking metric for load balancing


 include/linux/sched.h |9 +-
 kernel/sched/core.c   |   19 +---
 kernel/sched/fair.c   |   76 +
 kernel/sched/sched.h  |9 +-
 4 files changed, 43 insertions(+), 70 deletions(-)

-- 
Preeti U Murthy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC v2 PATCH 2/2] sched: Use Per-Entity-Load-Tracking metric for load balancing

2012-11-15 Thread Vincent Guittot 
Hi Preeti,

On 15 November 2012 17:54, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
 Currently the load balancer weighs a task based upon its priority,and this
 weight consequently gets added up to the weight of the run queue that it is
 on.It is this weight of the runqueue that sums up to a sched group's load
 which is used to decide the busiest or the idlest group and the runqueue
 thereof.

 The Per-Entity-Load-Tracking metric however measures how long a task has
 been runnable over the duration of its lifetime.This gives us a hint of
 the amount of CPU time that the task can demand.This metric takes care of the
 task priority as well.Therefore apart from the priority of a task we also
 have an idea of the live behavior of the task.This seems to be a more
 realistic metric to use to compute task weight which adds upto the run queue
 weight and the weight of the sched group.Consequently they can be used for
 load balancing.

 The semantics of load balancing is left untouched.The two functions
 load_balance() and select_task_rq_fair() perform the task of load
 balancing.These two paths have been browsed through in this patch to make
 necessary changes.

 weighted_cpuload() and task_h_load() provide the run queue weight and the
 weight of the task respectively.They have been modified to provide the
 Per-Entity-Load-Tracking metric as relevant for each.
 The rest of the modifications had to be made to suit these two changes.

 Completely Fair Scheduler class is the only sched_class which contributes to
 the run queue load.Therefore the rq-load.weight==cfs_rq-load.weight when
 the cfs_rq is the root cfs_rq (rq-cfs) of the hierarchy.When replacing this
 with Per-Entity-Load-Tracking metric,cfs_rq-runnable_load_avg needs to be
 used as this is the right reflection of the run queue load when
 the cfs_rq is the root cfs_rq (rq-cfs) of the hierarchy.This metric reflects
 the percentage uptime of the tasks that are queued on it and hence that 
 contribute
 to the load.Thus cfs_rq-runnable_load_avg replaces the metric earlier used in
 weighted_cpuload().

 The task load is aptly captured by se.avg.load_avg_contrib which captures the
 runnable time vs the alive time of the task against its priority.This metric
 replaces the earlier metric used in task_h_load().

 The consequent changes appear as data type changes for the helper variables;
 they abound in number.Because cfs_rq-runnable_load_avg needs to be big enough
 to capture the tasks' load often and accurately.

You are now using cfs_rq-runnable_load_avg instead of
cfs_rq-load.weight for calculation of cpu_load but
cfs_rq-runnable_load_avg is smaller or equal to cfs_rq-load.weight
value. This implies that the new value is smaller or equal to the old
statistic so you should be able to keep the same variable width for
the computation of cpu_load


 The following patch does not consider CONFIG_FAIR_GROUP_SCHED AND
 CONFIG_SCHED_NUMA.This is done so as to evaluate this approach starting from 
 the
 simplest scenario.Earlier discussions can be found in the link below.

 Link: https://lkml.org/lkml/2012/10/25/162
 Signed-off-by: Preeti U Murthypre...@linux.vnet.ibm.com
 ---
  include/linux/sched.h |2 +-
  kernel/sched/core.c   |   12 +
  kernel/sched/fair.c   |   64 
 +
  kernel/sched/sched.h  |2 +-
  4 files changed, 40 insertions(+), 40 deletions(-)

 diff --git a/include/linux/sched.h b/include/linux/sched.h
 index 087dd20..302756e 100644
 --- a/include/linux/sched.h
 +++ b/include/linux/sched.h
 @@ -924,7 +924,7 @@ struct sched_domain {
 unsigned int lb_count[CPU_MAX_IDLE_TYPES];
 unsigned int lb_failed[CPU_MAX_IDLE_TYPES];
 unsigned int lb_balanced[CPU_MAX_IDLE_TYPES];
 -   unsigned int lb_imbalance[CPU_MAX_IDLE_TYPES];
 +   u64 lb_imbalance[CPU_MAX_IDLE_TYPES];
 unsigned int lb_gained[CPU_MAX_IDLE_TYPES];
 unsigned int lb_hot_gained[CPU_MAX_IDLE_TYPES];
 unsigned int lb_nobusyg[CPU_MAX_IDLE_TYPES];
 diff --git a/kernel/sched/core.c b/kernel/sched/core.c
 index 24d8b9b..4dea057 100644
 --- a/kernel/sched/core.c
 +++ b/kernel/sched/core.c
 @@ -2415,8 +2415,8 @@ static const unsigned char
   * would be when CPU is idle and so we just decay the old load without
   * adding any new load.
   */
 -static unsigned long
 -decay_load_missed(unsigned long load, unsigned long missed_updates, int idx)
 +static u64
 +decay_load_missed(u64 load, unsigned long missed_updates, int idx)
  {
 int j = 0;

 @@ -2444,7 +2444,7 @@ decay_load_missed(unsigned long load, unsigned long 
 missed_updates, int idx)
   * scheduler tick (TICK_NSEC). With tickless idle this will not be called
   * every tick. We fix it up based on jiffies.
   */
 -static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
 +static void __update_cpu_load(struct rq *this_rq, u64 this_load,
   unsigned long pending_updates)
  {
 int

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Tushar Behera 
On 11/15/2012 06:05 PM, Jon Medhurst (Tixy) wrote:
 On Thu, 2012-11-15 at 11:37 +, Jon Medhurst (Tixy) wrote:
 On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
 On 11/14/2012 07:41 PM, Ryan Harkin wrote:
 On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:
 [...]
 Now that the LT branches included in linux-linaro (ll) are based on
 llct, then they could modify the board configs in llct if required for
 the work in their topics. So at the moment, I can't think of a good
 reason not to pub all the board configs into llct. Can anyone else?

 I don't know if we need the board configs to be sourced from a single
 repo, or allow board configs to be included in llct from LT trees. One
 central repo means that people know where to go

 This seems like the easiest option to me.  Let's do it this way unless
 someone gives a valid objection.

 (Unless we had
 an official maintainer to manage all commits to the tree.)

 I assume this would have to be Andrey.  Andrey, are you OK with that?
 Or does someone else need to do it?

 Each LT that is using LLCT would have to send a patch to get their
 config updated.  So long as this happens in a timely manner, LTs
 should be able to live with that process.


 I suppose we are talking about the basic board config here. That should
 be ok. The new board enablement config fragments should always go in
 with the respective topic branches.

 I agree.
 
 Of course, this can't be done until Linaro's CI jobs and Ubuntu kernel
 packaging jobs support multiple config fragments, so for now we're stuck
 with one config per board. Shall we agree that all of these will live in
 the central location of the config-boards-tracking branch of
 git://git.linaro.org/kernel/configs.git ?
 

Fine with me as long as the basic board config gets pulled into llct. I
will post the Origen patch today.

-- 
Tushar Behera

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)

2012-11-15 Thread Tushar Behera 
On 11/15/2012 05:31 PM, Ryan Harkin wrote:
 On 15 November 2012 11:37, Jon Medhurst (Tixy) t...@linaro.org wrote:
 On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
 On 11/14/2012 07:41 PM, Ryan Harkin wrote:
 On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote:
 [...]
 Now that the LT branches included in linux-linaro (ll) are based on
 llct, then they could modify the board configs in llct if required for
 the work in their topics. So at the moment, I can't think of a good
 reason not to pub all the board configs into llct. Can anyone else?

 I don't know if we need the board configs to be sourced from a single
 repo, or allow board configs to be included in llct from LT trees. One
 central repo means that people know where to go

 This seems like the easiest option to me.  Let's do it this way unless
 someone gives a valid objection.

 (Unless we had
 an official maintainer to manage all commits to the tree.)

 I assume this would have to be Andrey.  Andrey, are you OK with that?
 Or does someone else need to do it?

 Each LT that is using LLCT would have to send a patch to get their
 config updated.  So long as this happens in a timely manner, LTs
 should be able to live with that process.


 I suppose we are talking about the basic board config here. That should
 be ok. The new board enablement config fragments should always go in
 with the respective topic branches.

 I agree.
 
 OK, can we do it then?  We're freezing for release today, but it's not
 a big change, so we can get it in, right?
 
 At some point in the past, Andrey asked:
 My question is if this topic branch would be kernel/configs.git,
 
 Sounds perfect
 
 
  config-boards-tracking branch or something else?
 
 I don't have an opinion.  We'll probably have to live with it for a
 long time, but as long as it looks sensible, I'm sure people will be
 ok...
 

config-boards-tracking branch already has got config fragment for Origen
board, but this config file has enabled all the config options used in
all the topic branches too. If we plan to keep it that way, I suggest to
add the basic board config file to config-core-tracking. (It makes sense
as we would be enabling only mainline components that is essential to
boot the board). Any further modification to these can always be done
through LT topic branches.

Andrey, let me know which way you would prefer the patch?

-- 
Tushar Behera

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Decoding the PTM traces

2012-11-15 Thread Arun KS 
Hello Arve,

On Thu, Nov 15, 2012 at 9:11 AM, Arun KS arunks.li...@gmail.com wrote:
 Hello Arve,

 On Thu, Nov 15, 2012 at 4:55 AM, Arve Hjønnevåg a...@android.com wrote:
 On Wed, Nov 14, 2012 at 6:04 AM, Arun KS arunks.li...@gmail.com wrote:
 Hello,

 I m trying to capture and decode PTM trace from Cortex A9 dual core.

 I m successful  in configuring the driver(arch/arm/kernel/etm.c) and
 setting the funnel to get data in ETB.
 But I don't know how to decode these traces.

 Anyone has any pointers?

 Thanks,
 Arun

 I attached some tools I use to decode the traces. I have used this on
 the A8, A9 and A15. I assume since you cc-ed me you have already
 applied the kernel patches I posted a while back. Without them you
 will not get useful trace data from a dual core processor.

 Thank you very much for the tools. Hope I have taken all your patches.

 Here is how my git log --oneline looks on arch/arm/kernel/etm.c

 75cbaea ARM: etm: Add sysfs entry to enable return stack if supported
 434032a ARM: etm: Add sysfs entry to disable branch_output flag
 c6b1c35 ARM: etm: Add sysfs entry to set context-id-size
 cfb8dc5 ARM: etm: Add sysfs entry to enable timestamps if supported
 d263bc7 ARM: etm: Check arch version and disable data tracing for ptm
 eff62a8 ARM: etm: Wait for etm/ptm(s) to stop before requesting PowerDown
 4246983 ARM: etm: Power down etm(s) when tracing is not enabled
 992cd59 ARM: etm: Support multiple ETMs/PTMs.
 3a91f3e ARM: etm: Return the entire trace buffer if it is empty after reset
 fe05bda ARM: etm: Add some missing locks and error checks
 0c3da53 ARM: etm: Configure data tracing
 d71c695 ARM: etm: Allow range selection
 f13ae47 ARM: etm: Don't try to clear the buffer full status after
 reading the buffer
 8511b5b ARM: etm: Don't limit tracing to only non-secure code.
 d387659 ARM: etm: Don't require clock control
 73017a5 arm: fix implicit module.h users by adding it to arch/arm as required.
 8e88069 ARM: 6838/1: etm: fix section mismatch warning
 aa25afa ARM: amba: make probe() functions take const id tables
 092e0e7 Merge branch 'llseek' of
 git://git.kernel.org/pub/scm/linux/kernel/git/arnd/bkl
 6038f37 llseek: automatically add .llseek fop
 8234eae ARM: 6291/1: coresight: move struct tracectx inside etm driver
 1495cc9 Input: sysrq - drop tty argument from sysrq ops handlers
 988257c ARM: 6294/1: etm: do a dummy read from OSSRR during initialization
 9e354ea ARM: 6292/1: coresight: add ETM management registers
 c5d6c77 ARM: 5841/1: a driver for on-chip ETM and ETB

 I ll let you know the results.

I m able to see decoded ptm traces using the following command,
python3.1 etm-objdump.py --trace-decoder=./etm
--trace-decoder-options=--pft-1.1 --sourceid-match 2 ptm.bin

Thanks,
Arun

 thanks,
 Arun

 --
 Arve Hjønnevåg

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev