diff mbox

[v4,3/5] ARM: topology: Update cpu_power according to DT information

Message ID 1341826026-6504-4-git-send-email-vincent.guittot@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Vincent Guittot July 9, 2012, 9:27 a.m. UTC
Use cpu compatibility field and clock-frequency field of DT to
estimate the capacity of each core of the system and to update
the cpu_power field accordingly.
This patch enables to put more running tasks on big cores than
on LITTLE ones. But this patch doesn't ensure that long running
tasks will run on big cores and short ones on LITTLE cores.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
---
 arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 153 insertions(+)

Comments

Santosh Shilimkar July 9, 2012, 10:55 a.m. UTC | #1
Vincent,
On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system and to update
> the cpu_power field accordingly.
> This patch enables to put more running tasks on big cores than
> on LITTLE ones. But this patch doesn't ensure that long running
> tasks will run on big cores and short ones on LITTLE cores.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
> ---
>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 153 insertions(+)
>
Sorry for not giving this comment on previous version but we should also
have a way to provide the big.LITTLE information without Device Tree.
May be a platform device/data.

I know we are moving DT way, but remember apart from core kernel
infrastructure, to have a complete product build with DT means all the
drivers must be already supporting DT which is not the case with
many huge driver sub-systems like USB, display subsystem, Audio etc.

Having that support would greatly help for the SOC's which have not yet
reached to stage where entire SOC is DT compliant and want to use
big.LITTLE infrastructure.

Regards
Santosh
Peter Zijlstra July 9, 2012, 11 a.m. UTC | #2
On Mon, 2012-07-09 at 16:25 +0530, Shilimkar, Santosh wrote:
> Having that support would greatly help for the SOC's which have not
> yet
> reached to stage where entire SOC is DT compliant and want to use
> big.LITTLE infrastructure. 

Good incentive to get there though.. :-)
Santosh Shilimkar July 9, 2012, 11:04 a.m. UTC | #3
On Mon, Jul 9, 2012 at 4:30 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Mon, 2012-07-09 at 16:25 +0530, Shilimkar, Santosh wrote:
>> Having that support would greatly help for the SOC's which have not
>> yet
>> reached to stage where entire SOC is DT compliant and want to use
>> big.LITTLE infrastructure.
>
> Good incentive to get there though.. :-)

Sure and I guess thats the thought process from
Vincent too :-)

Regards
Santosh
Vincent Guittot July 9, 2012, 12:32 p.m. UTC | #4
On 9 July 2012 12:55, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
> Vincent,
> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
>> Use cpu compatibility field and clock-frequency field of DT to
>> estimate the capacity of each core of the system and to update
>> the cpu_power field accordingly.
>> This patch enables to put more running tasks on big cores than
>> on LITTLE ones. But this patch doesn't ensure that long running
>> tasks will run on big cores and short ones on LITTLE cores.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>> ---
>>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 153 insertions(+)
>>
> Sorry for not giving this comment on previous version but we should also
> have a way to provide the big.LITTLE information without Device Tree.
> May be a platform device/data.

Hi Santosh,

I had thought of adding such additional way to set cpu_power of
big.LITTLE but my conclusion was
-it's a new platform so it should come with DT
-DT is already required by other patches linked to big.LITTLE
(http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html)
-There is no device that can be easily used to get such information at
this early boot stage.

>
> I know we are moving DT way, but remember apart from core kernel
> infrastructure, to have a complete product build with DT means all the
> drivers must be already supporting DT which is not the case with
> many huge driver sub-systems like USB, display subsystem, Audio etc.
>
> Having that support would greatly help for the SOC's which have not yet
> reached to stage where entire SOC is DT compliant and want to use
> big.LITTLE infrastructure.

Can't you support both type of devices on your platform ? You can move
your device to DT mode when it is supported ?

Regards,
Vincent

>
> Regards
> Santosh
Santosh Shilimkar July 9, 2012, 1 p.m. UTC | #5
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
> On 9 July 2012 12:55, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>> Vincent,
>> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
>> <vincent.guittot@linaro.org> wrote:
>>> Use cpu compatibility field and clock-frequency field of DT to
>>> estimate the capacity of each core of the system and to update
>>> the cpu_power field accordingly.
>>> This patch enables to put more running tasks on big cores than
>>> on LITTLE ones. But this patch doesn't ensure that long running
>>> tasks will run on big cores and short ones on LITTLE cores.
>>>
>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>>> ---
>>>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 153 insertions(+)
>>>
>> Sorry for not giving this comment on previous version but we should also
>> have a way to provide the big.LITTLE information without Device Tree.
>> May be a platform device/data.
>
> Hi Santosh,
>
> I had thought of adding such additional way to set cpu_power of
> big.LITTLE but my conclusion was
> -it's a new platform so it should come with DT
> -DT is already required by other patches linked to big.LITTLE
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html)
> -There is no device that can be easily used to get such information at
> this early boot stage.
>
I see. Its new processor but it is just 1 one of the IP in an entire SOC.
As mentioned below I was talking about full SOC support including
all the driver subsystem with DT.

>>
>> I know we are moving DT way, but remember apart from core kernel
>> infrastructure, to have a complete product build with DT means all the
>> drivers must be already supporting DT which is not the case with
>> many huge driver sub-systems like USB, display subsystem, Audio etc.
>>
>> Having that support would greatly help for the SOC's which have not yet
>> reached to stage where entire SOC is DT compliant and want to use
>> big.LITTLE infrastructure.
>
> Can't you support both type of devices on your platform ? You can move
> your device to DT mode when it is supported ?
>
That is what eventually people end up doing who don't have
DT ready for entire SOC. I was trying to ask whether at least some
method is proposed(need not be merged in mainline) to have
the big.LITTLE information parsing without DT.

Regards
Santosh
Vincent Guittot July 9, 2012, 2:36 p.m. UTC | #6
On 9 July 2012 15:00, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
> On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
>> On 9 July 2012 12:55, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>>> Vincent,
>>> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
>>> <vincent.guittot@linaro.org> wrote:
>>>> Use cpu compatibility field and clock-frequency field of DT to
>>>> estimate the capacity of each core of the system and to update
>>>> the cpu_power field accordingly.
>>>> This patch enables to put more running tasks on big cores than
>>>> on LITTLE ones. But this patch doesn't ensure that long running
>>>> tasks will run on big cores and short ones on LITTLE cores.
>>>>
>>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>>> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>>>> ---
>>>>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 153 insertions(+)
>>>>
>>> Sorry for not giving this comment on previous version but we should also
>>> have a way to provide the big.LITTLE information without Device Tree.
>>> May be a platform device/data.
>>
>> Hi Santosh,
>>
>> I had thought of adding such additional way to set cpu_power of
>> big.LITTLE but my conclusion was
>> -it's a new platform so it should come with DT
>> -DT is already required by other patches linked to big.LITTLE
>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html)
>> -There is no device that can be easily used to get such information at
>> this early boot stage.
>>
> I see. Its new processor but it is just 1 one of the IP in an entire SOC.
> As mentioned below I was talking about full SOC support including
> all the driver subsystem with DT.
>
>>>
>>> I know we are moving DT way, but remember apart from core kernel
>>> infrastructure, to have a complete product build with DT means all the
>>> drivers must be already supporting DT which is not the case with
>>> many huge driver sub-systems like USB, display subsystem, Audio etc.
>>>
>>> Having that support would greatly help for the SOC's which have not yet
>>> reached to stage where entire SOC is DT compliant and want to use
>>> big.LITTLE infrastructure.
>>
>> Can't you support both type of devices on your platform ? You can move
>> your device to DT mode when it is supported ?
>>
> That is what eventually people end up doing who don't have
> DT ready for entire SOC. I was trying to ask whether at least some
> method is proposed(need not be merged in mainline) to have
> the big.LITTLE information parsing without DT.

Ok, IIUC, you need a temporary methods, which doesn't need to be
merged in mainline, to set the cpu_scale field ?

>
> Regards
> Santosh
Santosh Shilimkar July 9, 2012, 2:37 p.m. UTC | #7
On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
> On 9 July 2012 15:00, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>> On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
>> <vincent.guittot@linaro.org> wrote:
>>> On 9 July 2012 12:55, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>>>> Vincent,
>>>> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
>>>> <vincent.guittot@linaro.org> wrote:
>>>>> Use cpu compatibility field and clock-frequency field of DT to
>>>>> estimate the capacity of each core of the system and to update
>>>>> the cpu_power field accordingly.
>>>>> This patch enables to put more running tasks on big cores than
>>>>> on LITTLE ones. But this patch doesn't ensure that long running
>>>>> tasks will run on big cores and short ones on LITTLE cores.
>>>>>
>>>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>>>> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>>>>> ---
>>>>>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>>>>>  1 file changed, 153 insertions(+)
>>>>>
>>>> Sorry for not giving this comment on previous version but we should also
>>>> have a way to provide the big.LITTLE information without Device Tree.
>>>> May be a platform device/data.
>>>
>>> Hi Santosh,
>>>
>>> I had thought of adding such additional way to set cpu_power of
>>> big.LITTLE but my conclusion was
>>> -it's a new platform so it should come with DT
>>> -DT is already required by other patches linked to big.LITTLE
>>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html)
>>> -There is no device that can be easily used to get such information at
>>> this early boot stage.
>>>
>> I see. Its new processor but it is just 1 one of the IP in an entire SOC.
>> As mentioned below I was talking about full SOC support including
>> all the driver subsystem with DT.
>>
>>>>
>>>> I know we are moving DT way, but remember apart from core kernel
>>>> infrastructure, to have a complete product build with DT means all the
>>>> drivers must be already supporting DT which is not the case with
>>>> many huge driver sub-systems like USB, display subsystem, Audio etc.
>>>>
>>>> Having that support would greatly help for the SOC's which have not yet
>>>> reached to stage where entire SOC is DT compliant and want to use
>>>> big.LITTLE infrastructure.
>>>
>>> Can't you support both type of devices on your platform ? You can move
>>> your device to DT mode when it is supported ?
>>>
>> That is what eventually people end up doing who don't have
>> DT ready for entire SOC. I was trying to ask whether at least some
>> method is proposed(need not be merged in mainline) to have
>> the big.LITTLE information parsing without DT.
>
> Ok, IIUC, you need a temporary methods, which doesn't need to be
> merged in mainline, to set the cpu_scale field ?
>
Yep.

Regards
Santosh
Vincent Guittot July 9, 2012, 3:10 p.m. UTC | #8
On 9 July 2012 16:37, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
> On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
>> On 9 July 2012 15:00, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>>> On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
>>> <vincent.guittot@linaro.org> wrote:
>>>> On 9 July 2012 12:55, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>>>>> Vincent,
>>>>> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
>>>>> <vincent.guittot@linaro.org> wrote:
>>>>>> Use cpu compatibility field and clock-frequency field of DT to
>>>>>> estimate the capacity of each core of the system and to update
>>>>>> the cpu_power field accordingly.
>>>>>> This patch enables to put more running tasks on big cores than
>>>>>> on LITTLE ones. But this patch doesn't ensure that long running
>>>>>> tasks will run on big cores and short ones on LITTLE cores.
>>>>>>
>>>>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>>>>> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>>>>>> ---
>>>>>>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 153 insertions(+)
>>>>>>
>>>>> Sorry for not giving this comment on previous version but we should also
>>>>> have a way to provide the big.LITTLE information without Device Tree.
>>>>> May be a platform device/data.
>>>>
>>>> Hi Santosh,
>>>>
>>>> I had thought of adding such additional way to set cpu_power of
>>>> big.LITTLE but my conclusion was
>>>> -it's a new platform so it should come with DT
>>>> -DT is already required by other patches linked to big.LITTLE
>>>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html)
>>>> -There is no device that can be easily used to get such information at
>>>> this early boot stage.
>>>>
>>> I see. Its new processor but it is just 1 one of the IP in an entire SOC.
>>> As mentioned below I was talking about full SOC support including
>>> all the driver subsystem with DT.
>>>
>>>>>
>>>>> I know we are moving DT way, but remember apart from core kernel
>>>>> infrastructure, to have a complete product build with DT means all the
>>>>> drivers must be already supporting DT which is not the case with
>>>>> many huge driver sub-systems like USB, display subsystem, Audio etc.
>>>>>
>>>>> Having that support would greatly help for the SOC's which have not yet
>>>>> reached to stage where entire SOC is DT compliant and want to use
>>>>> big.LITTLE infrastructure.
>>>>
>>>> Can't you support both type of devices on your platform ? You can move
>>>> your device to DT mode when it is supported ?
>>>>
>>> That is what eventually people end up doing who don't have
>>> DT ready for entire SOC. I was trying to ask whether at least some
>>> method is proposed(need not be merged in mainline) to have
>>> the big.LITTLE information parsing without DT.
>>
>> Ok, IIUC, you need a temporary methods, which doesn't need to be
>> merged in mainline, to set the cpu_scale field ?
>>
> Yep.

You could use set_power_scale in your platform code to set the
cpu_power of your CPUs until DT is ready for your platform.

Regards,
Vincent

>
> Regards
> Santosh
Santosh Shilimkar July 9, 2012, 3:28 p.m. UTC | #9
On Mon, Jul 9, 2012 at 8:40 PM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
> On 9 July 2012 16:37, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>> On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot
>> <vincent.guittot@linaro.org> wrote:
>>> On 9 July 2012 15:00, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>>>> On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
>>>> <vincent.guittot@linaro.org> wrote:
>>>>> On 9 July 2012 12:55, Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>>>>>> Vincent,
>>>>>> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
>>>>>> <vincent.guittot@linaro.org> wrote:
>>>>>>> Use cpu compatibility field and clock-frequency field of DT to
>>>>>>> estimate the capacity of each core of the system and to update
>>>>>>> the cpu_power field accordingly.
>>>>>>> This patch enables to put more running tasks on big cores than
>>>>>>> on LITTLE ones. But this patch doesn't ensure that long running
>>>>>>> tasks will run on big cores and short ones on LITTLE cores.
>>>>>>>
>>>>>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>>>>>> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>>>>>>> ---
>>>>>>>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>  1 file changed, 153 insertions(+)
>>>>>>>
>>>>>> Sorry for not giving this comment on previous version but we should also
>>>>>> have a way to provide the big.LITTLE information without Device Tree.
>>>>>> May be a platform device/data.
>>>>>
>>>>> Hi Santosh,
>>>>>
>>>>> I had thought of adding such additional way to set cpu_power of
>>>>> big.LITTLE but my conclusion was
>>>>> -it's a new platform so it should come with DT
>>>>> -DT is already required by other patches linked to big.LITTLE
>>>>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html)
>>>>> -There is no device that can be easily used to get such information at
>>>>> this early boot stage.
>>>>>
>>>> I see. Its new processor but it is just 1 one of the IP in an entire SOC.
>>>> As mentioned below I was talking about full SOC support including
>>>> all the driver subsystem with DT.
>>>>
>>>>>>
>>>>>> I know we are moving DT way, but remember apart from core kernel
>>>>>> infrastructure, to have a complete product build with DT means all the
>>>>>> drivers must be already supporting DT which is not the case with
>>>>>> many huge driver sub-systems like USB, display subsystem, Audio etc.
>>>>>>
>>>>>> Having that support would greatly help for the SOC's which have not yet
>>>>>> reached to stage where entire SOC is DT compliant and want to use
>>>>>> big.LITTLE infrastructure.
>>>>>
>>>>> Can't you support both type of devices on your platform ? You can move
>>>>> your device to DT mode when it is supported ?
>>>>>
>>>> That is what eventually people end up doing who don't have
>>>> DT ready for entire SOC. I was trying to ask whether at least some
>>>> method is proposed(need not be merged in mainline) to have
>>>> the big.LITTLE information parsing without DT.
>>>
>>> Ok, IIUC, you need a temporary methods, which doesn't need to be
>>> merged in mainline, to set the cpu_scale field ?
>>>
>> Yep.
>
> You could use set_power_scale in your platform code to set the
> cpu_power of your CPUs until DT is ready for your platform.
>
Thanks for the clarification. Will try that out.

Regards
Santosh
tip-bot for Dave Martin Sept. 13, 2012, 1:03 p.m. UTC | #10
On Mon, Jul 09, 2012 at 11:27:04AM +0200, Vincent Guittot wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system and to update
> the cpu_power field accordingly.
> This patch enables to put more running tasks on big cores than
> on LITTLE ones. But this patch doesn't ensure that long running
> tasks will run on big cores and short ones on LITTLE cores.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
> ---
>  arch/arm/kernel/topology.c |  153 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 153 insertions(+)
> 
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index eb5fc81..198b084 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -17,7 +17,9 @@
>  #include <linux/percpu.h>
>  #include <linux/node.h>
>  #include <linux/nodemask.h>
> +#include <linux/of.h>
>  #include <linux/sched.h>
> +#include <linux/slab.h>
>  
>  #include <asm/cputype.h>
>  #include <asm/topology.h>
> @@ -49,6 +51,152 @@ static void set_power_scale(unsigned int cpu, unsigned long power)
>  	per_cpu(cpu_scale, cpu) = power;
>  }
>  
> +#ifdef CONFIG_OF
> +struct cpu_efficiency {
> +	const char *compatible;
> +	unsigned long efficiency;
> +};
> +
> +/*
> + * Table of relative efficiency of each processors
> + * The efficiency value must fit in 20bit and the final
> + * cpu_scale value must be in the range
> + *   0 < cpu_scale < 3*SCHED_POWER_SCALE/2
> + * in order to return at most 1 when DIV_ROUND_CLOSEST
> + * is used to compute the capacity of a CPU.
> + * Processors that are not defined in the table,
> + * use the default SCHED_POWER_SCALE value for cpu_scale.
> + */
> +struct cpu_efficiency table_efficiency[] = {
> +	{"arm,cortex-a15", 3891},
> +	{"arm,cortex-a7",  2048},
> +	{NULL, },

How accurate would we expect this to be, in general?

How the SoC is integrated will affect things, and throughput is not a
linear function of the clock frequency due to bus and DRAM timing
effects, and so on.

Part of the issue here is that two CPUs can be "compatible" in the DT
sense even when in performance terms there may be significant differences
(different integration options, difference cache sizes, etc.)


If the CPU power estimate doesn't need to be very precise (I suspect it
doesn't?) then then may not be a problem.

Otherwise, could it make sense to put values into the DT itself, or at
least to have the possibility of doing so?

Of course, this can probably be delayed until it proves to be necessary.
Maybe we'll never need it.

Cheers
---Dave

> +};
> +
> +struct cpu_capacity {
> +	unsigned long hwid;
> +	unsigned long capacity;
> +};
> +
> +struct cpu_capacity *cpu_capacity;
> +
> +unsigned long middle_capacity = 1;
> +
> +/*
> + * Iterate all CPUs' descriptor in DT and compute the efficiency
> + * (as per table_efficiency). Also calculate a middle efficiency
> + * as close as possible to  (max{eff_i} - min{eff_i}) / 2
> + * This is later used to scale the cpu_power field such that an
> + * 'average' CPU is of middle power. Also see the comments near
> + * table_efficiency[] and update_cpu_power().
> + */
> +static void __init parse_dt_topology(void)
> +{
> +	struct cpu_efficiency *cpu_eff;
> +	struct device_node *cn = NULL;
> +	unsigned long min_capacity = (unsigned long)(-1);
> +	unsigned long max_capacity = 0;
> +	unsigned long capacity = 0;
> +	int alloc_size, cpu = 0;
> +
> +	alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
> +	cpu_capacity = (struct cpu_capacity *)kzalloc(alloc_size, GFP_NOWAIT);
> +
> +	while ((cn = of_find_node_by_type(cn, "cpu"))) {
> +		const u32 *rate, *reg;
> +		int len;
> +
> +		if (cpu >= num_possible_cpus())
> +			break;
> +
> +		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
> +			if (of_device_is_compatible(cn, cpu_eff->compatible))
> +				break;
> +
> +		if (cpu_eff->compatible == NULL)
> +			continue;
> +
> +		rate = of_get_property(cn, "clock-frequency", &len);
> +		if (!rate || len != 4) {
> +			pr_err("%s missing clock-frequency property\n",
> +				cn->full_name);
> +			continue;
> +		}
> +
> +		reg = of_get_property(cn, "reg", &len);
> +		if (!reg || len != 4) {
> +			pr_err("%s missing reg property\n", cn->full_name);
> +			continue;
> +		}
> +
> +		capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
> +
> +		/* Save min capacity of the system */
> +		if (capacity < min_capacity)
> +			min_capacity = capacity;
> +
> +		/* Save max capacity of the system */
> +		if (capacity > max_capacity)
> +			max_capacity = capacity;
> +
> +		cpu_capacity[cpu].capacity = capacity;
> +		cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
> +	}
> +
> +	if (cpu < num_possible_cpus())
> +		cpu_capacity[cpu].hwid = (unsigned long)(-1);
> +
> +	/* If min and max capacities are equals, we bypass the update of the
> +	 * cpu_scale because all CPUs have the same capacity. Otherwise, we
> +	 * compute a middle_capacity factor that will ensure that the capacity
> +	 * of an 'average' CPU of the system will be as close as possible to
> +	 * SCHED_POWER_SCALE, which is the default value, but with the
> +	 * constraint explained near table_efficiency[].
> +	 */
> +	if (min_capacity == max_capacity)
> +		cpu_capacity[0].hwid = (unsigned long)(-1);
> +	else if (4*max_capacity < (3*(max_capacity + min_capacity)))
> +		middle_capacity = (min_capacity + max_capacity)
> +				>> (SCHED_POWER_SHIFT+1);
> +	else
> +		middle_capacity = ((max_capacity / 3)
> +				>> (SCHED_POWER_SHIFT-1)) + 1;
> +
> +}
> +
> +/*
> + * Look for a customed capacity of a CPU in the cpu_capacity table during the
> + * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
> + * function returns directly for SMP system.
> + */
> +void update_cpu_power(unsigned int cpu, unsigned long hwid)
> +{
> +	unsigned int idx = 0;
> +
> +	/* look for the cpu's hwid in the cpu capacity table */
> +	for (idx = 0; idx < num_possible_cpus(); idx++) {
> +		if (cpu_capacity[idx].hwid == hwid)
> +			break;
> +
> +		if (cpu_capacity[idx].hwid == -1)
> +			return;
> +	}
> +
> +	if (idx == num_possible_cpus())
> +		return;
> +
> +	set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
> +
> +	printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
> +		cpu, arch_scale_freq_power(NULL, cpu));
> +}
> +
> +#else
> +static inline void parse_dt_topology(void) {}
> +static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
> +#endif
> +
> +
>  /*
>   * cpu topology management
>   */
> @@ -62,6 +210,7 @@ static void set_power_scale(unsigned int cpu, unsigned long power)
>   * These masks reflect the current use of the affinity levels.
>   * The affinity level can be up to 16 bits according to ARM ARM
>   */
> +#define MPIDR_HWID_BITMASK 0xFFFFFF
>  
>  #define MPIDR_LEVEL0_MASK 0x3
>  #define MPIDR_LEVEL0_SHIFT 0
> @@ -160,6 +309,8 @@ void store_cpu_topology(unsigned int cpuid)
>  
>  	update_siblings_masks(cpuid);
>  
> +	update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
> +
>  	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
>  		cpuid, cpu_topology[cpuid].thread_id,
>  		cpu_topology[cpuid].core_id,
> @@ -187,4 +338,6 @@ void init_cpu_topology(void)
>  		set_power_scale(cpu, SCHED_POWER_SCALE);
>  	}
>  	smp_wmb();
> +
> +	parse_dt_topology();
>  }
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
diff mbox

Patch

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index eb5fc81..198b084 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -17,7 +17,9 @@ 
 #include <linux/percpu.h>
 #include <linux/node.h>
 #include <linux/nodemask.h>
+#include <linux/of.h>
 #include <linux/sched.h>
+#include <linux/slab.h>
 
 #include <asm/cputype.h>
 #include <asm/topology.h>
@@ -49,6 +51,152 @@  static void set_power_scale(unsigned int cpu, unsigned long power)
 	per_cpu(cpu_scale, cpu) = power;
 }
 
+#ifdef CONFIG_OF
+struct cpu_efficiency {
+	const char *compatible;
+	unsigned long efficiency;
+};
+
+/*
+ * Table of relative efficiency of each processors
+ * The efficiency value must fit in 20bit and the final
+ * cpu_scale value must be in the range
+ *   0 < cpu_scale < 3*SCHED_POWER_SCALE/2
+ * in order to return at most 1 when DIV_ROUND_CLOSEST
+ * is used to compute the capacity of a CPU.
+ * Processors that are not defined in the table,
+ * use the default SCHED_POWER_SCALE value for cpu_scale.
+ */
+struct cpu_efficiency table_efficiency[] = {
+	{"arm,cortex-a15", 3891},
+	{"arm,cortex-a7",  2048},
+	{NULL, },
+};
+
+struct cpu_capacity {
+	unsigned long hwid;
+	unsigned long capacity;
+};
+
+struct cpu_capacity *cpu_capacity;
+
+unsigned long middle_capacity = 1;
+
+/*
+ * Iterate all CPUs' descriptor in DT and compute the efficiency
+ * (as per table_efficiency). Also calculate a middle efficiency
+ * as close as possible to  (max{eff_i} - min{eff_i}) / 2
+ * This is later used to scale the cpu_power field such that an
+ * 'average' CPU is of middle power. Also see the comments near
+ * table_efficiency[] and update_cpu_power().
+ */
+static void __init parse_dt_topology(void)
+{
+	struct cpu_efficiency *cpu_eff;
+	struct device_node *cn = NULL;
+	unsigned long min_capacity = (unsigned long)(-1);
+	unsigned long max_capacity = 0;
+	unsigned long capacity = 0;
+	int alloc_size, cpu = 0;
+
+	alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
+	cpu_capacity = (struct cpu_capacity *)kzalloc(alloc_size, GFP_NOWAIT);
+
+	while ((cn = of_find_node_by_type(cn, "cpu"))) {
+		const u32 *rate, *reg;
+		int len;
+
+		if (cpu >= num_possible_cpus())
+			break;
+
+		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
+			if (of_device_is_compatible(cn, cpu_eff->compatible))
+				break;
+
+		if (cpu_eff->compatible == NULL)
+			continue;
+
+		rate = of_get_property(cn, "clock-frequency", &len);
+		if (!rate || len != 4) {
+			pr_err("%s missing clock-frequency property\n",
+				cn->full_name);
+			continue;
+		}
+
+		reg = of_get_property(cn, "reg", &len);
+		if (!reg || len != 4) {
+			pr_err("%s missing reg property\n", cn->full_name);
+			continue;
+		}
+
+		capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
+
+		/* Save min capacity of the system */
+		if (capacity < min_capacity)
+			min_capacity = capacity;
+
+		/* Save max capacity of the system */
+		if (capacity > max_capacity)
+			max_capacity = capacity;
+
+		cpu_capacity[cpu].capacity = capacity;
+		cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
+	}
+
+	if (cpu < num_possible_cpus())
+		cpu_capacity[cpu].hwid = (unsigned long)(-1);
+
+	/* If min and max capacities are equals, we bypass the update of the
+	 * cpu_scale because all CPUs have the same capacity. Otherwise, we
+	 * compute a middle_capacity factor that will ensure that the capacity
+	 * of an 'average' CPU of the system will be as close as possible to
+	 * SCHED_POWER_SCALE, which is the default value, but with the
+	 * constraint explained near table_efficiency[].
+	 */
+	if (min_capacity == max_capacity)
+		cpu_capacity[0].hwid = (unsigned long)(-1);
+	else if (4*max_capacity < (3*(max_capacity + min_capacity)))
+		middle_capacity = (min_capacity + max_capacity)
+				>> (SCHED_POWER_SHIFT+1);
+	else
+		middle_capacity = ((max_capacity / 3)
+				>> (SCHED_POWER_SHIFT-1)) + 1;
+
+}
+
+/*
+ * Look for a customed capacity of a CPU in the cpu_capacity table during the
+ * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
+ * function returns directly for SMP system.
+ */
+void update_cpu_power(unsigned int cpu, unsigned long hwid)
+{
+	unsigned int idx = 0;
+
+	/* look for the cpu's hwid in the cpu capacity table */
+	for (idx = 0; idx < num_possible_cpus(); idx++) {
+		if (cpu_capacity[idx].hwid == hwid)
+			break;
+
+		if (cpu_capacity[idx].hwid == -1)
+			return;
+	}
+
+	if (idx == num_possible_cpus())
+		return;
+
+	set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
+
+	printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
+		cpu, arch_scale_freq_power(NULL, cpu));
+}
+
+#else
+static inline void parse_dt_topology(void) {}
+static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
+#endif
+
+
 /*
  * cpu topology management
  */
@@ -62,6 +210,7 @@  static void set_power_scale(unsigned int cpu, unsigned long power)
  * These masks reflect the current use of the affinity levels.
  * The affinity level can be up to 16 bits according to ARM ARM
  */
+#define MPIDR_HWID_BITMASK 0xFFFFFF
 
 #define MPIDR_LEVEL0_MASK 0x3
 #define MPIDR_LEVEL0_SHIFT 0
@@ -160,6 +309,8 @@  void store_cpu_topology(unsigned int cpuid)
 
 	update_siblings_masks(cpuid);
 
+	update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
+
 	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
 		cpuid, cpu_topology[cpuid].thread_id,
 		cpu_topology[cpuid].core_id,
@@ -187,4 +338,6 @@  void init_cpu_topology(void)
 		set_power_scale(cpu, SCHED_POWER_SCALE);
 	}
 	smp_wmb();
+
+	parse_dt_topology();
 }