[PATCH] cpufreq: core: Fix typo in comment describing show_bios_limit()
show_bios_limit is mistakenly written as show_scaling_driver in a comment
describing purpose of show_bios_limit() routine.
Fix it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fb8a527..021973b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -581,7 +581,7 @@ static ssize_t show_scaling_setspeed(struct cpufreq_policy
*policy, char *buf)
}
/**
- * show_scaling_driver - show the current cpufreq HW/BIOS limitation
+ * show_bios_limit - show the current cpufreq HW/BIOS limitation
*/
static ssize_t show_bios_limit(struct cpufreq_policy *policy, char *buf)
{
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be =15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c
b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver = {
.target = vexpress_cpufreq_set_target,
.get= vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = cpufreq_vexpress,
+ .name = vexpress-bL,
.attr = vexpress_cpufreq_attr,
};
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On 09/10/12 08:10, Viresh Kumar wrote:
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be =15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c
b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver = {
.target = vexpress_cpufreq_set_target,
.get= vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = cpufreq_vexpress,
+ .name = vexpress-bL,
.attr = vexpress_cpufreq_attr,
};
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On Tue, 2012-10-09 at 09:27 +0100, Sudeep KarkadaNagesha wrote:
On 09/10/12 08:10, Viresh Kumar wrote:
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be =15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Shall I apply this to the ARM Landing Team vexpress tree then?
--
Tixy
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c
b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver = {
.target = vexpress_cpufreq_set_target,
.get= vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = cpufreq_vexpress,
+ .name = vexpress-bL,
.attr = vexpress_cpufreq_attr,
};
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On Tue, Oct 9, 2012 at 2:13 PM, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2012-10-09 at 09:27 +0100, Sudeep KarkadaNagesha wrote:
On 09/10/12 08:10, Viresh Kumar wrote:
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be =15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed
properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Shall I apply this to the ARM Landing Team vexpress tree then?
I'd say yes, the driver lives in your tree. I'm not sure how you
coordinate the code drops with ARM since it should be in their tree as
well for the future.
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c
b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver =
{
.target = vexpress_cpufreq_set_target,
.get= vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = cpufreq_vexpress,
+ .name = vexpress-bL,
.attr = vexpress_cpufreq_attr,
};
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On 09/10/12 11:33, Amit Kucheria wrote:
On Tue, Oct 9, 2012 at 2:13 PM, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2012-10-09 at 09:27 +0100, Sudeep KarkadaNagesha wrote:
On 09/10/12 08:10, Viresh Kumar wrote:
Following is the declaration of name field in struct cpufreq_driver:
char name[CPUFREQ_NAME_LEN];
where CPUFREQ_NAME_LEN is 16.
So, length of drivers name must be =15 (one position for '\0').
Current name is crossing this limit and so name doesn't get printed properly
when we do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
This patch renames driver-name to fix this issue.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Shall I apply this to the ARM Landing Team vexpress tree then?
I'd say yes, the driver lives in your tree. I'm not sure how you
coordinate the code drops with ARM since it should be in their tree as
well for the future.
Robin raised a valid point that this driver is TC2 specific and bL is
not appropriate name for it including the file name(my bad choice at first).
---
drivers/cpufreq/vexpress_bL_cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c
b/drivers/cpufreq/vexpress_bL_cpufreq.c
index 8b7ec18..541fc40 100644
--- a/drivers/cpufreq/vexpress_bL_cpufreq.c
+++ b/drivers/cpufreq/vexpress_bL_cpufreq.c
@@ -244,7 +244,7 @@ static struct cpufreq_driver vexpress_cpufreq_driver = {
.target = vexpress_cpufreq_set_target,
.get= vexpress_cpufreq_get,
.init = vexpress_cpufreq_init,
- .name = cpufreq_vexpress,
+ .name = vexpress-bL,
.attr = vexpress_cpufreq_attr,
};
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On 9 October 2012 16:24, Pawel Moll pawel.m...@arm.com wrote: On Tue, 2012-10-09 at 11:42 +0100, Sudeep KarkadaNagesha wrote: Robin raised a valid point that this driver is TC2 specific and bL is not appropriate name for it including the file name(my bad choice at first). Just to be painfully precise ;-) I must say it's not TC2 specific, but V2P-CA15_A7 specific. TC2 == Test Chip 2, also known as Garuda. The SPC that the driver talks to is _not_ a part of the TC2, it's a separate component of the V2P-CA15_A7 core tile (HBI0249). Why is it CA15_A7 specific? It looks to me like a simple cpufreq driver for vexpress board, that may support any coretile... Single cluster, multicluster (big LITTLE or otherwise)... What's in there for CA15 or A7 ? -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On Tue, 2012-10-09 at 12:34 +0100, Viresh Kumar wrote: On 9 October 2012 16:24, Pawel Moll pawel.m...@arm.com wrote: On Tue, 2012-10-09 at 11:42 +0100, Sudeep KarkadaNagesha wrote: Robin raised a valid point that this driver is TC2 specific and bL is not appropriate name for it including the file name(my bad choice at first). Just to be painfully precise ;-) I must say it's not TC2 specific, but V2P-CA15_A7 specific. TC2 == Test Chip 2, also known as Garuda. The SPC that the driver talks to is _not_ a part of the TC2, it's a separate component of the V2P-CA15_A7 core tile (HBI0249). Why is it CA15_A7 specific? It looks to me like a simple cpufreq driver for vexpress board, that may support any coretile... Single cluster, multicluster (big LITTLE or otherwise)... What's in there for CA15 or A7 ? It's not about A15 or A7, but about V2P-CA15_A7 ;-) That's what the TC2 core tile is officially called. The driver talks to firmware running on the microcontroller on the tile. No other VE tile (so far) has similar interface available, so it is specific for this particular core tile. Now, _if_ some of future boards share the same interface for the power management firmware (and the _if_ is a big _IF_ ;-), it still wouldn't be TC2-specific (because the future boards will not use TC2). So maybe we want to call it something like vexpress-spc (or whatever three letter acronym we use here ;-) and hope for the best? Paweł ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/3] bootwrapper: Add support for big.LITTLE models
On 8 October 2012 14:59, Jon Medhurst (Tixy) t...@linaro.org wrote: This mostly boils down to initialising the Cache Coherent Interconnect (CCI). We do this by looking in the device-tree for a CCI node, that way the same semihosting bootwrapper binary can be used on both the big.LITTLE models and on the A15 models which don't have a CCI. Changes sinces v1: - Added in-source comment to configure_from_fdt() - Reworded commit message for patch 2 [PATCH v2 1/3] bootwrapper: Allow for multiple clusters in boot CPU [PATCH v2 2/3] bootwrapper: Factor out parsing of fdt #address-cells [PATCH v2 3/3] bootwrapper: Initialise CCI device if found in the All: Reviewed-by: Peter Maydell peter.mayd...@linaro.org and tested that the KVM boot is still OK. Patch 2 made git complain about trailing whitespace in one place but I'll just zap that in passing when I apply these. Dave, unless you have any further review comments I propose to apply these Wednesday. thanks -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] bootwrapper: Factor out parsing of fdt #address-cells and #size-cells
On Mon, Oct 08, 2012 at 02:59:18PM +0100, Jon Medhurst (Tixy) wrote:
From: Jon Medhurst t...@linaro.org
A subsequent patch will also need to obtain address-cells and
size-cells, so lets factor out this code into a handy function.
The code looks ok. There are a couple of stylistic things that could be
tweaked, but it's not a big issue.
Cheers
---Dave
Signed-off-by: Jon Medhurst t...@linaro.org
---
semi_loader.c | 56 ++--
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/semi_loader.c b/semi_loader.c
index cbe911c..c9750be 100644
--- a/semi_loader.c
+++ b/semi_loader.c
@@ -97,6 +97,39 @@ static int _fdt_make_node(void *fdt, int parentoffset,
const char *name)
return fdt_add_subnode(fdt, parentoffset, name);
}
+static void _fdt_address_and_size_cells(void *fdt, int* addrcells, int*
sizecells)
Minor quibble: the rest of the code uses the type *decl spacing, not
type* decl.
+{
+ int e;
+ uint32_t const *p;
+
+ if(!(p = fdt_getprop(fdt, 0, #address-cells, e)))
+ goto libfdt_error;
+ else if(e != 4)
+ goto size_error;
Another minor quibble: this could be simplified slightly by dropping any
else which directly follows a goto.
(The superfluous elses were in the original code too, though.)
+ *addrcells = fdt32_to_cpu(*p);
+ if(!(p = fdt_getprop(fdt, 0, #size-cells, e)))
+ goto libfdt_error;
+ else if(e != 4)
+ goto size_error;
+ *sizecells = fdt32_to_cpu(*p);
+
+ /*
+ * Sanity-check address sizes, since addresses and sizes which do
+ * not take up exactly 4 or 8 bytes are not supported.
+ */
+ if ((*addrcells != 1 *addrcells != 2) ||
+ (*sizecells != 1 *sizecells != 2))
+ goto size_error;
+
+ return;
+
+libfdt_error:
+ fatal(libfdt: , fdt_strerror(e), , while looking for
#address-cells/#size-cells\n);
+
+size_error:
+ fatal(Unexpected/invalid #address-cells/#size-cells in device tree\n);
+}
+
static void update_fdt(void **dest, struct loader_info *info)
{
int e;
@@ -112,25 +145,7 @@ static void update_fdt(void **dest, struct loader_info
*info)
if((e = fdt_open_into((void *)info-fdt_start, fdt, FDT_SIZE_MAX)) 0)
goto libfdt_error;
- /*
- * Sanity-check address sizes, since addresses and sizes which do
- * not take up exactly 4 or 8 bytes are not supported.
- */
- {
- if(!(p = fdt_getprop(fdt, 0, #address-cells, e)))
- goto libfdt_error;
- else if(e != 4)
- goto size_error;
- addrcells = fdt32_to_cpu(*p);
- if(!(p = fdt_getprop(fdt, 0, #size-cells, e)))
- goto libfdt_error;
- else if(e != 4)
- goto size_error;
- sizecells = fdt32_to_cpu(*p);
- if ((addrcells != 1 addrcells != 2) ||
- (sizecells != 1 sizecells != 2))
- goto size_error;
- }
+ _fdt_address_and_size_cells(fdt, addrcells, sizecells);
/*
* Add a memory node, but only if there isn't one already. If
@@ -225,9 +240,6 @@ no_add_memory:
libfdt_error:
fatal(libfdt: , fdt_strerror(e), , while updating device tree\n);
-
-size_error:
- fatal(Unexpected/invalid #address-cells/#size-cells in device tree\n);
}
static int is_space(char c)
--
1.7.10.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 3/3] bootwrapper: Initialise CCI device if found in the fdt
On Mon, Oct 08, 2012 at 02:59:19PM +0100, Jon Medhurst (Tixy) wrote:
From: Jon Medhurst t...@linaro.org
The A15xA7 models simulate a Cache Coherent Interconnect (CCI) and this
needs to be initialised correctly for Linux to boot.
To perform this initiation we add the new function configure_from_fdt()
which will look in the fdt for devices to initialise. In this first case
we look for the CCI node and if found then setup this device.
Acked-by: Dave Martin dave.mar...@linaro.org
(Commentary below, but the patch looks OK to me.)
Signed-off-by: Jon Medhurst t...@linaro.org
---
semi_loader.c | 57
+
1 file changed, 57 insertions(+)
diff --git a/semi_loader.c b/semi_loader.c
index c9750be..b0c064c 100644
--- a/semi_loader.c
+++ b/semi_loader.c
@@ -242,6 +242,61 @@ libfdt_error:
fatal(libfdt: , fdt_strerror(e), , while updating device tree\n);
}
+/* For accessing 32-bit device ports */
+#define io32(p) (*(volatile uint32_t *)(p))
I had a vague memory of something like this already existing somewhere,
but I think I may be confusing this with another codebase.
+
+static void init_cci(unsigned cci)
+{
+ info(Initialising CCI\n);
+
+ /*
+ * Ideally, the CCI device tree binding would include suitable
+ * information so we can correctly configure the CCI, but for
+ * now we'll just hard-code settings for the present A15xA7
+ * models.
+ */
+
+ /* Turn on CCI snoops and DVM messages */
+ io32(cci+0x4000) = 0x3; /* A15 cluster */
+ io32(cci+0x5000) = 0x3; /* A7 cluster */
We may want to be more sophisticated about this at some point, but
this is a sensible compromise for now.
There is no official CCI binding yet, but this code makes reasonable-
looking, minimal assumptions about its final form.
+
+ /* Wait while change pending bit of status register is set */
+ while(io32(cci+0xc) 0x1)
+ {}
+}
+
+static void configure_from_fdt(struct loader_info *info)
+{
+ void *fdt = (void *)info-fdt_start;
+ uint32_t const *p;
+ int addrcells, sizecells;
+ int offset, len;
+
+ if(!fdt)
+ return;
+
+ _fdt_address_and_size_cells(fdt, addrcells, sizecells);
+
+ /* See if there is a CCI device to initialise */
+ offset = fdt_node_offset_by_compatible(fdt, 0, arm,cci);
+ if (offset = 0) {
+ p = fdt_getprop(fdt, offset, reg, len);
+ if(len != (addrcells + sizecells) * 4)
+ info(Failed parsing device-tree node for CCI\n);
+ else {
+ /*
+ * p[addrcells - 1] is the least significant 32-bits of
+ * the address for the CCI. On 32-bit CPUs any
additional
+ * address bits had better be zero otherwise we can't
+ * access it as we don't enable the MMU.
+ */
+ init_cci(fdt32_to_cpu(p[addrcells - 1]));
+ }
+ }
+
+ return;
+}
+
static int is_space(char c)
{
return c == ' ';
@@ -598,4 +653,6 @@ args_done:
atag_append(atagp, ATAG_NONE, 0, 0);
update_fdt(phys, info);
+
+ configure_from_fdt(info);
}
--
1.7.10.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/3] bootwrapper: Allow for multiple clusters in boot CPU detection
On Mon, Oct 08, 2012 at 02:59:17PM +0100, Jon Medhurst (Tixy) wrote: From: Jon Medhurst t...@linaro.org Check all the CPU affinity fields of MPIDR, so we select only the first CPU of the first cluster as the one to boot on. Shame, we can't run this on pre-v7 CPUs now ;) (Well, v6T2). The chance of us wanting to do that (motivating bic instead of bfc) is minimal, though. Acked-by: Dave Martin dave.mar...@linaro.org Signed-off-by: Jon Medhurst t...@linaro.org --- boot.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot.S b/boot.S index 727119a..40ebd33 100644 --- a/boot.S +++ b/boot.S @@ -121,7 +121,7 @@ start: @ Check CPU nr again mrc p15, 0, r0, c0, c0, 5 @ MPIDR (ARMv7 only) - and r0, r0, #15 @ CPU number + bfc r0, #24, #8 @ CPU number, taking multicluster into account cmp r0, #0 @ primary CPU? beq 2f -- 1.7.10.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/3] bootwrapper: Add support for big.LITTLE models
On Tue, Oct 09, 2012 at 01:31:55PM +0100, Peter Maydell wrote: On 8 October 2012 14:59, Jon Medhurst (Tixy) t...@linaro.org wrote: This mostly boils down to initialising the Cache Coherent Interconnect (CCI). We do this by looking in the device-tree for a CCI node, that way the same semihosting bootwrapper binary can be used on both the big.LITTLE models and on the A15 models which don't have a CCI. Changes sinces v1: - Added in-source comment to configure_from_fdt() - Reworded commit message for patch 2 [PATCH v2 1/3] bootwrapper: Allow for multiple clusters in boot CPU [PATCH v2 2/3] bootwrapper: Factor out parsing of fdt #address-cells [PATCH v2 3/3] bootwrapper: Initialise CCI device if found in the All: Reviewed-by: Peter Maydell peter.mayd...@linaro.org and tested that the KVM boot is still OK. Patch 2 made git complain about trailing whitespace in one place but I'll just zap that in passing when I apply these. Thanks Dave, unless you have any further review comments I propose to apply these Wednesday. Apart from a couple of minor stylistic quibbles, the look good to me. Those aren't critical, but could be tweaked if you get a moment. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/3] bootwrapper: Add support for big.LITTLE models
On 9 October 2012 14:06, Dave Martin dave.mar...@linaro.org wrote: On Tue, Oct 09, 2012 at 01:31:55PM +0100, Peter Maydell wrote: Patch 2 made git complain about trailing whitespace in one place but I'll just zap that in passing when I apply these. Thanks Dave, unless you have any further review comments I propose to apply these Wednesday. Apart from a couple of minor stylistic quibbles, the look good to me. Those aren't critical, but could be tweaked if you get a moment. I've fixed the style quibbles and pushed the patches to master now. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On Tue, 2012-10-09 at 11:42 +0100, Sudeep KarkadaNagesha wrote: On 09/10/12 11:33, Amit Kucheria wrote: On Tue, Oct 9, 2012 at 2:13 PM, Jon Medhurst (Tixy) t...@linaro.org wrote: On Tue, 2012-10-09 at 09:27 +0100, Sudeep KarkadaNagesha wrote: On 09/10/12 08:10, Viresh Kumar wrote: Following is the declaration of name field in struct cpufreq_driver: char name[CPUFREQ_NAME_LEN]; where CPUFREQ_NAME_LEN is 16. So, length of drivers name must be =15 (one position for '\0'). Current name is crossing this limit and so name doesn't get printed properly when we do: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver This patch renames driver-name to fix this issue. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org Acked-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com Shall I apply this to the ARM Landing Team vexpress tree then? I'd say yes, the driver lives in your tree. I'm not sure how you coordinate the code drops with ARM since it should be in their tree as well for the future. Robin raised a valid point that this driver is TC2 specific and bL is not appropriate name for it including the file name(my bad choice at first). Considering the confusion over what the correct naming should be, I don't think it's worth me apply the renaming patch at the moment ;-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 02/10] sched: Task placement for heterogeneous systems based on task load-tracking
Hi Viresh,
On Thu, Oct 04, 2012 at 07:02:03AM +0100, Viresh Kumar wrote:
Hi Morten,
On 22 September 2012 00:02, morten.rasmus...@arm.com wrote:
From: Morten Rasmussen morten.rasmus...@arm.com
This patch introduces the basic SCHED_HMP infrastructure. Each class of
cpus is represented by a hmp_domain and tasks will only be moved between
these domains when their load profiles suggest it is beneficial.
SCHED_HMP relies heavily on the task load-tracking introduced in Paul
Turners fair group scheduling patch set:
https://lkml.org/lkml/2012/8/23/267
SCHED_HMP requires that the platform implements arch_get_hmp_domains()
which should set up the platform specific list of hmp_domains. It is
also assumed that the platform disables SD_LOAD_BALANCE for the
appropriate sched_domains.
An explanation of this requirement would be helpful here.
Yes. This is to prevent the load-balancer from moving tasks between
hmp_domains. This will be done exclusively by SCHED_HMP instead to
implement a strict task migration policy and avoid changing the
load-balancer behaviour. The load-balancer will take care of
load-balacing within each hmp_domain.
Tasks placement takes place every time a task is to be inserted into
a runqueue based on its load history. The task placement decision is
based on load thresholds.
There are no restrictions on the number of hmp_domains, however,
multiple (2) has not been tested and the up/down migration policy is
rather simple.
Signed-off-by: Morten Rasmussen morten.rasmus...@arm.com
---
arch/arm/Kconfig | 17 +
include/linux/sched.h |6 ++
kernel/sched/fair.c | 168
+
kernel/sched/sched.h |6 ++
4 files changed, 197 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4a5d58..5b09684 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1554,6 +1554,23 @@ config SCHED_SMT
MultiThreading at a cost of slightly increased overhead in some
places. If unsure say N here.
+config DISABLE_CPU_SCHED_DOMAIN_BALANCE
+ bool (EXPERIMENTAL) Disable CPU level scheduler load-balancing
+ help
+ Disables scheduler load-balancing at CPU sched domain level.
Shouldn't this depend on EXPERIMENTAL?
It should. The ongoing discussion about CONFIG_EXPERIMENTAL that Amit is
referring to hasn't come to a conclusion yet.
+config SCHED_HMP
+ bool (EXPERIMENTAL) Heterogenous multiprocessor scheduling
ditto.
+ depends on DISABLE_CPU_SCHED_DOMAIN_BALANCE SCHED_MC
FAIR_GROUP_SCHED !SCHED_AUTOGROUP
+ help
+ Experimental scheduler optimizations for heterogeneous platforms.
+ Attempts to introspectively select task affinity to optimize power
+ and performance. Basic support for multiple (2) cpu types is in
place,
+ but it has only been tested with two types of cpus.
+ There is currently no support for migration of task groups, hence
+ !SCHED_AUTOGROUP. Furthermore, normal load-balancing must be
disabled
+ between cpus of different type (DISABLE_CPU_SCHED_DOMAIN_BALANCE).
+
config HAVE_ARM_SCU
bool
help
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 81e4e82..df971a3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1039,6 +1039,12 @@ unsigned long default_scale_smt_power(struct
sched_domain *sd, int cpu);
bool cpus_share_cache(int this_cpu, int that_cpu);
+#ifdef CONFIG_SCHED_HMP
+struct hmp_domain {
+ struct cpumask cpus;
+ struct list_head hmp_domains;
Probably need a better name here. domain_list?
Yes. hmp_domain_list would be better and stick with the hmp_* naming
convention.
+};
+#endif /* CONFIG_SCHED_HMP */
#else /* CONFIG_SMP */
struct sched_domain_attr;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3e17dd5..d80de46 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3077,6 +3077,125 @@ static int select_idle_sibling(struct task_struct
*p, int target)
return target;
}
+#ifdef CONFIG_SCHED_HMP
+/*
+ * Heterogenous multiprocessor (HMP) optimizations
+ *
+ * The cpu types are distinguished using a list of hmp_domains
+ * which each represent one cpu type using a cpumask.
+ * The list is assumed ordered by compute capacity with the
+ * fastest domain first.
+ */
+DEFINE_PER_CPU(struct hmp_domain *, hmp_cpu_domain);
+
+extern void __init arch_get_hmp_domains(struct list_head
*hmp_domains_list);
+
+/* Setup hmp_domains */
+static int __init hmp_cpu_mask_setup(void)
How should we interpret its return value? Can you mention what does 0 1 mean
here?
Returns 0 if domain setup failed, i.e. the domain list is empty, and 1
otherwise.
+{
+ char buf[64];
+ struct hmp_domain
Re: [RFC PATCH 04/10] sched: Introduce priority-based task migration filter
On Thu, Oct 04, 2012 at 07:27:00AM +0100, Viresh Kumar wrote:
On 22 September 2012 00:02, morten.rasmus...@arm.com wrote:
+config SCHED_HMP_PRIO_FILTER
+ bool (EXPERIMENTAL) Filter HMP migrations by task priority
+ depends on SCHED_HMP
Should it depend on EXPERIMENTAL?
+ help
+ Enables task priority based HMP migration filter. Any task with
+ a NICE value above the threshold will always be on low-power cpus
+ with less compute capacity.
+
+config SCHED_HMP_PRIO_FILTER_VAL
+ int NICE priority threshold
+ default 5
+ depends on SCHED_HMP_PRIO_FILTER
+
config HAVE_ARM_SCU
bool
help
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 490f1f0..8f0f3b9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3129,9 +3129,12 @@ static int __init hmp_cpu_mask_setup(void)
* hmp_down_threshold: max. load allowed for tasks migrating to a slower
cpu
* The default values (512, 256) offer good responsiveness, but may need
* tweaking suit particular needs.
+ *
+ * hmp_up_prio: Only up migrate task with high priority (hmp_up_prio)
*/
unsigned int hmp_up_threshold = 512;
unsigned int hmp_down_threshold = 256;
+unsigned int hmp_up_prio = NICE_TO_PRIO(CONFIG_SCHED_HMP_PRIO_FILTER_VAL);
static unsigned int hmp_up_migration(int cpu, struct sched_entity *se);
static unsigned int hmp_down_migration(int cpu, struct sched_entity *se);
@@ -5491,6 +5494,12 @@ static unsigned int hmp_up_migration(int cpu, struct
sched_entity *se)
if (hmp_cpu_is_fastest(cpu))
return 0;
+#ifdef CONFIG_SCHED_HMP_PRIO_FILTER
+ /* Filter by task priority */
+ if (p-prio = hmp_up_prio)
+ return 0;
+#endif
+
if (cpumask_intersects(hmp_faster_domain(cpu)-cpus,
tsk_cpus_allowed(p))
se-avg.load_avg_ratio hmp_up_threshold) {
@@ -5507,6 +5516,12 @@ static unsigned int hmp_down_migration(int cpu,
struct sched_entity *se)
if (hmp_cpu_is_slowest(cpu))
return 0;
+#ifdef CONFIG_SCHED_HMP_PRIO_FILTER
+ /* Filter by task priority */
+ if (p-prio = hmp_up_prio)
+ return 1;
+#endif
Even if below cpumask_intersects() fails?
No. Good catch :)
if (cpumask_intersects(hmp_slower_domain(cpu)-cpus,
tsk_cpus_allowed(p))
se-avg.load_avg_ratio hmp_down_threshold) {
--
viresh
Thanks,
Morten
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On 9 October 2012 21:02, Jon Medhurst (Tixy) t...@linaro.org wrote: Considering the confusion over what the correct naming should be, I don't think it's worth me apply the renaming patch at the moment ;-) This thread went into another direction, than the one it was intended for :) Looks correct, would be better if Sudeep can send a quick patch with renaming of file/routines/driver. Because the initial issue reported by me was a bug and has to be fixed ASAP. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Questions about linux-linaro-tracking.git asked on IRC
(12:25:28 PM) hongbo_: amitk: good afternoon. need I push u8500 thermal driver to linux-linaro? problems I found is that both the AmitDK's generic cpu cooling code and the generic thermal layer code are so old in this tree, if u8500 thermal driver has to be pushed into this tree, I have to edit it to an relevant old and useless version. (12:27:16 PM) amitk: fabo: which build (and corresponding kernel) currently has the best enablement across various member HW. LLCT doesn't work on some hardware and is blocking michaelh|away from creating a PM-QA summary view for us (12:27:25 PM) amitk: andrey_konovalov: ^ hongbo_ could try linux-linaro instead of linux-linaro-core-tracking. (12:28:02 PM) amitk: hongbo_: the idea is never to go with older patchsets, but to refresh the depending patchset to a newer version. (12:28:10 PM) hongbo_: amitk: my opinion is that both generic cooling and thermal framework should be update first, and then push u8500 codes later (12:29:16 PM) hongbo_: amitk: who is responsible for refreshing generic cooling code? Amit DK has left. (12:29:17 PM) amitk: hongbo_: correct, so can you ask andrey_konovalov to remove the old thermal fwk code (where do you find it, btw?) and supply him with a new version of the patchset (3.6+) (12:29:25 PM) amitk: hongbo_: now you are :) (12:31:12 PM) hongbo_: amitk: andrey_konovalov: I found the old thermal fwk here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/thermal;h=642a4a8ef2bc2834c6bab9cc1469c4459f330f4e;hb=13e6bbdf5e6e44b2168dbc876d8bba61d28f29c7 Wrong tree. This is *v3.4 based* linux-linaro-tracking (aka LLT) tree (git branch to be exact). It should not be used to develop new common code (this tree is created from LT's trees; there are no common topics in llt). There is a short description of the linux-linaro-tracking.git branches here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=summary - and the link to https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 02/10] sched: Task placement for heterogeneous systems based on task load-tracking
On 9 October 2012 21:26, Morten Rasmussen morten.rasmus...@arm.com wrote:
On Thu, Oct 04, 2012 at 07:02:03AM +0100, Viresh Kumar wrote:
On 22 September 2012 00:02, morten.rasmus...@arm.com wrote:
SCHED_HMP requires that the platform implements arch_get_hmp_domains()
which should set up the platform specific list of hmp_domains. It is
also assumed that the platform disables SD_LOAD_BALANCE for the
appropriate sched_domains.
An explanation of this requirement would be helpful here.
Yes. This is to prevent the load-balancer from moving tasks between
hmp_domains. This will be done exclusively by SCHED_HMP instead to
implement a strict task migration policy and avoid changing the
load-balancer behaviour. The load-balancer will take care of
load-balacing within each hmp_domain.
Honestly speaking i understood this point now and earlier it wasn't clear
to me :)
What would be ideal is to put this information in the comment just before
we re-define other SCHED_*** domains where we disable balancing.
And keep it in the commit log too.
+struct hmp_domain {
+ struct cpumask cpus;
+ struct list_head hmp_domains;
Probably need a better name here. domain_list?
Yes. hmp_domain_list would be better and stick with the hmp_* naming
convention.
IMHO hmp_ would be better for global names, but names of variables
enclosed within another hmp_*** data type don't actually need hmp_**,
as this is implicity.
i.e.
struct hmp_domain {
struct cpumask cpus;
struct list_head domain_list;
}
would be better than
struct list_head hmp domain_list;
as the parent structure already have hmp_***. So whatever is inside the
struct is obviously hmp specific.
+/* Setup hmp_domains */
+static int __init hmp_cpu_mask_setup(void)
How should we interpret its return value? Can you mention what does 0 1
mean
here?
Returns 0 if domain setup failed, i.e. the domain list is empty, and 1
otherwise.
Helpful. Please mention this in function comment in your next revision.
+{
+ char buf[64];
+ struct hmp_domain *domain;
+ struct list_head *pos;
+ int dc, cpu;
+ /* Print hmp_domains */
+ dc = 0;
Should be done during definition of dc.
You missed this ??
+ for_each_cpu_mask(cpu, domain-cpus) {
+ per_cpu(hmp_cpu_domain, cpu) = domain;
+ }
Should use hmp_cpu_domain(cpu) here. Also no need of {} for single
line loop.
??
+ dc++;
You aren't using it... Only for testing? Should we remove it from mainline
patchset and keep it locally?
I'm using it in the pr_debug line a little earlier. It is used for
enumerating the hmp_domains.
My mistake :(
+/* Check if cpu is in fastest hmp_domain */
+static inline unsigned int hmp_cpu_is_fastest(int cpu)
+{
+ struct list_head *pos;
+
+ pos = hmp_cpu_domain(cpu)-hmp_domains;
+ return pos == hmp_domains.next;
better create list_is_first() for this.
I had the same thought, but I see that as a separate patch that should
be submitted separately.
Correct. So better send it now, so that it is included before you send your
next version. :)
--
viresh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On Tue, 2012-10-09 at 22:15 +0530, Viresh Kumar wrote: On 9 October 2012 21:02, Jon Medhurst (Tixy) t...@linaro.org wrote: Considering the confusion over what the correct naming should be, I don't think it's worth me apply the renaming patch at the moment ;-) This thread went into another direction, than the one it was intended for :) Looks correct, would be better if Sudeep can send a quick patch with renaming of file/routines/driver. Because the initial issue reported by me was a bug and has to be fixed ASAP. Perhaps I misunderstood the bug, I though it was just a name getting truncated and was otherwise harmless. If it's causing real problems then I'll apply the original suggested patch and not worry about other cosmetic renaming issues. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq: vexpress: cpufreq driver name can't be longer than 15 chars
On 9 October 2012 22:30, Jon Medhurst (Tixy) t...@linaro.org wrote: Perhaps I misunderstood the bug, I though it was just a name getting truncated and was otherwise harmless. If it's causing real problems then I'll apply the original suggested patch and not worry about other cosmetic renaming issues. No real working failure without this patch. Only while doing $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver We don't get a new line entered at the print.. So, currently we get something like: cpufreq_vexpress$/root/: -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PULL REQUEST]: ARM: perf: multi-PMU support v2
Hi Viresh, Please pull the following changes(v2) for the multiple CPU PMU support (re-based to v3.6). Changes v1-v2: 1. Incorporated review comments from Will for few patches(which he will be queuing for v3.8) 2. Dropped ARM: perf: register the init functions with the bindings, still looking for alternate to list in implementation. 3. Added per-process event tracking support on multi-PMUs. Re-factored the original patch ARM: perf: add support for per-cluster/multiple PMUs 4. Fixed the bug reported by Tixy for non-FDT case The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: ssh://usern...@pdsw-ci.cambridge.arm.com:29418/kernel.git multi_pmu_v2 for you to fetch changes up to bd7fc4c65bd8ed994ded5aa0feeef91190fbd7be: ARM: perf: save/restore pmu registers in pm notifier (2012-10-09 18:20:45 +0100) Axel Lin (1): ARM: ux500: Fix build error due to missing include of asm/pmu.h in cpu-db8500.c Jon Hunter (1): ARM: PMU: Add runtime PM Support Lorenzo Pieralisi (1): ARM: kernel: provide cluster to logical cpu mask mapping API Marc Zyngier (1): ARM: perf: add guest vs host discrimination Mark Rutland (1): ARM: perf: register cpu_notifier at driver init Sudeep KarkadaNagesha (11): ARM: pmu: remove arm_pmu_type enumeration ARM: perf: move irq registration into pmu implementation ARM: perf: allocate CPU PMU dynamically at probe time ARM: perf: consistently use struct perf_event in arm_pmu functions ARM: perf: check ARMv7 counter validity on a per-pmu basis ARM: perf: replace global CPU PMU pointer with per-cpu pointers ARM: perf: register CPU PMUs with idr types ARM: perf: set cpu affinity to support multiple PMUs ARM: perf: set cpu affinity for the irqs correctly ARM: perf: remove spaces in CPU PMU names ARM: perf: save/restore pmu registers in pm notifier Will Deacon (8): ARM: perf: add devicetree bindings for 11MPcore, A5, A7 and A15 PMUs ARM: pmu: remove unused reservation mechanism ARM: perf: remove mysterious compiler barrier ARM: perf: probe devicetree in preference to current CPU ARM: perf: prepare for moving CPU PMU code into separate file ARM: perf: move CPU-specific PMU handling code into separate file ARM: perf: return NOTIFY_DONE from cpu notifier when no available PMU ARM: perf: consistently use arm_pmu-name for PMU name Documentation/devicetree/bindings/arm/pmu.txt |7 + MAINTAINERS |1 - arch/arm/Kconfig |8 +- arch/arm/include/asm/perf_event.h | 14 +- arch/arm/include/asm/pmu.h| 111 +++ arch/arm/include/asm/topology.h |3 + arch/arm/kernel/Makefile |3 +- arch/arm/kernel/perf_event.c | 444 +++-- arch/arm/kernel/perf_event_cpu.c | 380 + arch/arm/kernel/perf_event_v6.c | 134 arch/arm/kernel/perf_event_v7.c | 307 + arch/arm/kernel/perf_event_xscale.c | 163 - arch/arm/kernel/pmu.c | 36 -- arch/arm/kernel/topology.c| 27 ++ arch/arm/mach-bcmring/arch.c |3 +- arch/arm/mach-omap2/devices.c |3 +- arch/arm/mach-pxa/devices.c |3 +- arch/arm/mach-realview/realview_eb.c |3 +- arch/arm/mach-realview/realview_pb1176.c |3 +- arch/arm/mach-realview/realview_pb11mp.c |3 +- arch/arm/mach-realview/realview_pba8.c|3 +- arch/arm/mach-realview/realview_pbx.c |3 +- arch/arm/mach-tegra/devices.c |3 +- arch/arm/mach-ux500/cpu-db8500.c |4 +- arch/arm/mach-vexpress/ct-ca9x4.c |3 +- arch/arm/plat-iop/pmu.c |3 +- arch/arm/plat-samsung/devs.c |3 +- 27 files changed, 942 insertions(+), 736 deletions(-) create mode 100644 arch/arm/kernel/perf_event_cpu.c delete mode 100644 arch/arm/kernel/pmu.c -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PULL REQUEST]: ARM: perf: multi-PMU support v2
On 9 October 2012 23:16, Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com wrote: Hi Viresh, Please pull the following changes(v2) for the multiple CPU PMU support (re-based to v3.6). Thanks.. Will be included in this release. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro + call for 12.10 topics
Greetings, On 10/06/2012 01:07 AM, Andrey Konovalov wrote: Greetings, Minor change to the plan: * The current llct is *llct-20121006.0* * October 9: ll rebuild based on llct-20121006.0 ll-20121010.0 has been pushed to linux-linaro-tracking.git. The pinned manifest is: http://git.linaro.org/gitweb?p=kernel/linux-linaro-manifest.git;a=blob;f=manifest.pin;h=84bb4172cbda8f5d603b1507f9f5299b5f60787b;hb=1c7ce72c6a6c9ee072987f6c8d964971fa8c3936 ll-20121010.0 is based on llct-20121009.0, which is llct-20121006.0 plus few fixes. Here is the pinned manifest: http://git.linaro.org/gitweb?p=kernel/linux-linaro-manifest.git;a=blob;f=manifest.pin;h=a6a0cb6c3415efc8ba2f020758f581846889123b;hb=linux-linaro-core-tracking * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) If you have a new topic to add to 12.10, please make sure that it is submitted by October 12 (common topics to add to llct tree), or October 16 (ll topics). The topics for llct should be based on v3.6 or (if there is a need for that) on another llct topic. The ll topics should be based on llct, or (if there is a need for that) on v3.6 or another ll topic. If an ll topic is based on an older llct version, it can be rebased to the current one automatically, but the commit ids would be mangled (of course). For the 12.10 the plan is to switch to config fragments for all the supported boards. Please make sure that the config fragment for your board is up-to-date here: git://git.linaro.org/kernel/configs.git , config-boards-3.6 branch Otherwise these instructions apply: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess Thanks, Andrey On 10/05/2012 05:25 PM, Jon Medhurst (Tixy) wrote: On Fri, 2012-10-05 at 17:03 +0400, Andrey Konovalov wrote: On 10/05/2012 12:12 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Yes, this makes sense. Would the following plan be OK: (N should normally be 0, but may be a small positive number) * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N * October 23: ll rebuild based on llct-20121019.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Is this month following the normal release cycle? If so, isn't the release day Oct 24th, and release candidates are built from the previous Thurday's code, i.e. Oct 18th. I.e. the freeze for the release should be Oct 16th not 23rd? Oops.. Your are right. Why don't we have the Thursday, October 32 this year? So the correct plan is the following: * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Also, I assume we're not going to try to move to Linux 3.7 this month? That's correct. We didn't have the kernel.org release based (vs -rc based) ll release for quite a while. And the plan is to stick to v3.6 for 12.10 release unless someone needs to move to v3.7-rc* by all means this cycle. After October 19 the llct tree will move to v3.7-rc*, but the ll tree will be frozen till the 12.10 is out. That all sounds reasonable to me. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
2012-10-10 Android Platform Team Meeting Agenda Posted
Please take a look at: https://wiki.linaro.org/Platform/Android/Meetings/2012-10-10 Feel free to add to the agenda and join us in #linaro-meeting on irc.freenode.net at 13:00 UTC on 2012/10/10. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PULL REQUEST]: ARM: perf: multi-PMU support v2
On 9 October 2012 23:16, Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com wrote: Please pull the following changes(v2) for the multiple CPU PMU support (re-based to v3.6). http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=shortlog;h=refs/heads/arm-multi_pmu_v2 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] cpufreq:core: Fix printing of governor and driver name
Arrays for governer and driver name are of size CPUFREQ_NAME_LEN or 16.
i.e. 15 bytes for name and 1 for trailing '\0'.
When cpufreq driver print these names (for sysfs), it includes '\n' or ' ' in
the fmt string and still passes length as CPUFREQ_NAME_LEN. If the driver or
governor names are using all 15 fields allocated to them, then the trailing '\n'
or ' ' will never be printed. And so commands like:
root@linaro-developer# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
will print something like:
cpufreq_foodrvroot@linaro-developer#
Fix this by increasing print length by one character.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 6 +++---
include/linux/cpufreq.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 021973b..db6e337 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -445,7 +445,7 @@ static ssize_t show_scaling_governor(struct cpufreq_policy
*policy, char *buf)
else if (policy-policy == CPUFREQ_POLICY_PERFORMANCE)
return sprintf(buf, performance\n);
else if (policy-governor)
- return scnprintf(buf, CPUFREQ_NAME_LEN, %s\n,
+ return scnprintf(buf, CPUFREQ_NAME_PLEN, %s\n,
policy-governor-name);
return -EINVAL;
}
@@ -491,7 +491,7 @@ static ssize_t store_scaling_governor(struct cpufreq_policy
*policy,
*/
static ssize_t show_scaling_driver(struct cpufreq_policy *policy, char *buf)
{
- return scnprintf(buf, CPUFREQ_NAME_LEN, %s\n, cpufreq_driver-name);
+ return scnprintf(buf, CPUFREQ_NAME_PLEN, %s\n, cpufreq_driver-name);
}
/**
@@ -512,7 +512,7 @@ static ssize_t show_scaling_available_governors(struct
cpufreq_policy *policy,
if (i = (ssize_t) ((PAGE_SIZE / sizeof(char))
- (CPUFREQ_NAME_LEN + 2)))
goto out;
- i += scnprintf(buf[i], CPUFREQ_NAME_LEN, %s , t-name);
+ i += scnprintf(buf[i], CPUFREQ_NAME_PLEN, %s , t-name);
}
out:
i += sprintf(buf[i], \n);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index b60f6ba..fc4b785 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -22,6 +22,8 @@
#include asm/div64.h
#define CPUFREQ_NAME_LEN 16
+/* Print length for names. Extra 1 space for accomodating '\n' in prints */
+#define CPUFREQ_NAME_PLEN (CPUFREQ_NAME_LEN + 1)
/*
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
