Re: [PATCH] dt: add helper function to read u8 & u16 variables & arrays
On Tue, 2012-11-20 at 10:15 +0530, Viresh Kumar wrote:
> This adds following helper routines:
> - of_property_read_u8_array()
> - of_property_read_u16_array()
> - of_property_read_u8()
> - of_property_read_u16()
>
> This expects arrays from DT to be passed as:
> - u8 array:
> property = /bits/ 8 <0x50 0x60 0x70>;
> - u16 array:
> property = /bits/ 16 <0x5000 0x6000 0x7000>;
>
> Signed-off-by: Viresh Kumar
> ---
> V2->V3:
> - Expect u8 & u16 arrays to be passed using: /bits/ 8 or 16
> - remove common macro, as not much common now :(
You could at least create macro to do a precheck if you want to.
Like
#define CHECK_PROP(prop, sz, out)
{
if (!prop)
return -EINVAL;
if (!prop->value)
return -ENODATA;
if ((sz * sizeof(*out)) > prop->length)
return -EOVERFLOW;
}
Of course you can do even robust macro to cover types, but I don't like
ugly macros (as I can't see how it could be shaped nicely).
> - Tested on ARM platform.
>
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -671,12 +671,89 @@ struct device_node *of_find_node_by_phandle(phandle
> handle)
> EXPORT_SYMBOL(of_find_node_by_phandle);
>
> /**
> + * of_property_read_u8_array - Find and read an array of u8 from a property.
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname:name of the property to be searched.
> + * @out_value: pointer to return value, modified only if return value
> is 0.
> + * @sz: number of array elements to read
> + *
> + * Search for a property in a device node and read 8-bit value(s) from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * dts entry of array should be like:
> + * property = /bits/ 8 <0x50 0x60 0x70>;
> + *
> + * The out_value is modified only if a valid u8 value can be decoded.
> + */
> +int of_property_read_u8_array(const struct device_node *np,
> + const char *propname, u8 *out_values, size_t sz)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> + const u8 *val;
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> + if ((sz * sizeof(*out_values)) > prop->length)
> + return -EOVERFLOW;
> +
> + val = prop->value;
> + while (sz--)
> + *out_values++ = *val++;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_property_read_u8_array);
> +
> +/**
> + * of_property_read_u16_array - Find and read an array of u16 from a
> property.
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname:name of the property to be searched.
> + * @out_value: pointer to return value, modified only if return value
> is 0.
> + * @sz: number of array elements to read
> + *
> + * Search for a property in a device node and read 16-bit value(s) from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * dts entry of array should be like:
> + * property = /bits/ 16 <0x5000 0x6000 0x7000>;
> + *
> + * The out_value is modified only if a valid u16 value can be decoded.
> + */
> +int of_property_read_u16_array(const struct device_node *np,
> + const char *propname, u16 *out_values, size_t sz)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> + const __be16 *val;
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> + if ((sz * sizeof(*out_values)) > prop->length)
> + return -EOVERFLOW;
> +
> + val = prop->value;
> + while (sz--)
> + *out_values++ = be16_to_cpup(val++);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_property_read_u16_array);
> +
> +/**
> * of_property_read_u32_array - Find and read an array of 32 bit integers
> * from a property.
> *
> * @np: device node from which the property value is to be read.
> * @propname:name of the property to be searched.
> * @out_value: pointer to return value, modified only if return value
> is 0.
> + * @sz: number of array elements to read
> *
> * Search for a property in a device node and read 32-bit value(s) from
> * it. Returns 0 on success, -EINVAL if the property does not exist,
--
Andy Shevchenko
Intel Finland Oy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any re
Re: [PATCH] dt: add helper function to read u8 & u16 variables & arrays
On 20 November 2012 13:51, Shevchenko, Andriy
wrote:
> You could at least create macro to do a precheck if you want to.
>
> Like
> #define CHECK_PROP(prop, sz, out)
>
> {
> if (!prop)
> return -EINVAL;
> if (!prop->value)
> return -ENODATA;
> if ((sz * sizeof(*out)) > prop->length)
> return -EOVERFLOW;
> }
Hi Andriy,
Initially i started with a macro for the complete routine, but later as types
started to play important role in it, i have to split it to routines.
I thought of this idea to do prop check in a macro, but then i thought
it might cover a bigger range of files and so thought of doing that separately.
For, simplicity left it this time.
--
viresh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]; big LITTLE MP master v12
On Tue, 2012-11-20 at 13:00 +0530, Viresh Kumar wrote: > On 19 November 2012 22:44, Andrey Konovalov > wrote: > > I won't pull the big-LITTLE-MP-master-v12 into the > > linux-linaro-core-tracking tree today due to the issues found by Tixy. > > > > Tomorrow evening I am going to pull this topic anyway - whether these issues > > are resolved, or not. If the build error is not fixed by Thursday morning > > UTC, I'll move llct back to v11. Would it work for the Landing Teams? Tixy? > > Hi Andrey, > > I have updated master-v12 branch with fixes from tixy and ARM. > You can PULL it now :) I've redone my vexpress test integration branch [1] based on the new big-LITTLE-MP-master-v12 and can confirm that an Android kernel builds and boots on TC2 and A9 CoreTiles, both with and without the big-LITTLE-MP.conf. What shall we do about the boot time and possibly other performance regressions? I can disable CONFIG_HMP_VARIABLE_SCALE in vexpress builds... -- Tixy [1] http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=shortlog;h=refs/heads/integration-android-vexpress ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]; big LITTLE MP master v12
On 20 November 2012 15:40, Jon Medhurst (Tixy) wrote: > I've redone my vexpress test integration branch [1] based on the new > big-LITTLE-MP-master-v12 and can confirm that an Android kernel builds > and boots on TC2 and A9 CoreTiles, both with and without the > big-LITTLE-MP.conf. Thanks. > What shall we do about the boot time and possibly other performance > regressions? I can disable CONFIG_HMP_VARIABLE_SCALE in vexpress I haven't done anything for this, as Chris reported he isn't facing this issue. @Chris? -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [GIT PULL]; big LITTLE MP master v12
Well, I didn't find any problem with USB boot. I'm just setting up u-boot to go for a completely standard MMC boot and I'll continue to try to reproduce. Tixy, could you try temporarily changing the default option to off for the frequency-invariant load? I think it'll be at line 3631 in your fair.c hmp_data.freqinvar_load_scale_enabled = 1; Change it to 0 to change the default. Basically, there are two feature changes which are both disabled when you disable CONFIG_HMP_VARIABLE_SCALE and I'd like to find out which is responsible. The CONFIG_HMP_VARIABLE_SCALE control is responsible for a change which lets us 'stretch time' during load accumulation so that we can retain the optimised math routines in Paul's patch but also control the rate of accumulation of load. On top of that using the same sysfs code, is CONFIG_HMP_FREQUENCY_INVARIANT_SCALE which uses a PM notifier to change a scale factor so that the recorded loads are expressed in terms of the potential CPU capacity rather than instantaneous capacity. This has the effect of stopping HMP up migrations from happening when the frequency of the A7 cluster is still low. I can't think of any reason why either of these changes should result in increased boot time other than some odd interaction between DVFS and IO wait time which we haven't seen anywhere yet. Even then, it seems strange that we could get such a slowdown. Presumably the IO itself wouldn't get slower, and over the course of a whole boot the CPUs are not very busy anyway. Regards, Chris > -Original Message- > From: Viresh Kumar [mailto:viresh.ku...@linaro.org] > Sent: 20 November 2012 10:13 > To: Chris Redpath; Jon Medhurst (Tixy) > Cc: Andrey Konovalov; PDSW-power-team; Lists linaro-dev > Subject: Re: [GIT PULL]; big LITTLE MP master v12 > > On 20 November 2012 15:40, Jon Medhurst (Tixy) wrote: > > I've redone my vexpress test integration branch [1] based on the new > > big-LITTLE-MP-master-v12 and can confirm that an Android kernel > builds > > and boots on TC2 and A9 CoreTiles, both with and without the > > big-LITTLE-MP.conf. > > Thanks. > > > What shall we do about the boot time and possibly other performance > > regressions? I can disable CONFIG_HMP_VARIABLE_SCALE in vexpress > > I haven't done anything for this, as Chris reported he isn't facing > this issue. > @Chris? > > -- > viresh -- 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: [GIT PULL]; big LITTLE MP master v12
Hi Tixy, It seems that at least on my board, the presence of so many MMC timeouts causes the A7s to remain at the lowest frequency, presumably because the system load average is so low. With the frequency-invariant patch, this has the side effect that no tasks ever get to run elsewhere. Do you get lots of these? [ 529.490615] mmcblk0: retrying using single block transfer [ 529.591009] mmcblk0: error -5 transferring data, sector 845208, nr 24, cmd response 0x0, card status 0x900 Regards, Chris > -Original Message- > From: Chris Redpath > Sent: 20 November 2012 10:23 > To: Viresh Kumar; Jon Medhurst (Tixy) > Cc: Andrey Konovalov; PDSW-power-team; Lists linaro-dev > Subject: RE: [GIT PULL]; big LITTLE MP master v12 > > Well, I didn't find any problem with USB boot. I'm just setting up u- > boot to go for a completely standard MMC boot and I'll continue to try > to reproduce. > > Tixy, could you try temporarily changing the default option to off for > the frequency-invariant load? > > I think it'll be at line 3631 in your fair.c > > hmp_data.freqinvar_load_scale_enabled = 1; > > Change it to 0 to change the default. > > > Basically, there are two feature changes which are both disabled when > you disable CONFIG_HMP_VARIABLE_SCALE and I'd like to find out which is > responsible. > > The CONFIG_HMP_VARIABLE_SCALE control is responsible for a change which > lets us 'stretch time' during load accumulation so that we can retain > the optimised math routines in Paul's patch but also control the rate > of accumulation of load. > > On top of that using the same sysfs code, is > CONFIG_HMP_FREQUENCY_INVARIANT_SCALE which uses a PM notifier to change > a scale factor so that the recorded loads are expressed in terms of the > potential CPU capacity rather than instantaneous capacity. This has the > effect of stopping HMP up migrations from happening when the frequency > of the A7 cluster is still low. > > I can't think of any reason why either of these changes should result > in increased boot time other than some odd interaction between DVFS and > IO wait time which we haven't seen anywhere yet. Even then, it seems > strange that we could get such a slowdown. Presumably the IO itself > wouldn't get slower, and over the course of a whole boot the CPUs are > not very busy anyway. > > > Regards, > Chris > > > -Original Message- > > From: Viresh Kumar [mailto:viresh.ku...@linaro.org] > > Sent: 20 November 2012 10:13 > > To: Chris Redpath; Jon Medhurst (Tixy) > > Cc: Andrey Konovalov; PDSW-power-team; Lists linaro-dev > > Subject: Re: [GIT PULL]; big LITTLE MP master v12 > > > > On 20 November 2012 15:40, Jon Medhurst (Tixy) > wrote: > > > I've redone my vexpress test integration branch [1] based on the > new > > > big-LITTLE-MP-master-v12 and can confirm that an Android kernel > > builds > > > and boots on TC2 and A9 CoreTiles, both with and without the > > > big-LITTLE-MP.conf. > > > > Thanks. > > > > > What shall we do about the boot time and possibly other performance > > > regressions? I can disable CONFIG_HMP_VARIABLE_SCALE in vexpress > > > > I haven't done anything for this, as Chris reported he isn't facing > > this issue. > > @Chris? > > > > -- > > viresh -- 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: [GIT PULL]; big LITTLE MP master v12
On Tue, 2012-11-20 at 10:23 +, Chris Redpath wrote: > Well, I didn't find any problem with USB boot. I'm just setting up u-boot to > go for a completely standard MMC boot and I'll continue to try to reproduce. I use ARM's bootmonitor for booting. My setup should have the same firmware and boot process as results from the instructions at: http://releases.linaro.org/12.10/android/vexpress > Tixy, could you try temporarily changing the default option to off for the > frequency-invariant load? > > I think it'll be at line 3631 in your fair.c > > hmp_data.freqinvar_load_scale_enabled = 1; > > Change it to 0 to change the default. That change restores boot time to 90 seconds down from 5-ish minutes. I'll try booting from a USB stick instead of MMC... -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]; big LITTLE MP master v12
On Tue, 2012-11-20 at 11:31 +, Chris Redpath wrote: > Hi Tixy, > > It seems that at least on my board, the presence of so many MMC timeouts > causes the A7s to remain at the lowest frequency, presumably because the > system load average is so low. With the frequency-invariant patch, this has > the side effect that no tasks ever get to run elsewhere. > > Do you get lots of these? > > [ 529.490615] mmcblk0: retrying using single block transfer > [ 529.591009] mmcblk0: error -5 transferring data, sector 845208, nr 24, cmd > response 0x0, card status 0x900 No, because we have fixed IOFPGA firmware. The 'Firmware Update' tab on http://releases.linaro.org/12.10/android/vexpress links to ARM's site to get this. Our kernel commandline also has "mmci.fmax=1200" to select the fastest clock speed possible. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]; big LITTLE MP master v12
On Tue, 2012-11-20 at 11:32 +, Jon Medhurst (Tixy) wrote: > > Tixy, could you try temporarily changing the default option to off for the > > frequency-invariant load? > > > > I think it'll be at line 3631 in your fair.c > > > > hmp_data.freqinvar_load_scale_enabled = 1; > > > > Change it to 0 to change the default. > > That change restores boot time to 90 seconds down from 5-ish minutes. > > I'll try booting from a USB stick instead of MMC... I cloned my MMC card onto a USB stick and updated init.partitions.rc in my initrd to mount sdaX rather than mmblk0pX. Here are the boot times I get: With hmp_data.freqinvar_load_scale_enabled = 1 49s, 46s, 46s With hmp_data.freqinvar_load_scale_enabled = 0 39s, 40s, 37s So whilst the difference is nothing like what I see with MMC, there does still seem to be a significant effect. On the slow booting config, the 'Geiger counter' sound from the power circuitry does sound a bit harsher, perhaps the pattern of cpuidling is different. That could be my imaginations, or a symptom rather than a cause... -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [GIT PULL]; big LITTLE MP master v12
Hi Tixy, I can now reproduce it with MMC too, and the times are pretty much the same for me :( There is definitely some interaction with CPUFreq, the A7s stay at a low enough OPP that the busy threads during boot are never able to accumulate enough load to migrate up to an A15. Normally, it makes no sense for a thread classified as 'heavy' at 350MHz to move to an A15 since it may very well not be a heavy thread at 1GHz. This is the expected behaviour of the patch, to bring HMP migration in line with cpufreq DVFS changes. Do you always use the ondemand governor in Linaro? I'm wondering if one of the differences is that the default ondemand config bases it's load calculation on a 1s sliding window, while we use the interactive governor which is much more sensitive. I'm going to try changing the ondemand config at boot and see what happens. Regards, Chris > -Original Message- > From: Jon Medhurst (Tixy) [mailto:t...@linaro.org] > Sent: 20 November 2012 12:31 > To: Chris Redpath > Cc: Viresh Kumar; Andrey Konovalov; PDSW-power-team; Lists linaro-dev > Subject: Re: [GIT PULL]; big LITTLE MP master v12 > > On Tue, 2012-11-20 at 11:32 +, Jon Medhurst (Tixy) wrote: > > > > Tixy, could you try temporarily changing the default option to off > for the frequency-invariant load? > > > > > > I think it'll be at line 3631 in your fair.c > > > > > > hmp_data.freqinvar_load_scale_enabled = 1; > > > > > > Change it to 0 to change the default. > > > > That change restores boot time to 90 seconds down from 5-ish minutes. > > > > I'll try booting from a USB stick instead of MMC... > > I cloned my MMC card onto a USB stick and updated init.partitions.rc in > my initrd to mount sdaX rather than mmblk0pX. Here are the boot times I > get: > > With hmp_data.freqinvar_load_scale_enabled = 1 > > 49s, 46s, 46s > > With hmp_data.freqinvar_load_scale_enabled = 0 > > 39s, 40s, 37s > > So whilst the difference is nothing like what I see with MMC, there > does > still seem to be a significant effect. > > On the slow booting config, the 'Geiger counter' sound from the power > circuitry does sound a bit harsher, perhaps the pattern of cpuidling is > different. That could be my imaginations, or a symptom rather than a > cause... > > -- > Tixy > -- 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: [GIT PULL]; big LITTLE MP master v12
On Tue, 2012-11-20 at 12:39 +, Chris Redpath wrote: > Hi Tixy, > > I can now reproduce it with MMC too, and the times are pretty much the same > for me :( > > There is definitely some interaction with CPUFreq, the A7s stay at a low > enough OPP > that the busy threads during boot are never able to accumulate enough load to > migrate up to an A15. Normally, it makes no sense for a thread classified as > 'heavy' > at 350MHz to move to an A15 since it may very well not be a heavy thread at > 1GHz. > This is the expected behaviour of the patch, to bring HMP migration in line > with > cpufreq DVFS changes. > > Do you always use the ondemand governor in Linaro? That is how I was told by people at ARM to configure vexpress for big.LITTLE MP; A15's as 'perfomance', A7's as 'ondemand'. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]; big LITTLE MP master v12
On 11/20/2012 11:30 AM, Viresh Kumar wrote: On 19 November 2012 22:44, Andrey Konovalov wrote: I won't pull the big-LITTLE-MP-master-v12 into the linux-linaro-core-tracking tree today due to the issues found by Tixy. Tomorrow evening I am going to pull this topic anyway - whether these issues are resolved, or not. If the build error is not fixed by Thursday morning UTC, I'll move llct back to v11. Would it work for the Landing Teams? Tixy? Hi Andrey, I have updated master-v12 branch with fixes from tixy and ARM. You can PULL it now :) Done. Thanks! Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 3/6] sched: pack small tasks
Hi Vincent,
On Mon, Nov 12, 2012 at 01:51:00PM +, Vincent Guittot wrote:
> On 9 November 2012 18:13, Morten Rasmussen wrote:
> > 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.
>
> Hi Morten,
>
> Thanks for testing the patches.
>
> It seems that I have too optimized the loop and remove some use cases.
>
> >
> > 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
>
> You probably wanted to use sched_group instead of cluster because
> cluster is only a special use case, didn't you ?
>
> > 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.
>
> We don't want to pack in the current sched_domain because it shares
> power domain. We want to pack at the parent level
>
Yes. I think we mean the same thing. The packing takes place at the
parent sched_domain but the sched_group that we are looking at only
contains the cpus of the level below.
> >
> > I propose the following fix:
> >
> > - sd = sd->parent;
> > + if (cpumask_first(sched_domain_span(sd)) == cpu
> > + || !sd->parent)
> > + sd = sd->parent;
>
> We always look for the buddy in the parent level whatever the cpu
> position in the mask is.
>
> >
> >
> >> +
> >> + 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
>
Re: [GIT PULL]; big LITTLE MP master v12
Hi Viresh, I test your updated branch, and find there is some errors: # ARCH=arm scripts/kconfig/merge_config.sh arch/arm/configs/vexpress_defconfig linaro/configs/big-LITTLE-MP.conf Using arch/arm/configs/vexpress_defconfig as base Merging linaro/configs/big-LITTLE-MP.conf HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --alldefconfig Kconfig # # configuration written to .config # Value requested for CONFIG_RCU_CPU_STALL_DETECTOR not in final .config Requested value: # CONFIG_RCU_CPU_STALL_DETECTOR is not set Actual value: Value requested for CONFIG_DEBUG_ERRORS not in final .config Requested value: CONFIG_DEBUG_ERRORS=y Actual value: Value requested for CONFIG_HMP_FREQUENCY_INVARIANT_SCALE not in final .config Requested value: CONFIG_HMP_FREQUENCY_INVARIANT_SCALE=y Actual value: Any suggestion for this? Also when launch the MP system, how could I know there already two cluster are running? For I only see one cpu by checking cpuinfo. The system I am running actually is A15x1-A7x1 over fastmodel... -- / # cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS: 99.73 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part: 0xc0f CPU revision: 0 Hardware: ARM-Versatile Express Revision: Serial : Thanks, Lei On Sun, Nov 18, 2012 at 1:10 PM, Viresh Kumar wrote: > Hi Andrey, > > Please pull big-LITTLE-MP-master-v12 with following updates: > > - Based on v3.7-rc5 > - Stats: > - Total Patches: 62 > - New Patches: 1 >- genirq: Add default affinity mask command line option in > misc-patches branch >- top 3 patches in: sched-pack-small-tasks-v1 >- top 2 patches in: task-placement-v2 >- additional patch in: config-fragments > - Dropped patches/branches (as they are managed in experimental > merge branch): 20 >- patches in per-entity-load-tracking-with-core-sched-v1: 15 > - Updated Patches: 0 > > > -x--x--- > > The following changes since commit > 77b67063bb6bce6d475e910d3b886a606d0d91f7: > > Linux 3.7-rc5 (2012-11-11 13:44:33 +0100) > > are available in the git repository at: > > git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-master-v12 > > for you to fetch changes up to f942092bd1008de7379b4a52d38dc03de5949fc8: > > Merge branches 'arm-multi_pmu_v2', 'hw-bkp-v7.1-debug-v1', > 'task-placement-v2', 'misc-patches', 'config-fragments' and > 'sched-pack-small-tasks-v1' into big-LITTLE-MP-master-v12-v2 > (2012-11-17 09:29:41 +0530) > > > > Ben Segall (1): > sched: Maintain per-rq runnable averages > > Chris Redpath (1): > ARM: Experimental Frequency-Invariant Load Scaling Patch > > Dietmar Eggemann (1): > ARM: hw_breakpoint: v7.1 self-hosted debug powerdown support > > Jon Medhurst (1): > ARM: sched: Avoid empty 'slow' HMP domain > > Liviu Dudau (2): > Revert "sched: secure access to other CPU statistics" > linaro/configs: big-LITTLE-MP: Enable the new tunable sysfs > interface by default. > > 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 > > Morten Rasmussen (15): > sched: entity load-tracking load_avg_ratio > sched: Task placement for heterogeneous systems based on task > load-tracking > sched: Forced task migration on heterogeneous systems > sched: Introduce priority-based task migration filter > ARM: Add HMP scheduling support for ARM architecture > ARM: sched: Use device-tree to provide fast/slow CPU list for HMP > ARM: sched: Setup SCHED_HMP domains > sched: Add ftrace events for entity load-tracking > sched: Add HMP task migration ftrace event > sched: SCHED_HMP multi-domain task migration control > sched: Enable HMP priority filter by default > sched: Only down migrate low priority tasks if allowed by affinity > mask > linaro/configs: Enable HMP priority filter by default > sched: SD_SHARE_POWERLINE buddy selection fix > ARM: TC2: Re-enable SD_SHARE_POWERLINE > > Olivier Cozette (1): > ARM: Cha
[ANNOUNCE][Linux Linaro kernel] Re: linux-linaro kernel trees move to 3.7 and 12.11 schedule
Greetings, The linux-linaro-core-tracking tree has been updated to v3.7-rc6. The current 12.11 schedule is now: * October 30: initial v3.7-rc3 based llct build, 3.6 based topics will not be included if there are conflicts - Done. The tag is llct-20121101.1. v3.7-rc3 based. * November 6: updated big-LITTLE-MP topic arrives, llct rebuild (llct-20121106) - Done. The tag is llct-20121106.0. v3.7-rc4 based. * November 8: linux-linaro (ll) rebuild based on llct-20121106 - Done. The tag is ll-20121108.0 * November 13: llct rebuild (llct-20121113) - Done. The tag is llct-20121113.0. v3.7-rc5 based. Otherwise the only change is in the "configs" topic: babf06c configs: linaro-base: set CONFIG_AEABI=y * November 15: ll rebuild based on llct-20121113 - Done. The tag is ll-20121115.0. Origen support is back into the ll tree (the "tracking" topic from the Samsung LT). * November 20: llct rebuild (llct-20121120) - Done. The tag is llct-20121120.1. v3.7-rc6 based. This is the last scheduled llct update for 12.11. - Updates: . new version of the big.LITTLE-MP topic (big-LITTLE-MP-master-v12), . configs topic renamed to core-configs, . basic-board-configs topic added, . devfreq patches from Rajagopal Venkat added . "KBuild: Allow scripts/* to be cross compiled" patch added to llct-v3.7-misc-fixes topic - Not included into llct-20121120.1: . android perf patch from Bernhard Rosenkraenzer (patch received, but no topic branch yet): too much conflicts in tools/perf/Makefile vs v3.7-rc6 for me to resolve myself. If I get the version of this patch to apply cleanly to v3.7-rc6, it could be included right into the ll tree for 12.11. (The risk is low, as the patch makes no changes outside tools/perf). * November 22: ll rebuild based on llct-20121120.1, ll code freeze (no massive ll topics updates after that; bugfixes only) Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]; big LITTLE MP master v12
On 20 November 2012 20:06, Lei Wen wrote: > I test your updated branch, and find there is some errors: > > > # ARCH=arm scripts/kconfig/merge_config.sh > arch/arm/configs/vexpress_defconfig linaro/configs/big-LITTLE-MP.conf I don't know what's there in vexpress_defconfig. How everybody else is using this is, merge tixy integration branch with my branch (It may already have my branch). Then do merge of linaro base config, vexpress.conf, ubuntu or android.conf. All above from linaro/configs/* > Using arch/arm/configs/vexpress_defconfig as base > Merging linaro/configs/big-LITTLE-MP.conf > HOSTCC scripts/basic/fixdep > HOSTCC scripts/kconfig/conf.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/zconf.lex.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > scripts/kconfig/conf --alldefconfig Kconfig > # > # configuration written to .config > # > Value requested for CONFIG_RCU_CPU_STALL_DETECTOR not in final .config > Requested value: # CONFIG_RCU_CPU_STALL_DETECTOR is not set > Actual value: > > Value requested for CONFIG_DEBUG_ERRORS not in final .config > Requested value: CONFIG_DEBUG_ERRORS=y > Actual value: > > Value requested for CONFIG_HMP_FREQUENCY_INVARIANT_SCALE not in final > .config > Requested value: CONFIG_HMP_FREQUENCY_INVARIANT_SCALE=y > Actual value: This can happen due to some mismatched dependencies. You just need to check dependencies. Even i get lot of errors when i merge configs mentioned earlier. > > > Any suggestion for this? > > Also when launch the MP system, how could I know there already two cluster > are running? > For I only see one cpu by checking cpuinfo. > The system I am running actually is A15x1-A7x1 over fastmodel... Check cpu domain information. pass sched_debug in cmdline params and check boot prints. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 3/6] sched: pack small tasks
On 20 November 2012 15:28, Morten Rasmussen wrote:
> Hi Vincent,
>
> On Mon, Nov 12, 2012 at 01:51:00PM +, Vincent Guittot wrote:
>> On 9 November 2012 18:13, Morten Rasmussen wrote:
>> > 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.
>>
>> Hi Morten,
>>
>> Thanks for testing the patches.
>>
>> It seems that I have too optimized the loop and remove some use cases.
>>
>> >
>> > 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
>>
>> You probably wanted to use sched_group instead of cluster because
>> cluster is only a special use case, didn't you ?
>>
>> > 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.
>>
>> We don't want to pack in the current sched_domain because it shares
>> power domain. We want to pack at the parent level
>>
>
> Yes. I think we mean the same thing. The packing takes place at the
> parent sched_domain but the sched_group that we are looking at only
> contains the cpus of the level below.
>
>> >
>> > I propose the following fix:
>> >
>> > - sd = sd->parent;
>> > + if (cpumask_first(sched_domain_span(sd)) == cpu
>> > + || !sd->parent)
>> > + sd = sd->parent;
>>
>> We always look for the buddy in the parent level whatever the cpu
>> position in the mask is.
>>
>> >
>> >
>> >> +
>> >> + 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_f
Re: [PATCH] cpuidle: Measure idle state durations with monotonic clock
On Wednesday, November 14, 2012 05:56:30 PM Julius Werner wrote:
> Many cpuidle drivers measure their time spent in an idle state by
> reading the wallclock time before and after idling and calculating the
> difference. This leads to erroneous results when the wallclock time gets
> updated by another processor in the meantime, adding that clock
> adjustment to the idle state's time counter.
>
> If the clock adjustment was negative, the result is even worse due to an
> erroneous cast from int to unsigned long long of the last_residency
> variable. The negative 32 bit integer will zero-extend and result in a
> forward time jump of roughly four billion milliseconds or 1.3 hours on
> the idle state residency counter.
>
> This patch changes all affected cpuidle drivers to either use the
> monotonic clock for their measurements or make use of the generic time
> measurement wrapper in cpuidle.c, which was already working correctly.
> Some superfluous CLIs/STIs in the ACPI code are removed (interrupts
> should always already be disabled before entering the idle function, and
> not get reenabled until the generic wrapper has performed its second
> measurement). It also removes the erroneous cast, making sure that
> negative residency values are applied correctly even though they should
> not appear anymore.
>
> Signed-off-by: Julius Werner
Len, I need your ACK on intel_idle change in this patch if you agree with it.
Thanks,
Rafael
> ---
> arch/powerpc/platforms/pseries/processor_idle.c |4 +-
> drivers/acpi/processor_idle.c | 57 +-
> drivers/cpuidle/cpuidle.c |3 +-
> drivers/idle/intel_idle.c | 14 +-
> 4 files changed, 7 insertions(+), 71 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
> b/arch/powerpc/platforms/pseries/processor_idle.c
> index 45d00e5..4d806b4 100644
> --- a/arch/powerpc/platforms/pseries/processor_idle.c
> +++ b/arch/powerpc/platforms/pseries/processor_idle.c
> @@ -36,7 +36,7 @@ static struct cpuidle_state *cpuidle_state_table;
> static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t
> *kt_before)
> {
>
> - *kt_before = ktime_get_real();
> + *kt_before = ktime_get();
> *in_purr = mfspr(SPRN_PURR);
> /*
>* Indicate to the HV that we are idle. Now would be
> @@ -50,7 +50,7 @@ static inline s64 idle_loop_epilog(unsigned long in_purr,
> ktime_t kt_before)
> get_lppaca()->wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
> get_lppaca()->idle = 0;
>
> - return ktime_to_us(ktime_sub(ktime_get_real(), kt_before));
> + return ktime_to_us(ktime_sub(ktime_get(), kt_before));
> }
>
> static int snooze_loop(struct cpuidle_device *dev,
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index e8086c7..f1a5da4 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -735,31 +735,18 @@ static inline void acpi_idle_do_entry(struct
> acpi_processor_cx *cx)
> static int acpi_idle_enter_c1(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index)
> {
> - ktime_t kt1, kt2;
> - s64 idle_time;
> struct acpi_processor *pr;
> struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
> struct acpi_processor_cx *cx = cpuidle_get_statedata(state_usage);
>
> pr = __this_cpu_read(processors);
> - dev->last_residency = 0;
>
> if (unlikely(!pr))
> return -EINVAL;
>
> - local_irq_disable();
> -
> -
> lapic_timer_state_broadcast(pr, cx, 1);
> - kt1 = ktime_get_real();
> acpi_idle_do_entry(cx);
> - kt2 = ktime_get_real();
> - idle_time = ktime_to_us(ktime_sub(kt2, kt1));
> -
> - /* Update device last_residency*/
> - dev->last_residency = (int)idle_time;
>
> - local_irq_enable();
> lapic_timer_state_broadcast(pr, cx, 0);
>
> return index;
> @@ -806,19 +793,12 @@ static int acpi_idle_enter_simple(struct cpuidle_device
> *dev,
> struct acpi_processor *pr;
> struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
> struct acpi_processor_cx *cx = cpuidle_get_statedata(state_usage);
> - ktime_t kt1, kt2;
> - s64 idle_time_ns;
> - s64 idle_time;
>
> pr = __this_cpu_read(processors);
> - dev->last_residency = 0;
>
> if (unlikely(!pr))
> return -EINVAL;
>
> - local_irq_disable();
> -
> -
> if (cx->entry_method != ACPI_CSTATE_FFH) {
> current_thread_info()->status &= ~TS_POLLING;
> /*
> @@ -829,7 +809,6 @@ static int acpi_idle_enter_simple(struct cpuidle_device
> *dev,
>
> if (unlikely(need_resched())) {
> current_thread_info()->status |= TS_POLLING;
> - local_irq_enable();
> return -EINVAL;
> }
> }
>
Re: [PATCH] dt: add helper function to read u8 & u16 variables & arrays
On 11/19/2012 10:45 PM, Viresh Kumar wrote:
> This adds following helper routines:
> - of_property_read_u8_array()
> - of_property_read_u16_array()
> - of_property_read_u8()
> - of_property_read_u16()
>
> This expects arrays from DT to be passed as:
> - u8 array:
> property = /bits/ 8 <0x50 0x60 0x70>;
> - u16 array:
> property = /bits/ 16 <0x5000 0x6000 0x7000>;
>
> Signed-off-by: Viresh Kumar
Applied.
Rob
> ---
> V2->V3:
> - Expect u8 & u16 arrays to be passed using: /bits/ 8 or 16
> - remove common macro, as not much common now :(
> - Tested on ARM platform.
>
> drivers/of/base.c | 77
> ++
> include/linux/of.h | 30 +
> 2 files changed, 107 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index af3b22a..f564e31 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -671,12 +671,89 @@ struct device_node *of_find_node_by_phandle(phandle
> handle)
> EXPORT_SYMBOL(of_find_node_by_phandle);
>
> /**
> + * of_property_read_u8_array - Find and read an array of u8 from a property.
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname:name of the property to be searched.
> + * @out_value: pointer to return value, modified only if return value
> is 0.
> + * @sz: number of array elements to read
> + *
> + * Search for a property in a device node and read 8-bit value(s) from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * dts entry of array should be like:
> + * property = /bits/ 8 <0x50 0x60 0x70>;
> + *
> + * The out_value is modified only if a valid u8 value can be decoded.
> + */
> +int of_property_read_u8_array(const struct device_node *np,
> + const char *propname, u8 *out_values, size_t sz)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> + const u8 *val;
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> + if ((sz * sizeof(*out_values)) > prop->length)
> + return -EOVERFLOW;
> +
> + val = prop->value;
> + while (sz--)
> + *out_values++ = *val++;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_property_read_u8_array);
> +
> +/**
> + * of_property_read_u16_array - Find and read an array of u16 from a
> property.
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname:name of the property to be searched.
> + * @out_value: pointer to return value, modified only if return value
> is 0.
> + * @sz: number of array elements to read
> + *
> + * Search for a property in a device node and read 16-bit value(s) from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * dts entry of array should be like:
> + * property = /bits/ 16 <0x5000 0x6000 0x7000>;
> + *
> + * The out_value is modified only if a valid u16 value can be decoded.
> + */
> +int of_property_read_u16_array(const struct device_node *np,
> + const char *propname, u16 *out_values, size_t sz)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> + const __be16 *val;
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> + if ((sz * sizeof(*out_values)) > prop->length)
> + return -EOVERFLOW;
> +
> + val = prop->value;
> + while (sz--)
> + *out_values++ = be16_to_cpup(val++);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_property_read_u16_array);
> +
> +/**
> * of_property_read_u32_array - Find and read an array of 32 bit integers
> * from a property.
> *
> * @np: device node from which the property value is to be read.
> * @propname:name of the property to be searched.
> * @out_value: pointer to return value, modified only if return value
> is 0.
> + * @sz: number of array elements to read
> *
> * Search for a property in a device node and read 32-bit value(s) from
> * it. Returns 0 on success, -EINVAL if the property does not exist,
> diff --git a/include/linux/of.h b/include/linux/of.h
> index b4e50d5..bfdc130 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -223,6 +223,10 @@ extern struct device_node *of_find_node_with_property(
> extern struct property *of_find_property(const struct device_node *np,
>const char *name,
>int *lenp);
> +extern int of_property_read_u8_array(const struct device_node *np,
> + const char *propname
Exynos5 binary blobs situation on devices running GNU/Linux
Hello everybody
This time I want to post some information and questions about binary
blobs situation on Exynos5 devices. It means Samsung Chromebook and
Andale Board (I do not have data about other Exynos5 powered devices).
Chromebook ships with Chromium OS and under it has working OpenGL ES and
OpenMAX based video acceleration. I was able to play 1080p YouTube
videos both on internal and external screen without any slowdown.
But under normal GNU/Linux systems (Debian, Fedora, OpenSUSE, Ubuntu)
there is none of it...
We got OpenGL ES running by copying libmali and all symlinks pointing to
it (lib{EGL,GLES} etc) and taking care of /dev/mali* permissions. But we
can not make packages with it for our distibutions because of lack of
any license for it. Normal "this is proprietary binary, do not hack it
etc but you can distribute it freely" kind of license will be enough.
Android binaries for OpenGL ES are available for Andale Board. GNU/Linux
ones can be extracted from Chromebook recovery image (363MB download
extracting to ~1GB file). But lack of license anyway.
I know that we have ARM Ltd. people here, same with Samsung - maybe
someone can tell us what is going on in this area?
Other thing is video acceleration. I do not know is there a source for
it available or not. This is area where I do not have knowledge needed
to get it running. All I know is that Exynos5 itself is able to play
480p DivX encoded movie - did not yet tried 720p or 1080p ones but do
not think it will make it on it own.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
