linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

RE: Kernel fixes for HW watchpoint support

by Ulrich Weigand

"Will Deacon" <will.deacon(a)arm.com> wrote on 02/21/2011 06:56:13 PM: > > > - On (some versions of?) Versatile Express SMP Cortex-A9 SMP boards, a CPU > > > errata (#720789) causes TLB flushes to sometime fail, which can lead to > > > random problems when running GDB in SMP mode (and probably elsewhere). > > > There is a kernel work-around for this problem activated by > > > CONFIG_ARM_ERRATA_720789, but this is unfortuantely not active on the > > > Linaro kernels. (On OMAP4, this happens automatically due to an entry in > > > mach-omap2/Kconfig. There is no such entry in mach-vexpress/Kconfig > > > currently.) > > > > Could you send a patch to Russell for that? > > I have a patch that enables some other workarounds that we probably > want enabled for the VE as well. Great, thanks! > I can CC you (Ulrich) on that if you'd prefer? Sure, that's fine with me ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 1 month

About the precision of ftrace in kernel

by Yong Shen

Hi there, When I am trying to use ftrace to measure cpuidle latency, I find that the timestamp is always ending with 0000, like below. bash-2.05b# head trace # tracer: nop # # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | <idle>-0 [000] 79.530000: cpu_idle: state=0 cpu_id=0 <idle>-0 [000] 79.530000: cpu_idle: state=4294967295 cpu_id=0 <idle>-0 [000] 79.530000: cpu_idle: state=0 cpu_id=0 <idle>-0 [000] 79.530000: cpu_idle: state=4294967295 cpu_id=0 <idle>-0 [000] 79.530000: cpu_idle: state=0 cpu_id=0 <idle>-0 [000] 79.530000: cpu_idle: state=4294967295 cpu_id=0 But it is supposed to be more accurate like: <idle>-0 [000] 270.396210: cpu_idle: state=4294967295 cpu_id=0 <idle>-0 [000] 270.422424: cpu_idle: state=0 cpu_id=0 <idle>-0 [000] 270.427124: cpu_idle: state=4294967295 cpu_id=0 <idle>-0 [000] 270.427185: cpu_idle: state=2 cpu_id=0 Did I miss something in kernel configuration or some certain features? Thanks Yong

15 years, 1 month

Re: [PATCH] CPUFREQ : calculate delay after dbs_check_cpu

by Vincent Guittot

Hi, The ondemand delay value is calculated before calling dbs_check_cpu which can lead to a delay value of sampling_rate*sampling_down_factor but a frequency set to the lowest value. The main result is a slow responsiveness during this period. This patch moves the calculation of delay after the call of dbs_check_cpu. I have seen this problem when testing cpufreq-bench on my Arm platform. Vincent On 7 February 2011 17:14, Vincent Guittot <vincent.guittot(a)linaro.org> wrote: > calculate ondemand delay after dbs_check_cpu call because it can > modify rate_mult value > > use freq_lo_jiffies value for the sub sample period of powersave_bias mode > > Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org> > --- > drivers/cpufreq/cpufreq_ondemand.c | 20 +++++++++++++------- > 1 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq_ondemand.c > b/drivers/cpufreq/cpufreq_ondemand.c > index 58aa85e..44c2dba 100644 > --- a/drivers/cpufreq/cpufreq_ondemand.c > +++ b/drivers/cpufreq/cpufreq_ondemand.c > @@ -641,13 +641,7 @@ static void do_dbs_timer(struct work_struct *work) > container_of(work, struct cpu_dbs_info_s, work.work); > unsigned int cpu = dbs_info->cpu; > int sample_type = dbs_info->sample_type; > - > - /* We want all CPUs to do sampling nearly on same jiffy */ > - int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate > - * dbs_info->rate_mult); > - > - if (num_online_cpus() > 1) > - delay -= jiffies % delay; > + int delay; > > mutex_lock(&dbs_info->timer_mutex); > > @@ -660,10 +654,22 @@ static void do_dbs_timer(struct work_struct *work) > /* Setup timer for SUB_SAMPLE */ > dbs_info->sample_type = DBS_SUB_SAMPLE; > delay = dbs_info->freq_hi_jiffies; > + } else { > + /* We want all CPUs to do sampling nearly on > + * same jiffy > + */ > + delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate > + * dbs_info->rate_mult); > + > + if (num_online_cpus() > 1) > + delay -= jiffies % delay; > + > } > + > } else { > __cpufreq_driver_target(dbs_info->cur_policy, > dbs_info->freq_lo, CPUFREQ_RELATION_H); > + delay = dbs_info->freq_lo_jiffies; > } > schedule_delayed_work_on(cpu, &dbs_info->work, delay); > mutex_unlock(&dbs_info->timer_mutex); > -- > 1.7.1 >

15 years, 1 month

Patch subject for complex project like Android (was: Re: [PATCH v2] device/linaro/beagleboard: Install 0xbench native applications)

by Jim Huang

2011/2/21 Jason Kridner <jkridner(a)beagleboard.org>: > How about putting it inside the [PATCH xxx], ie. "[PATCH v3 android] > device/linaro/beagleboard: Install 0xbench native applications"? When > I go to git.linaro.org, this would give me enough information to > figure out to which tree this patch applied. For that matter, isn't > "device/linaro/beagleboard" redundant as a comment within that tree? > Why not just do "[PATCH v3 android/device/linaro/beagleboard] Install > 0xbench native applications"? hi Jason, I completely agree with you. Also, your idea matches the layout of git.linaro.org . Thanks a lot! -jserv

15 years, 1 month

Board Support Review deadline this Thursday 24th February

by Jamie Bennett

Hi, Along with Feature Freeze [1], Thursday sees Linaro's Board Support Review deadline. This deadline marks the start of the process to define exactly what hardware will be enabled in the final Linaro Evaluation Builds released at the end of the cycle [2]. This review is to ensure that the target hardware support is progressing as expected and that the final user experience will shine on these boards. For more information on the Board Support Review deadline please see the Linaro wiki at: https://wiki.linaro.org/Process/Cycle/BoardReview There will be another review on 2011-03-24 where the list will be refined if necessary. A list of boards that Linaro expects to enable this cycle will be circulated after the review. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager Office: +44 1761 348 220 | Mobile: +44 7962 259 437 [1] http://lists.linaro.org/pipermail/linaro-dev/2011-February/002702.html [2] https://wiki.linaro.org/Releases/1105

15 years, 1 month

[PATCH, android device/linaro/common.git] Added target roottarball

by Patrik Ryd

>From e2ce2661169a8653c86112d4dd0d5ac99fbe6925 Mon Sep 17 00:00:00 2001 From: Patrik Ryd <patrik.ryd(a)linaro.org> Date: Mon, 21 Feb 2011 09:49:56 +0100 Subject: [PATCH] Added target roottarball The new taget roottarball creates a tarball of the root file system. --- tasks/tarballs.mk | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 tasks/tarballs.mk diff --git a/tasks/tarballs.mk b/tasks/tarballs.mk new file mode 100644 index 0000000..e569e98 --- /dev/null +++ b/tasks/tarballs.mk @@ -0,0 +1,25 @@ +# +# Trigger build of tar balls for the linaro boards +# + +####### +## root tarball +define build-roottarball-target + $(hide) echo "Target root fs tarball:" $(INSTALLED_ROOTTARBALL_TARGET) + $(hide) $(MKTARBALL) $(FS_GET_STATS) \ + $(PRODUCT_OUT)/root . $(PRIVATE_ROOT_TAR) \ + $(INSTALLED_ROOTTARBALL_TARGET) +endef + +ifndef ROOT_TARBALL_FORMAT + ROOT_TARBALL_FORMAT := bz2 +endif + +root_tar := $(PRODUCT_OUT)/root.tar +INSTALLED_ROOTTARBALL_TARGET := $(root_tar).$(ROOT_TARBALL_FORMAT) + +$(INSTALLED_ROOTTARBALL_TARGET): PRIVATE_ROOT_TAR := $(root_tar) +$(INSTALLED_ROOTTARBALL_TARGET): $(FS_GET_STATS) $(INTERNAL_RAMDISK_FILES) + $(build-roottarball-target) + +roottarball: $(INSTALLED_ROOTTARBALL_TARGET) \ No newline at end of file -- 1.7.1

15 years, 1 month

Please reply if you got a U8500 board

by Per Forlin

Hi, Dave told me he got 3 u8500 boards but no UART break out board. From what I have heard the u8500 boards for Linaro should come with a full kit including power supply and UART. If you have a u8500 board please let me know if it contains a UART break out board or whether it is missing. Thanks, Per

15 years, 1 month

Feature Freeze this Thursday 24th February

by Jamie Bennett

Hi, Thursday 24th February is Feature Freeze. This is a point in the Engineering Cycle [1] where we stop taking new features and concentrate on fixing bugs. Please get your new features (as defined by new packages, API changes, additional features) proposed and uploaded to the archive as soon as possible. If you know of any features that will not make the deadline please make the Release Manager (me) aware of these and be prepared for the Feature Freeze Exception Process, an explanation of which can be found at: https://wiki.linaro.org/Process/Cycle/FreezeExceptionProcess To read more about the Feature Freeze deadline head on over to: https://wiki.linaro.org/Process/Cycle/FeatureFreeze Regards, Jamie. -- Linaro Release Manager [1] https://wiki.linaro.org/Releases/1105/Schedule

15 years, 1 month

Notes & Actions: Linaro Graphics Working Group - Feb 16, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-02-16 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Summary ======= * cairo-gles: Patchset "EGL fixes" sent upstream for review: http://lists.cairographics.org/archives/cairo/2011-February/021687.html * cairo-gles: Work in progress for replacing remaining GL only features (GL_CLAMP_TO_BORDER, 1D Textures). * kwin: Succeed to run kwin on imx51 and fixed flickering issue, patch accepted by kwin upstream: http://commits.kde.org/kde-workspace/341d4f90b7e45f92813d8362ff21c6f4b7ba96… * Jammy got KDE developer account (thanks to Martin) * drm/mali: Verified that Mali drivers worked with sample 3D application on Linaro kernel. * compiz-gles: Immediate mode replaced with vertex arrays. * compiz-gles: rendering now using shaders with built-in variables (replacement of built-ins in progress) Thanks, -- - Alexandros

15 years, 1 month

Subject: [PATCH] Added target roottatball

by Patrik Ryd

>From 0af38129a04da9c7b621ba0bde2bd90980ad9756 Mon Sep 17 00:00:00 2001 From: Patrik Ryd <patrik.ryd(a)linaro.org> Date: Mon, 21 Feb 2011 09:49:56 +0100 Subject: [PATCH] Added target roottatball The new taget roottarball creates a tarball of the root file system. --- tasks/tarballs.mk | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 tasks/tarballs.mk diff --git a/tasks/tarballs.mk b/tasks/tarballs.mk new file mode 100644 index 0000000..0c51644 --- /dev/null +++ b/tasks/tarballs.mk @@ -0,0 +1,25 @@ +# +# Trigger build of tar balls for the linaro boards +# + +####### +## root tarball +define build-roottarball-target + $(hide) echo "Target root fs tarball:" $(INSTALLED_ROOTTARBALL_TARGET) + $(hide) $(MKTARBALL) $(FS_GET_STATS) \ + $(PRODUCT_OUT) root $(PRIVATE_ROOT_TAR) \ + $(INSTALLED_ROOTTARBALL_TARGET) +endef + +ifndef ROOT_TARBALL_FORMAT + ROOT_TARBALL_FORMAT := bz2 +endif + +root_tar := $(PRODUCT_OUT)/root.tar +INSTALLED_ROOTTARBALL_TARGET := $(root_tar).$(BOOT_TARBALL_FORMAT) + +$(INSTALLED_ROOTTARBALL_TARGET): PRIVATE_ROOT_TAR := $(root_tar) +$(INSTALLED_ROOTTARBALL_TARGET): $(FS_GET_STATS) $(INTERNAL_RAMDISK_FILES) + $(build-roottarball-target) + +roottarball: $(INSTALLED_ROOTTARBALL_TARGET) \ No newline at end of file -- 1.7.1

15 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev