Re: [RFC 3/6] sched: pack small tasks

2012-11-09 Thread Morten Rasmussen 
Hi Vincent,

I have experienced suboptimal buddy selection on a dual cluster setup
(ARM TC2) if SD_SHARE_POWERLINE is enabled at MC level and disabled at
CPU level. This seems to be the correct flag settings for a system with
only cluster level power gating.

To me it looks like update_packing_domain() is not doing the right
thing. See inline comments below.

On Sun, Oct 07, 2012 at 08:43:55AM +0100, 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 |
> 
> Small tasks tend to slip out of the periodic load balance.
> The best place to choose to migrate them is at their wake up.
> 
> 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
> + * 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 */
> +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;
sd is the highest level where SD_SHARE_POWERLINE is enabled so the sched
groups of the parent level would represent the power domains. If get it
right, we want to pack inside the cluster first and only let first cpu
of the cluster do packing on another cluster. So all cpus - except the
first one - in the current sched domain should find its buddy within the
domain and only the first one should go to the parent sched domain to
find its buddy.

I propose the following fix:

-   sd = sd->parent;
+   if (cpumask_first(sched_domain_span(sd)) == cpu
+   || !sd->parent)
+   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));

There is no guarantee that id is in the sched group pointed to by
sd->groups, which is implicitly assumed later in the search loop. We
need to find the sched group that contains id and point sg to that
instead. I haven't found an elegant way to find that group, but the fix
below should at least give the right result.

+   /* Find sched group of candidate */
+   tmp = sd->groups;
+   do {
+   if (cpumask_test_cpu(id, sched_group_cpus(tmp)))
+   {
+   sg = tmp;
+   break;
+   }
+   } while (tmp = tmp->next, tmp != sd->groups);
+
+   pack = sg;
+   tmp = sg->next;

Regards,
Morten

> +
> + /* 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_

Re: [RFC 3/6] sched: pack small tasks

2012-11-09 Thread Morten Rasmussen 
On Fri, Nov 02, 2012 at 10:53:47AM +, Santosh Shilimkar wrote:
> On Monday 29 October 2012 06:42 PM, Vincent Guittot wrote:
> > On 24 October 2012 17:20, Santosh Shilimkar  
> > wrote:
> >> 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 ?
> >
> > No it's not a typo.
> > The system packs at each scheduling level. It starts to pack in
> > cluster because each core can power gate independently so CPU1 tries
> > to pack its tasks in CPU0 and CPU3 in CPU2. Then, it packs at CPU
> > level so CPU2 tries to pack in the cluster of CPU0 and CPU0 packs in
> > itself
> >
> I get it. Though in above example a task may migrate from say
> CPU3->CPU2->CPU0 as part of packing. I was just thinking whether
> moving such task from say CPU3 to CPU0 might be best instead.

To me it seems suboptimal to pack the task twice, but the alternative is
not good either. If you try to move the task directly to CPU0 you may
miss packing opportunities if CPU0 is already busy, while CPU2 might
have enough capacity to take it. It would probably be better to check
the business of CPU0 and then back off and try CPU2 if CP0 is busy. This
would require a buddy list for each CPU rather just a single buddy and
thus might become expensive.

> 
> >>
> >>> 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.
> >
> > Can I ask you which configuration you have used ? how many cores and
> > cluster ?  Can they be power gated independently ?
> >
> I have been trying with couple of setups. Dual Core ARM machine and
> Quad core X86 box with single package thought most of the mobile
> workload analysis I was doing on ARM machine. On both setups
> CPUs can be gated independently.
> 
> >>
> >>
> >>> 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
> >
> > yes
> >
> >>
> >>> + * 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..
> >> /*
> >>   *
> >>   */
> >>
> >
> > yes
> >
> >> Can you please expand the why the assumption is right ?
> >> "it doesn't wort to pack on CPU that share the same powerline"
> >
> > By "share the same power-line", I mean that the CPUs can't power off
> > independently. So if some CPUs can't power off independently, it's
> > worth to try to use most of them to race to idle.
> >
> In that case I suggest we use different word here. Power line can be
> treated as voltage line, power domain.
> May be SD_SHARE_CPU_POWERDOMAIN ?
> 

How about just SD_SHARE_POWERDOMAIN ?

> >>
> >> Think about a scenario

Re: Support for Raspberry Pi

2012-11-09 Thread Al Stone 

On 11/03/2012 10:09 AM, Loïc Minier wrote:

 Hi Geert,

On Fri, Nov 02, 2012, Geert Schuring wrote:

Could you tell me if you have any plans to enable Ubuntu on the Raspberry Pi
(ARMv6) ?


Short answer: an Ubuntu ARMv6 port for the Raspberry Pi isn't a Linaro
target, but we're taking patches and we're interested in some bugs!  :-)

There are two main reasons for that:
- Linaro doesn't have the capacity to do large scale distro ports, this
   is usually mainly the job of distros, and we're sometimes giving a
   hand
- Linaro is all about the future of ARM, so the focus is mainly on ARMv7
   and ARMv8 at this point

That said, there is hope!  First, a bunch of Linaro folks have a
Raspberry Pi and play with it; second, I believe Ubuntu's armel port is
being re-targeted to ARMv5, so Ubuntu armel binaries should eventually
run on the Pi.

Linaro does directly care about toolchain regressions you might
encounter on ARMv5/ARMv6 (or even on x86), so please do report us any
toolchain regressions caused by Linaro patches.

  Cheers,



As far as distros go, there's also a Fedora 17 remix for the
Raspberry Pi:

   http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix

Works pretty nicely on my Pi.  It's not the Linaro toolchain per se,
but just like Loic says, any toolchain regressions are of interest
to all of us -- improving Linux on ARM is the point of the exercise.

--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---

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

Re: Linaro Website Contact

2012-11-09 Thread Amber Graner 
Dear Yamil,

Thank you so much for your interest in Linaro.  I am forwarding your
question to our DevPlatform team Tech Lead, Ricardo Salveti and I am also
CC'ing our Linaro Dev mailing list.

Ricardo and those on the mailing listing list, thank you in advance for any
assistance that you can give Yamil.

Yamil other helpful resources should you have future questions are our
mailing lists and IRC channels:

http://www.linaro.org/engineering/mailing-lists
http://www.linaro.org/engineering/getting-started/discuss#tab2

You can also find other helpful support and discussion channels on the
Linaro Website at:

http://www.linaro.org/engineering/getting-started/discuss

Again thank you for your interest in Linaro and I hope you find these
resources helpful.

Please feel free to let me know if there is anything else I can assist you
with in regards to Linaro Technical Resources or Getting Started in the
Linaro Community.

All the best,
Amber Graner

On 9 November 2012 13:48, Linaro Content Management System <
lin...@freshleafmedia.co.uk> wrote:

> **
>Linaro Website Form Submission - *Contact Form*
> A user has submitted the following information on the Linaro website:
>
>  Name Yamil Garcia  Email ygar...@imagikcorp.com  Message I'm using a
> i.MX6Q Sabre Lite Board running a kernel and rootfs from
> linaro-12.09(Ubuntu-12.04) release. I would like to cross compile Qt
> applications for this board, could you guys give me a hint on this? I've
> been trying without successs. Thanks for your support.  Form Url
> http://www.linaro.org/contact
>
> This enquiry was received via the *Contact Form* on the website:
> http://www.linaro.org/contact
>
> Thank you,
>
> Linaro
>



-- 

Amber Graner

User Experience and Community Specialist



Linaro.org * **│ *Open source software for ARM SoCs*
***

Follow *Linaro: *Facebook  |
Twitter
 | Blog 


*+1.828.582.9469* cell
*+1.828.395.1049* office

irc: akgraner
amber.gra...@linaro.org  (email and Google chat)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V3 3/5] Thermal: Remove the cooling_cpufreq_list.

2012-11-09 Thread Hongbo Zhang 
On 7 November 2012 14:54, Zhang Rui  wrote:
> On Tue, 2012-10-30 at 17:48 +0100, hongbo.zhang wrote:
>> 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 
>> Reviewed-by: Francesco Lavra 
>> Reviewed-by: Amit Daniel Kachhap 
>
> applied to thermal-next.
Thanks.
I have sent the other updated 4/5 5/5 patches with Reviewed-by added
in a new thread, please have a look there.

>
> thanks,
> rui
>
>> ---
>>  drivers/thermal/cpu_cooling.c | 91 
>> +--
>>  1 file changed, 19 insertions(+), 72 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index bfd62b7..392d57d 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
>> @@ -240,28 +241,18 @@ static int cpufreq_thermal_notifier(struct 
>> notifier_block *nb,
>>  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 cpumask *maskPtr;
>> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>> + struct cpumask *maskPtr = &cpufreq_device->allowed_cpus;
>>   unsigned int cpu;
>>   struct cpufreq_frequency_table *table;
>>   unsigned long count = 0;
>> + int i = 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);
>>   if (!table) {
>>   *state = 0;
>> - ret = 0;
>> - goto return_get_max_state;
>> + return 0;
>>   }
>>
>>   for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> @@ -272,12 +263,10 @@ static int cpufreq_get_max_state(struct 
>> thermal_cooling_device *cdev,
>>
>>   if (count > 0) {
>>   *state = --count;
>> - ret = 0;
>> + return 0;
>>   }
>>
>> -return_get_max_state:
>> - mutex_unlock(&cooling_cpufreq_lock);
>> - return ret;
>> + return -EINVAL;
>>  }
>>
>>  /**
>> @@ -288,20 +277,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;
>> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>>
>> - 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);
>> -
>> - return ret;
>> + *state = cpufreq_device->cpufreq_state;
>> + return 0;
>>  }
>>
>>  /**
>> @@ -312,22 +291,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;
>> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>>
>> - 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);
>> -
>> - mutex_unlock(&cooling_cpufreq_lock);
>> -
>> - return ret;
>> + return cpufreq_apply_cooling(cpufreq_device, state);
>>  }
>>
>>  /* Bind cpufreq callbacks to thermal cooling dev

Re: [PATCH V5 0/2] Upstream ST-Ericsson thermal driver

2012-11-09 Thread Hongbo Zhang 
Hi Rui Zhang,
Please have a look at this patch set.
Since the previous 1/5, 2/5, 3/5 have been accepted, I'd like to send
these last two updated patches with Reviewed-by added in this new
thread.

Thanks.

On 9 November 2012 19:29, hongbo.zhang  wrote:
> From: "hongbo.zhang" 
>
> V4->V5 Changes:
>
> In patch "Thermal: Add ST-Ericsson DB8500 thermal driver":
>  - use flush_work instead of flush_work_sync since the later is deprecated 
> now.
>  - parameter trip_points of db8500_thermal_match_cdev is renamed to 
> trip_point;
>  - re-order oprerations in function db8500_thermal_update_config;
>
> 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.7.11.3
>

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

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

2012-11-09 Thread hongbo.zhang 
From: "hongbo.zhang" 

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 
Reviewed-by: Viresh Kumar 
Reviewed-by: Francesco Lavra 
---
 .../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..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

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

2012-11-09 Thread hongbo.zhang 
From: "hongbo.zhang" 

V4->V5 Changes:

In patch "Thermal: Add ST-Ericsson DB8500 thermal driver":
 - use flush_work instead of flush_work_sync since the later is deprecated now.
 - parameter trip_points of db8500_thermal_match_cdev is renamed to trip_point;
 - re-order oprerations in function db8500_thermal_update_config;

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.7.11.3


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

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

2012-11-09 Thread hongbo.zhang 
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 
Reviewed-by: Viresh Kumar 
---
 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 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -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 = {
+   [0] = "thermal-cpufreq-0",
+   },
+   },
+   .trip_points[1] = {
+   .temp = 75000,
+   .type = THERMAL_TRIP_ACTIVE,

Re: Support for Raspberry Pi

2012-11-09 Thread Matthias Klose 

Am 03.11.2012 17:09, schrieb Loïc Minier:

That said, there is hope!  First, a bunch of Linaro folks have a
Raspberry Pi and play with it; second, I believe Ubuntu's armel port is
being re-targeted to ARMv5, so Ubuntu armel binaries should eventually
run on the Pi.


yes, for 12.10. armel is now obsolete for 13.04.


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