Re: [PATCH] CPUFREQ : calculate delay after dbs_check_cpu
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.guit...@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.guit...@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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA scheduler spec
I have now updated the spec with your comments, thanks! https://wiki.linaro.org/Platform/Validation/Specs/ValidationScheduler On 11 February 2011 06:52, Paul Larson paul.lar...@linaro.org wrote: Ah, you are correct, that's excellent - a user story in the scheduler should then look something like this: Dave wants to rerun a previous test job from test job history. Comments? This would basically be a resubmit job feature, that would replicate the same parameters as the original job. As for some of the other things mentioned here, yes it has always been our intent that you should be able to request a job to run on a specific machine. This is, in fact, the simplest thing to do. As a step up from that, we should provide a way to say Run this on any single panda board, and the scheduler should be able to pick one from the list that has the least (hopefully 0) jobs queued. Thanks, Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please review blueprint linaro-n-validation-job-dispatcher
On 28 January 2011 08:12, Paul Larson paul.lar...@linaro.org wrote: Other questions... What does it do after running the test? How, and where does it leave the results? What get's added to the results (e.g. serial log) and how does that happen? What is the mechanism for then taking that bundle and pushing to the server? What happens if there were no results from the client, what do we capture in that case? About the test result, I draft a test result bundle template, for a job test result bundle, it is stored in a text file. Dispatcher server part will get the return value of the test case and the serial port log, then create test result together with some info from job message, client dispatcher test logs. I think server dispatcher can fetch the client test logs initiatively after client dispatcher ends. If there is no result from the client, after timeout, 1. server dispatcher send some Ctrl+C to client dispatcher to end it. 2. then restart the client dispatcher. 3. try to get the client dispatcher remained test logs. 4. mark the test case to TIMEOUT and create the test result. PS. If step 1 can not end the client dispatcher, it may need a reboot for server dispatcher have lost the control of serial line. Test result bundle composed of every test case result, for each test case result, it includes: - LOG casename:Test case name testsuite:Test suite name testcmd:Test case Command timeout:Timeout retvalue:Return value version:kernel version(by cat /proc/version) seriallog: serial port log ENDLOG e.g. - LOG casename:PERF001 testsuite:abrek testcmd:x11perf timeout:6 retvalue:0 version:2.6.35- seriallog: xxx xxx xxx ENDLOG And a test result bundle: LOG casename:PERF001 testsuite:abrek testcmd:x11perf timeout:6 retvalue:0 version:2.6.35- seriallog: xxx xxx xxx ENDLOG LOG casename:USB002 testsuite:abrek testcmd:usb_app timeout:6 retvalue:0 version:2.6.35- seriallog: yyy yyy yyy ENDLOG What do you think? The flow to get test result: 1. Server dispatcher sends commands to client dispatcher via serial line to invoke client dispatcher, capture all the serial log and wait for the client dispatcher ends. 2. Client dispatcher executes the command, save logs to some place on the board. 3. If client dispatcher ends normally(return to the root@testimage:~$ string), server dispatcher uses echo $? to get the return value. Or terminate the client dispatcher after timeout. 4. Server dispatcher gets client dispatcher test logs. 5. Server dispatcher uses the collected information to create test result. -- Best wishes, Spring Zhang ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC] ARM: dma-mapping: outer cache is invalidated twice
Hi,
My question concerns this patch
commit 2ffe2da3e71652d4f4cae19539b5c78c2a239136
Author: Russell King rmk+ker...@arm.linux.org.uk
Date: Sat Oct 31 16:52:16 2009 +
ARMv6 and ARMv7 CPUs can perform speculative prefetching, which makes
DMA cache coherency handling slightly more interesting. Rather than
being able to rely upon the CPU not accessing the DMA buffer until DMA
has completed, we now must expect that the cache could be loaded with
possibly stale data from the DMA buffer.
Where DMA involves data being transferred to the device, we clean the
cache before handing it over for DMA, otherwise we invalidate the buffer
to get rid of potential writebacks. On DMA Completion, if data was
transferred from the device, we invalidate the buffer to get rid of
any stale speculative prefetches.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-By: Santosh Shilimkar santosh.shilim...@ti.com
-
file: arch/arm/mm/dma-mapping.c
void ___dma_page_cpu_to_dev(struct page *page, unsigned long off,
size_t size, enum dma_data_direction dir)
{
...
if (dir == DMA_FROM_DEVICE) {
outer_inv_range(paddr, paddr + size);
...
}
EXPORT_SYMBOL(___dma_page_cpu_to_dev);
void ___dma_page_dev_to_cpu(struct page *page, unsigned long off,
size_t size, enum dma_data_direction dir)
{
...
if (dir != DMA_TO_DEVICE)
outer_inv_range(paddr, paddr + size);
...
}
outer_inv_range () is called twice for DMA_FROM_DEVICE.
The first time to get rid of potential writebacks and the second
time to get rid of any stale speculative prefetches
outer_inv_range() is a rather expensive operation. In the first case
isn't it enough to just call cache_sync()?
What about:
void ___dma_page_cpu_to_dev(struct page *page, unsigned long off,
size_t size, enum dma_data_direction dir)
{
...
if (dir == DMA_FROM_DEVICE) {
- outer_inv_range(paddr, paddr + size);
+ outer_sync();
...
}
/Per
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Notes Actions: Linaro Graphics Working Group - Feb 09, 2011
On Fri, Feb 11, 2011 at 7:47 AM, Alexandros Frantzis alexandros.frant...@linaro.org wrote: * First version of Unified Memory Management position: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement btw, the access control aspect of this sort of reminds me of the DRM driver infrastructure, and authentication between direct rendering client and x-server (or whoever the DRM master is).. I wonder if there is, or should be, a connection.. BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] ARM: dma-mapping: outer cache is invalidated twice
On Tue, Feb 15, 2011 at 02:14:55PM +0100, Per Forlin wrote: outer_inv_range () is called twice for DMA_FROM_DEVICE. The first time to get rid of potential writebacks and the second time to get rid of any stale speculative prefetches Correct. outer_inv_range() is a rather expensive operation. In the first case isn't it enough to just call cache_sync()? No. If the CPU speculatively fetches data from the DMA buffer after it's been mapped for DMA, it will bring data into the L2 cache. This data may or may not be up to date with the DMA buffer contents once DMA has completed. As there is no way to know, we have to invalidate the L2 cache (and the L1 cache) after the DMA has completed to avoid any possibility of data corruption. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] ARM: dma-mapping: outer cache is invalidated twice
On 15 February 2011 14:41, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 15, 2011 at 01:32:32PM +, Russell King - ARM Linux wrote: On Tue, Feb 15, 2011 at 02:14:55PM +0100, Per Forlin wrote: outer_inv_range () is called twice for DMA_FROM_DEVICE. The first time to get rid of potential writebacks and the second time to get rid of any stale speculative prefetches Correct. outer_inv_range() is a rather expensive operation. In the first case isn't it enough to just call cache_sync()? No. If the CPU speculatively fetches data from the DMA buffer after it's been mapped for DMA, it will bring data into the L2 cache. This data may or may not be up to date with the DMA buffer contents once DMA has completed. As there is no way to know, we have to invalidate the L2 cache (and the L1 cache) after the DMA has completed to avoid any possibility of data corruption. I should add: the solution to all of this is to have cache coherent DMA. As the CPUs become more complex and start playing tricks like speculative prefetching, we have seen cache maintainence for DMA becomes more expensive. The only way to reduce the cost of that is to have cache coherency for DMA. There is no way to safely avoid the double-invalidate for DMA_FROM_DEVICE. I don't fully understand this yet. I think you are right but I need a little help to get there myself. I agree, the cache (L1 and L2) must be invalidated after the DMA has completed. Before starting the DMA the write buffers must be drained (cache_sync). Why invalidate the cache before starting the DMA? The user shouldn't care about the cache until the DMA has finished and the cache is invalidated. I don't unsderstand how the DMA transfered data can be corrupt from a CPU perspective if the cache is invalidated after DMA transfer is done, but _not_ before DMA is started? Thanks for your fast response /Per ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linaro-android][PATCH] device/linaro/u8500href: Install 0xbench native applications
Hi, Looks good to me. I will push it to git.linaro.org. /Patrik On 15 February 2011 05:30, Jeremy Chang jer...@0xlab.org wrote: From 78b170843eadf0e72d6b0d4cb0fc5f3be5edcae8 Mon Sep 17 00:00:00 2001 From: Jeremy Chang jer...@0xlab.org Date: Tue, 15 Feb 2011 12:17:16 +0800 Subject: [PATCH] Install 0xbench native applications Signed-off-by: Jeremy Chang jer...@0xlab.org --- ZeroXBenchmark.mk | 96 + u8500href.mk |5 ++- 2 files changed, 100 insertions(+), 1 deletions(-) create mode 100644 ZeroXBenchmark.mk diff --git a/ZeroXBenchmark.mk b/ZeroXBenchmark.mk new file mode 100644 index 000..e78047d --- /dev/null +++ b/ZeroXBenchmark.mk @@ -0,0 +1,96 @@ +UNIXBENCH_BENCH_APPS := \ +bench_ubench_hanoi \ +bench_ubench_syscall\ +bench_ubench_context1 \ +bench_ubench_pipe \ +bench_ubench_spawn \ +bench_ubench_execl \ +bench_ubench_looper \ +bench_ubench_fstime \ +bench_ubench_arithoh\ +bench_ubench_register \ +bench_ubench_short \ +bench_ubench_int\ +bench_ubench_long \ +bench_ubench_float \ +bench_ubench_double \ +bench_ubench_dhry2 \ +bench_ubench_dhry2reg \ +bench_ubench_whetstone-double + +LIBMICRO_BENCH_APPS := \ +bench_getpid\ +bench_bind \ +bench_cascade_mutex \ +bench_cascade_fcntl \ +bench_cascade_flock \ +bench_chdir \ +bench_close \ +bench_close_tcp \ +bench_connection\ +bench_dup \ +bench_exec \ +bench_exit \ +bench_exp \ +bench_fcntl \ +bench_fcntl_ndelay \ +bench_file_lock \ +bench_fork \ +bench_getenv\ +bench_gettimeofday \ +bench_getpeername \ +bench_getrusage \ +bench_getsockname \ +bench_isatty\ +bench_listen\ +bench_localtime_r \ +bench_log \ +bench_longjmp \ +bench_lrand48 \ +bench_lseek \ +bench_malloc\ +bench_memcpy\ +bench_memmove \ +bench_memrand \ +bench_memset\ +bench_mktime\ +bench_mprotect \ +bench_mmap \ +bench_msync \ +bench_munmap\ +bench_mutex \ +bench_nop \ +bench_open \ +bench_pipe \ +bench_poll \ +bench_pread \ +bench_pthread_create\ +bench_pwrite\ +bench_read \ +bench_realpath \ +bench_recurse \ +bench_select\ +bench_setsockopt\ +bench_sigaction \ +bench_siglongjmp\ +bench_signal\ +bench_sigprocmask \ +bench_socket\ +bench_socketpair\ +bench_stat \ +bench_strcasecmp\ +bench_strchr\ +bench_strcmp\ +bench_strcpy\ +bench_strftime \ +bench_strlen\ +bench_strtol\ +bench_system\ +bench_time \ +bench_times \ +bench_write \ +bench_writev + +ZEROXBENCHMARK_NATIVE_APPS := \ +$(UNIXBENCH_BENCH_APPS) \ +$(LIBMICRO_BENCH_APPS) diff --git a/u8500href.mk b/u8500href.mk index 3efd467..37a9eab 100644 --- a/u8500href.mk +++ b/u8500href.mk @@ -1,5 +1,7 @@ # The beagleboard product that is specialized for beagleboard. +include $(LOCAL_PATH)/ZeroXBenchmark.mk + PRODUCT_PACKAGES := \ ZeroXBenchmark \ libmicro \ @@ -22,7 +24,8 @@ PRODUCT_PACKAGES := \ Sync \ Updater \ CalendarProvider \ -SyncProvider +SyncProvider \ +$(ZEROXBENCHMARK_NATIVE_APPS) $(call inherit-product, $(SRC_TARGET_DIR)/product/core.mk) -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linaro-android][PATCH] device/linaro/pandaboard: Install 0xbench native applications
Hi, Looks good to me. I will push it to git.linaro.org. /Patrik On 15 February 2011 05:28, Jeremy Chang jer...@0xlab.org wrote: From 8d63ba7ae90b3629dd60eeab12fdc28a8dcc58e7 Mon Sep 17 00:00:00 2001 From: Jeremy Chang jer...@0xlab.org Date: Tue, 15 Feb 2011 12:10:02 +0800 Subject: [PATCH] Install 0xbench native applications Signed-off-by: Jeremy Chang jer...@0xlab.org --- ZeroXBenchmark.mk | 96 + pandaboard.mk |5 ++- 2 files changed, 100 insertions(+), 1 deletions(-) create mode 100644 ZeroXBenchmark.mk diff --git a/ZeroXBenchmark.mk b/ZeroXBenchmark.mk new file mode 100644 index 000..e78047d --- /dev/null +++ b/ZeroXBenchmark.mk @@ -0,0 +1,96 @@ +UNIXBENCH_BENCH_APPS := \ +bench_ubench_hanoi \ +bench_ubench_syscall\ +bench_ubench_context1 \ +bench_ubench_pipe \ +bench_ubench_spawn \ +bench_ubench_execl \ +bench_ubench_looper \ +bench_ubench_fstime \ +bench_ubench_arithoh\ +bench_ubench_register \ +bench_ubench_short \ +bench_ubench_int\ +bench_ubench_long \ +bench_ubench_float \ +bench_ubench_double \ +bench_ubench_dhry2 \ +bench_ubench_dhry2reg \ +bench_ubench_whetstone-double + +LIBMICRO_BENCH_APPS := \ +bench_getpid\ +bench_bind \ +bench_cascade_mutex \ +bench_cascade_fcntl \ +bench_cascade_flock \ +bench_chdir \ +bench_close \ +bench_close_tcp \ +bench_connection\ +bench_dup \ +bench_exec \ +bench_exit \ +bench_exp \ +bench_fcntl \ +bench_fcntl_ndelay \ +bench_file_lock \ +bench_fork \ +bench_getenv\ +bench_gettimeofday \ +bench_getpeername \ +bench_getrusage \ +bench_getsockname \ +bench_isatty\ +bench_listen\ +bench_localtime_r \ +bench_log \ +bench_longjmp \ +bench_lrand48 \ +bench_lseek \ +bench_malloc\ +bench_memcpy\ +bench_memmove \ +bench_memrand \ +bench_memset\ +bench_mktime\ +bench_mprotect \ +bench_mmap \ +bench_msync \ +bench_munmap\ +bench_mutex \ +bench_nop \ +bench_open \ +bench_pipe \ +bench_poll \ +bench_pread \ +bench_pthread_create\ +bench_pwrite\ +bench_read \ +bench_realpath \ +bench_recurse \ +bench_select\ +bench_setsockopt\ +bench_sigaction \ +bench_siglongjmp\ +bench_signal\ +bench_sigprocmask \ +bench_socket\ +bench_socketpair\ +bench_stat \ +bench_strcasecmp\ +bench_strchr\ +bench_strcmp\ +bench_strcpy\ +bench_strftime \ +bench_strlen\ +bench_strtol\ +bench_system\ +bench_time \ +bench_times \ +bench_write \ +bench_writev + +ZEROXBENCHMARK_NATIVE_APPS := \ +$(UNIXBENCH_BENCH_APPS) \ +$(LIBMICRO_BENCH_APPS) diff --git a/pandaboard.mk b/pandaboard.mk index 2aca6a5..b7aab1c 100644 --- a/pandaboard.mk +++ b/pandaboard.mk @@ -1,5 +1,7 @@ # The pandaboard product that is specialized for pandaboard. +include $(LOCAL_PATH)/ZeroXBenchmark.mk + PRODUCT_PACKAGES := \ ZeroXBenchmark \ libmicro \ @@ -22,7 +24,8 @@ PRODUCT_PACKAGES := \ Sync \ Updater \ CalendarProvider \ -SyncProvider +SyncProvider \ +$(ZEROXBENCHMARK_NATIVE_APPS) $(call inherit-product, $(SRC_TARGET_DIR)/product/core.mk) -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linaro-android][PATCH] Install 0xbench native applications
Hi, Looks good to me. I will push it to git.linaro.org. /Patrik On 14 February 2011 11:08, Jeremy Chang jer...@0xlab.org wrote: From 9a8781bb34fe1ff3463a1dc48f3b33b43e2f Mon Sep 17 00:00:00 2001 From: Jeremy Chang jer...@0xlab.org Date: Sun, 13 Feb 2011 20:49:26 +0800 Subject: [PATCH] Install 0xbench native applications Signed-off-by: Jeremy Chang jer...@0xlab.org --- ZeroXBenchmark.mk | 96 + beagleboard.mk|6 +++- 2 files changed, 101 insertions(+), 1 deletions(-) create mode 100644 ZeroXBenchmark.mk diff --git a/ZeroXBenchmark.mk b/ZeroXBenchmark.mk new file mode 100644 index 000..e78047d --- /dev/null +++ b/ZeroXBenchmark.mk @@ -0,0 +1,96 @@ +UNIXBENCH_BENCH_APPS := \ +bench_ubench_hanoi \ +bench_ubench_syscall\ +bench_ubench_context1 \ +bench_ubench_pipe \ +bench_ubench_spawn \ +bench_ubench_execl \ +bench_ubench_looper \ +bench_ubench_fstime \ +bench_ubench_arithoh\ +bench_ubench_register \ +bench_ubench_short \ +bench_ubench_int\ +bench_ubench_long \ +bench_ubench_float \ +bench_ubench_double \ +bench_ubench_dhry2 \ +bench_ubench_dhry2reg \ +bench_ubench_whetstone-double + +LIBMICRO_BENCH_APPS := \ +bench_getpid\ +bench_bind \ +bench_cascade_mutex \ +bench_cascade_fcntl \ +bench_cascade_flock \ +bench_chdir \ +bench_close \ +bench_close_tcp \ +bench_connection\ +bench_dup \ +bench_exec \ +bench_exit \ +bench_exp \ +bench_fcntl \ +bench_fcntl_ndelay \ +bench_file_lock \ +bench_fork \ +bench_getenv\ +bench_gettimeofday \ +bench_getpeername \ +bench_getrusage \ +bench_getsockname \ +bench_isatty\ +bench_listen\ +bench_localtime_r \ +bench_log \ +bench_longjmp \ +bench_lrand48 \ +bench_lseek \ +bench_malloc\ +bench_memcpy\ +bench_memmove \ +bench_memrand \ +bench_memset\ +bench_mktime\ +bench_mprotect \ +bench_mmap \ +bench_msync \ +bench_munmap\ +bench_mutex \ +bench_nop \ +bench_open \ +bench_pipe \ +bench_poll \ +bench_pread \ +bench_pthread_create\ +bench_pwrite\ +bench_read \ +bench_realpath \ +bench_recurse \ +bench_select\ +bench_setsockopt\ +bench_sigaction \ +bench_siglongjmp\ +bench_signal\ +bench_sigprocmask \ +bench_socket\ +bench_socketpair\ +bench_stat \ +bench_strcasecmp\ +bench_strchr\ +bench_strcmp\ +bench_strcpy\ +bench_strftime \ +bench_strlen\ +bench_strtol\ +bench_system\ +bench_time \ +bench_times \ +bench_write \ +bench_writev + +ZEROXBENCHMARK_NATIVE_APPS := \ +$(UNIXBENCH_BENCH_APPS) \ +$(LIBMICRO_BENCH_APPS) diff --git a/beagleboard.mk b/beagleboard.mk index c10e0fa..f810f36 100644 --- a/beagleboard.mk +++ b/beagleboard.mk @@ -1,5 +1,7 @@ # The beagleboard product that is specialized for beagleboard. +include $(LOCAL_PATH)/ZeroXBenchmark.mk + PRODUCT_PACKAGES := \ ZeroXBenchmark \ libmicro \ @@ -22,7 +24,9 @@ PRODUCT_PACKAGES := \ Sync \ Updater \ CalendarProvider \ -SyncProvider +SyncProvider \ +$(ZEROXBENCHMARK_NATIVE_APPS) + $(call inherit-product, $(SRC_TARGET_DIR)/product/core.mk) -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ST-Ericsson launches the Igloo open source community
http://eetimes.eu/en/st-ericsson-launches-the-igloo-open-source-community.html?cmp_id=7news_id=222905920vID=209# =:-D ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] ARM: dma-mapping: outer cache is invalidated twice
On Tue, Feb 15, 2011 at 02:54:21PM +0100, Per Forlin wrote: I don't fully understand this yet. I think you are right but I need a little help to get there myself. I agree, the cache (L1 and L2) must be invalidated after the DMA has completed. Before starting the DMA the write buffers must be drained (cache_sync). Why invalidate the cache before starting the DMA? Think about what happens if you have dirty cache lines in the DMA region. These can be evicted when other cache lines are loaded, which will result in them overwriting contents of memory. If the DMA device has already written to that memory, the result is data corruption. So, the invalidate prior to DMA is to get rid of any dirty cache lines which could be written back to memory. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 09 February 2011, Sascha Hauer wrote: The driver patch itself is Cced to linux-fbdev, only the introductory mail is not. Ok, I see. Did you consider making the driver a KMS driver instead of a frame buffer? I think the recommendation these days is to start out with KMS for new drivers, which will be somewhat simpler and give you a frame buffer device as well. I don't think that there is a need to change over any drivers from fb to kms though, since you've already done the work. I tried doing so for the i.MX51 which supports multiple displays on dvi and vga outputs and thus could make good use of KMS and friends. Anyway, I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI and needs many many callbacks to implement. Additionally the userspace tools expect a nvidia/amd/intel driver and do not have a generic fallback. I think this stuff is good for implementing a full blown graphics driver, but is lacking support for simple framebuffer grapics. I'd love to go this way but it still requires a lot of work. Ok. This sounds like a lot of upfront work indeed, to make KMS more generic, though I think a number of driver would benefit from it eventually. It could be something for the Linaro graphics working group to look at in the following 11.11 release, depending on how many other people are interested in getting there. fwiw, it seems to me like xorg could have some more common code to deal with the KMS part of DRM.. the various userspace xorg drivers end up having a lot of very similar code to deal with enumerating CRTCs/outputs and modes, handle hotplug, etc. I'd been experimenting a bit on the side w/ the DRM driver framework ( http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu ), but had to add a good chunk of mostly boilerplate code to our xorg driver in order just to test it. Maybe some generic support for KMS in xf86-video-fbdev would have made this easier to develop the kernel part without in parallel having to implement the userspace part. I'm not sure if this is the sort of thing the linaro-wg has in mind? BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] ARM: dma-mapping: outer cache is invalidated twice
On 15 February 2011 15:12, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 15, 2011 at 02:54:21PM +0100, Per Forlin wrote: I don't fully understand this yet. I think you are right but I need a little help to get there myself. I agree, the cache (L1 and L2) must be invalidated after the DMA has completed. Before starting the DMA the write buffers must be drained (cache_sync). Why invalidate the cache before starting the DMA? Think about what happens if you have dirty cache lines in the DMA region. These can be evicted when other cache lines are loaded, which will result in them overwriting contents of memory. If the DMA device has already written to that memory, the result is data corruption. So, the invalidate prior to DMA is to get rid of any dirty cache lines which could be written back to memory. True. In my case write back is disable but read back is enable, that's why I didn't consider it. Do you think it is feasible to let dma-mapping detect the cache configurations in runtime in order to prevent unnecessary cache operations? I can see some FIXME comments in the code which indicates you may have plans to change it. I can try to think of a proposal if you agree. Thanks again, /Per ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Notes Actions: Linaro Graphics Working Group - Feb 09, 2011
Rob, It is certainly analogous to the DRM access control interfaces, and I would expect that access to memory objects from the graphics stack would go through those interfaces (i.e. Xorg/EGL calls libdrm, calls DRM kernel ioctl, calls memory manger inside the kernel), but we need to make sure we have equivalent interfaces setup for non-graphics applications to make sure that all access control policy is honored. So, in short, yes, there's a connection :-). cheers, Jesse On Tue, Feb 15, 2011 at 5:27 AM, Clark, Rob r...@ti.com wrote: On Fri, Feb 11, 2011 at 7:47 AM, Alexandros Frantzis alexandros.frant...@linaro.org wrote: * First version of Unified Memory Management position: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement btw, the access control aspect of this sort of reminds me of the DRM driver infrastructure, and authentication between direct rendering client and x-server (or whoever the DRM master is).. I wonder if there is, or should be, a connection.. BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Notes Actions: 2/9 Linaro Developer Platform Weekly Status Meeting
Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on February 9th in #linaro-meeting on irc.freenode.net at 16:00 UTC. https://wiki.linaro.org/Platform/Foundations/2011-02-09 Actions from the meeting where as follows: * JamieBennett to come up with test assignments for the new developer image: carried over * jcrigby to write up landing team u-boot, kernel workflows and send for review after first draft is done: carried over * wookey to work with tgall_foo to get the linaro-nano image building * tgall_foo and JamieBennett to get linaro-desktop building in Offspring * slangasek and fturgis to decide whether or not to move to more recent version of systemtap * ppearse to investigate how libtool does ldopen for GObject Introspection work Regards, Tom (tgall_foo) Developer Platforms Team We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please review blueprint linaro-n-validation-job-dispatcher
On 9 February 2011 20:12, Paul Larson paul.lar...@linaro.org wrote:
On Mon, Jan 31, 2011 at 11:58 AM, Paul Larson paul.lar...@linaro.orgwrote:
2. One queue TOTAL. One queue may seem like a bottleneck, but I don't
think it has to be in practice. One process can monitor that queue, then
launch a process or thread to handle each new job that comes in.
I think RabbitMQ message can have the ability to include the board
information in it to use one queue, and also we can use different queues for
different types of boards.
Right, but my question was, if you are already encoding that information
in the job stream, what is the advantage to having a queue for each board
type, rather than a single queue?
Job description:
I'd like to see some more detail here. Can you provide an example of a
job file that would illustrate how you see it working? We also need to
specify the underlying mechanisms that will handle parsing what's in the
job
file, and calling [something?] to do those tasks. What we have here feels
like it might be a bit cumbersome.
I added an detailed one on the spec, like:
1.
[Beagle-1,
http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/imx51/20110131/0/images/hwpack/hwpack_linaro-imx51_20110131-0_armel_unsupported.tar.gz,
http://snapshots.linaro.org/11.05-daily/linaro-headless/20110131/0/images/tar/linaro-natty-headless-tar-20110131-0.tar.gz,
900, [abrek, LTP, 180], [none, echo 100 abc, 1], ... ]
2.
[IMX51-2, 20100131, 900, [abrek, LTP, 180], [none, echo 100
abc, 1], ... ]
This looks almost like JSON, which is what Zygmunt was originally pushing
for IIRC. If we are already going down that path, seems it would be
sensible to take it a step further and have defined sections. For example:
Tests:[
{
name:LTP,
testsuite:abrek,
subtest:ltp, not thrilled about that name subtest,
but can't think of something better to call it at the moment
timeout:180,
reboot_after:True
},
{
name:echo test,
testsuite:shell,
timeout:20
reboot_after:False
}
]
What do you think? Obviously, there would be other sections for things
like defining the host characteristics, the image to deploy, etc.
Other questions...
What if we have a dependency, how does that get installed on the target
image? For example, if I want to do a test that requires bootchart be
installed before the system is booted, we should be able to specify that,
and have it installed before booting.
What about installing necessary test suites? How do we tell it, in
advance, what we need to have installed, and how does it get on the image
before we boot, or before we start testing?
I think validation tools, test suites and necessary files are likely to
install after test image deployment.
Yes, clearly they have to be installed after deployment, but we may also
need to consider them installing BEFORE we actually boot the test image.
Had another thought on this tonight, I didn't hear much back on the
previous proposal, but how about something more like this as an example of
what a job description might look like. In this scenario, there would be
some metadata for the job itself, such as timeout values, etc. Then steps
that would define commands with parameters. That would allow us to be more
flexible, and add support for more commands without changing the format.
Hopefully the mailer doesn't mangle this too badly. :)
{
job_name: foo,
target: panda01,
timeout: 18000,
steps: [
{
command: deploy,
parameters:
{
rootfs:
http://snapshots.linaro.org/11.05-daily/linaro-developer/20110208/0/images/tar/linaro-n-developer-tar-20110208-0.tar.gz
hwpack:
http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/panda/20110208/0/images/hwpack/hwpack_linaro-panda_20110208-0_armel_supported.tar.gz
}
},
{
command: boot_test_image
},
{
command: test_abrek,
parameters:
{
test_name: ltp
}
},
{
command: submit_results,
parameters:
{
server: http://dashboard.linaro.org;,
stream: panda01-ltp
}
}
]
}
I think this looks good. Is this the JSON file definition we will use
initially? Asking this because the corresponding Dispatcher WI is set to
done [qzhang] Define the job description both on dispatcher and scheduler:
DONE. I will need at least initial version to work with on Scheduler parts.
Also, I wonder if we will support more complex test jobs involving more than
one board, either of the same type or different types? If yes, how will the
Dispatcher handle those? Should we put that in queue as a single job or as
multiple jobs? How will that affect JSON file definition?
Thanks,
Paul Larson
___
linaro-dev mailing list
[RFC] agent-based remote validation invocation for LAVA
...@linaro.org-20110215171535-bzd9sb3wont0il67 # target_branch: http://bazaar.launchpad.net/~pwlars/abrek/trunk/ # testament_sha1: 3effa4a7c980a9b31968fc80514a0eabc5568e0b # timestamp: 2011-02-16 02:02:38 +0800 # base_revision_id: paul.lar...@canonical.com-20110112145515-\ # z05a1jdktss8rbtu # # Begin patch === added file 'abrek/test_definitions/monkey.py' --- abrek/test_definitions/monkey.py 1970-01-01 00:00:00 + +++ abrek/test_definitions/monkey.py 2011-02-15 17:15:35 + @@ -0,0 +1,27 @@ +import re +import abrek.testdef + +VERSION=20110215 +RUNSTEPS = ['adb shell monkey -s 1 --pct-syskeys 100 --throttle 500 100'] + +class MonkeyParser(abrek.testdef.AbrekTestParser): +def parse(self): +filename = testoutput.log +PAT = ^## Network stats: elapsed time?\W+(?Pmeasurement\d+)ms +pat = re.compile(PAT) +with open(filename) as fd: +for line in fd: +match = pat.search(line) +if match: +d = match.groupdict() +d['units'] = mseconds +d['result'] = pass +d['test_case_id'] = monkey +self.results['test_results'].append(d) + +monkeyinst = abrek.testdef.AbrekTestInstaller(deps=[monkey]) +monkeyrun = abrek.testdef.AbrekTestRunner(RUNSTEPS) +monkeyparser = MonkeyParser() +testobj = abrek.testdef.AbrekTest(testname=monkey, version=VERSION, + installer=monkeyinst, runner=monkeyrun, + parser=monkeyparser) # Begin bundle IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWW3hhegAAej/gERUQAFY7//3 8iPfj7BQBO92YDl0cQoDpQ0QJpGTaoek2U2Cn6mkaADQGQAwgA0Qmp6ZMjRoUHoQ 1U9pGk0xMQA0AAAGgAAaYgBw00yMRhNMBDAJphGCYmQ0yNDQCSIRpqYhqMCMmpNtNTEno9TUzUab UaDQ9TT0kAKLNYMvvSJqqDbZsmaEGYQEHgDA5VS0gDcStIz3bFxytYWtBJfJkkEUl0oobvO/5H8/ M8vKubu7cPVVy+HMi87Hl2O7x0SWr1I6ZoiUFBU9Uy0dJ+eRyEZha1Ao4ZtB00JqEoYtUUV6NgvX G2MJj31pOu3UpxJRakjP4MIBnRpbJHfNpBGDLfQGHLdnXAtj1ZZX4kqgpj0XPSSOlw7hvS4y3BWC rHIwsWLT4WzjCpOcz8gaKkt60UdT9iUlXDei26Vn3XSZul3e9tLcOj1oUA1Mggx9lYZwgny2EShG WUXmaLy5gc53K61jZBH9dBd3VpLlxRlNWVdlVcIKyIf7PLDKmAziczML2Xb5DrFx44QVMwcrAZu/ jRYuVBIuqyZ8cojX14UsYKYHPk06TmyFQpsV1mYwFGGqpTIYVxCFuS2OSyEBhsl1g1l8ZXFQnTZW IKAExhZDFgTUG5TSn6LKwa+M4tYXmOVgpnUWQtTk6t1CjEoFYFslOEqUknFkQGEISY9ya8JYCzFF lB0mMou1igLDmjO2WcEh+ArgDpuMFxAxqVXtei9lUVRmNa7rFBaBNNqiwJ2N3n02oXNh2YtnJEYf DOvT42d0612pXHoDqZQ0YGMbsWYQh0MKB8Qgnw9ykLh0KkI6R2xCHBAGRlC+R408njtNrZfn/QdD NkNe1nYGn2uQHDtXtPdctDbvC6w4FvUFF8L1TGDyhjSqW/j3e+7GimJJzcMzVrFR4Qr/OAwSk84r 8NZlFccTup7fjpwRvBs68Bek7zo7xGKC1l9I71DOPyeOtAgsInIkSWydSqNcKhQazNOPi28wirz0 iGEqgwsATt8AJIYTiloqxzaTApvwcWGoT4S8i2g7FDXkyGzhRSlS1eFrRPkSuoKpw03SUJ5RJDGA 8bDlwm2Nqbcm7Tg3uklmtEdmXe2XBz0XnJMDnyjPyt5plfWXtWxDNojGWxJ502YrPFmTJ2AtWT4O EFmEEsJtewNy+vAPV1mc3HQUPrtl8eF+uPlyOcCPDOJ0uCHNp3cLGRuBknshthkTF/nS1aXd7+3i yaf1kdYtXSwSVxmNyTwDCXs8Qz8oqmbMQigHBkAfomEjXL38I5S+B0A3DvD7PQh2RegLtwbVj3ri qwqXWKWKKOpYvRrrU2mwxWeCXNtujsdX3O82MOpMb6D1BbuxZ4Fmyllzag1NDxZma2hXQ+ldqULW lCDnvYUDPdUlQi4eFTjbBySUF2QpBAMRTwX7tOAmQ7Jl15krW0NsRfUHOmh78a0oPMYUuArLGtLQ 2JSgG5RWSoeyepmTdp26+MZLVqmYrWepiGqVemF2VP3EaEHQfAZQD18FK454iLa0pI/Tstv6aFqV c64Iglj7I5fZlqSmymO2kogrU6OMYjveqAyoJEDCOYE/G2TWbfWsFdUYtsiUxprqGDSV46xvg4zJ MmsZKgMGDytaDTdtfTAsecNdchY3eKGb7DBa0UyIPdE5tzaEZueMjHO2GWGvCPILfSCqI4oU5pzq LjKZ2QpXUE0tN4Dhb5IaoYIgVdAHYdP5CviFMbqjDENyUE7ILdCoZcBchV/4u5IpwoSDbwwvQA== ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
W dniu 15.02.2011 21:01, Jim Huang pisze: Hi Jim, great work! ** Why can't we execute LAVA/Abrek directly on Android devices? I agree that direct abrek is not the right solution for Android. I think there is a class of use cases that also falls into this category: * testing early silicon * testing very primitive systems * testing other foreign systems They all have either no python or running python is not desirable. ** So, what's agent-based remote validation invocation for LAVA? There are three key items: (a) Agent (b) Remote validation invocation (c) LAVA We keep in mind that we make no technical impact to LAVA architecture, and the Agent is just the helper. Originally, the client-server communication looks like the following: LAVA server LAVA client -- Abrek test suite Currently LAVA is just taking shape. Things like server and client are still not very well defined. You don't have to be constrained by this. The only thing that is somewhat well defined is abrek that was produced in the previous cycle. Abrek was designed to run _on_ the device. For use cases where Abrek is just interacting with the test device we may want to extend it sensibly to clearly separate those cases where necessary while retaining as much common code and user interface as possible. There are a few things to consider here: Device context: Currently abrek has some logic to probe the running system for context information. Context is loosely defined as the collection of relevant software and hardware information that might be interesting to analyze or that can be used to connect distinct test results in post-process analysis. If we are just interacting with a remote device we need to determine this information in some other way _and_ ensure we're not adding any dummy information from the host system. Remote device registration: A single host may talk to possibly large number of such devices. At the very least we should plan how we intend to manage the process of defining/adding/removing a device and how to allow remote tests to be invoked on registered devices, if possible (if the device supports this test). Test classes: So far abrek tests could run on any Linux box (where any was poorly defined as any ubuntu-like system. This is no longer the case so we should be able to classify tests (and devices) somehow. IMHO we could define a new tool (or just a new sub-command class for abrek), say abrek-remote that will be used instead of the normal abrek call. Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job would use abrek and some other tools to invoke tests, process results and send them to the dashboard while other job (one for android) would not run abrek at all, instead it would call some other helper, while still reusing identical components for process results and send to result storage phases. This is still in flux but has some advantages: 0) Jobs are simple text files that can be stored and shared with others 1) Jobs can encapsulate device information like which android device to connect to and how. 2) Jobs can still call to other parts of the LAVA stack such as result submission 3) Jobs can be extended locally (by LAVA plugins) so that anyone can develop specialized use cases for their very specific needs without altering the stack or having to write something completely custom. Another upside is that such job definitions (and any required LAVA plugins) would just integrate with the rest of LAVA (farm backend, frontend, etc). You could work on a job description on your workstation and once it's finished you could add it to a job scheduler for automatic processing. ** Show me the use case The attached patch is just trivial proof-of concept implementation done by Jeremy Chang that adds a 'monkey' test definition file for abrek. Once TCP/IP or USB is ready, for Android's monkey testing, the procedure is like as following: (1) abrek run monkey (2) abrek dashboard put /anonymous/ monkey1297752359.0 Could you please forgive my android ignorance and tell me how I can run this test? Please include any hardware/software I should have. Can I run this on a beagle board with some android installation? Do I need a real android phone? This is just so that I can participate in the discussion and not make clueless and pointless arguments later. Any suggestion is appreciated. Thank you in advance. I hope we can work on making this solid. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/2] ARM: IMX5: cpuidle driver
On Fri, Feb 11, 2011 at 10:36:12AM +0100, yong.s...@linaro.org wrote:
From: Yong Shen yong.s...@freescale.com
implement cpuidle driver for iMX5 SOCs, leave cpuidle params to board
related code.
Signed-off-by: Yong Shen yong.s...@freescale.com
---
arch/arm/mach-mx5/Makefile |1 +
arch/arm/mach-mx5/cpuidle.c | 113
+++
arch/arm/mach-mx5/cpuidle.h | 26 ++
3 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx5/cpuidle.c
create mode 100644 arch/arm/mach-mx5/cpuidle.h
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0d43be9..12239e0 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -7,6 +7,7 @@ obj-y := cpu.o mm.o clock-mx51-mx53.o devices.o
obj-$(CONFIG_SOC_IMX50) += mm-mx50.o
obj-$(CONFIG_CPU_FREQ_IMX)+= cpu_op-mx51.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
obj-$(CONFIG_MACH_MX53_EVK) += board-mx53_evk.o
diff --git a/arch/arm/mach-mx5/cpuidle.c b/arch/arm/mach-mx5/cpuidle.c
new file mode 100644
index 000..9d77c47
--- /dev/null
+++ b/arch/arm/mach-mx5/cpuidle.c
@@ -0,0 +1,113 @@
+/*
+ * arch/arm/mach-mx5/cpuidle.c
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/io.h
+#include linux/cpuidle.h
+#include asm/proc-fns.h
+#include mach/hardware.h
+#include cpuidle.h
+#include crm_regs.h
+
+static struct imx_cpuidle_params *imx_cpuidle_params;
+void imx_cpuidle_board_params(struct imx_cpuidle_params *cpuidle_params)
+{
+ imx_cpuidle_params = cpuidle_params;
+}
+
+extern int tzic_enable_wake(int is_idle);
Please put this into a header file.
+static int imx_enter_idle(struct cpuidle_device *dev,
+struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+ u32 plat_lpc, arm_srpgcr, ccm_clpcr;
+ u32 empgc0, empgc1;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ plat_lpc = __raw_readl(MXC_CORTEXA8_PLAT_LPC)
+ ~(MXC_CORTEXA8_PLAT_LPC_DSM);
+ ccm_clpcr = __raw_readl(MXC_CCM_CLPCR) ~(MXC_CCM_CLPCR_LPM_MASK);
+ arm_srpgcr = __raw_readl(MXC_SRPG_ARM_SRPGCR) ~(MXC_SRPGCR_PCR);
+ empgc0 = __raw_readl(MXC_SRPG_EMPGC0_SRPGCR) ~(MXC_SRPGCR_PCR);
+ empgc1 = __raw_readl(MXC_SRPG_EMPGC1_SRPGCR) ~(MXC_SRPGCR_PCR);
+
+ if (state == dev-states[WAIT_CLK_ON])
+ ;
An if without code? This looks strange.
+ else if (state == dev-states[WAIT_CLK_OFF])
+ ccm_clpcr |= (0x1 MXC_CCM_CLPCR_LPM_OFFSET);
+ else if (state == dev-states[WAIT_CLK_OFF_POWER_OFF]) {
+ /* Wait unclocked, power off */
+ plat_lpc |= MXC_CORTEXA8_PLAT_LPC_DSM
+ | MXC_CORTEXA8_PLAT_LPC_DBG_DSM;
+ arm_srpgcr |= MXC_SRPGCR_PCR;
+ ccm_clpcr |= (0x1 MXC_CCM_CLPCR_LPM_OFFSET);
+ ccm_clpcr = ~MXC_CCM_CLPCR_VSTBY;
+ ccm_clpcr = ~MXC_CCM_CLPCR_SBYOS;
+ if (tzic_enable_wake(1) != 0) {
+ local_irq_enable();
+ return 0;
+ }
+ }
+
+ __raw_writel(plat_lpc, MXC_CORTEXA8_PLAT_LPC);
+ __raw_writel(ccm_clpcr, MXC_CCM_CLPCR);
+ __raw_writel(arm_srpgcr, MXC_SRPG_ARM_SRPGCR);
+
+ cpu_do_idle();
+
+ do_gettimeofday(after);
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+ return idle_time;
+}
+
+static struct cpuidle_driver imx_cpuidle_driver = {
+ .name = imx_idle,
+ .owner =THIS_MODULE,
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, imx_cpuidle_device);
+
+static int __init imx_cpuidle_init(void)
+{
+ struct cpuidle_device *device;
+ int i;
+
+ if (imx_cpuidle_params == NULL)
+ return -ENODEV;
+
+ cpuidle_register_driver(imx_cpuidle_driver);
+
+ device = per_cpu(imx_cpuidle_device, smp_processor_id());
+ device-state_count = IMX_MAX_CPUIDLE_STATE;
+
+ for (i = 0; i IMX_MAX_CPUIDLE_STATE i CPUIDLE_STATE_MAX; i++) {
+ device-states[i].enter = imx_enter_idle;
+ device-states[i].exit_latency = imx_cpuidle_params[i].latency;
+ device-states[i].flags = CPUIDLE_FLAG_TIME_VALID;
+ }
+
+ strcpy(device-states[WAIT_CLK_ON].name, WFI 0);
+ strcpy(device-states[WAIT_CLK_ON].desc, Wait with clock on);
+ strcpy(device-states[WAIT_CLK_OFF].name, WFI 1);
+ strcpy(device-states[WAIT_CLK_OFF].desc, Wait with clock off);
+ strcpy(device-states[WAIT_CLK_OFF_POWER_OFF].name, WFI
Notes from the Infrastructure team meeting - 2011-02-15
Hi, See the notes in full formatted glory: https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-02-15 or see below. Thanks, James === Attendees === * Mattias Backman * Guilherme Salgado * Deepti Kalakeri * James Westby === Agenda === * Team status * Actions from last meeting * AOB === Action Items === * James to Cc Guilherme on RT for patchwork * James to email Guilherme with info on patc...@linaro.org account === Action Items from previous meeting === * James to talk with Michael about requirement driving not wanting to host artefacts on Hudson === Minutes === * Team status reports * Mattias Backman * Started prototyping BuildFailureBugFiling * Snowball was taken away again * Guilherme Salgado * Wrote design/implementation plans for PatchTracking * Submitted some patchwork patches and got good feedback * James Westby * Continued positive feedback about status.linaro.org, along with requests for improvement * Deepti Kalakeri * Set up Hudson locally to experiment with. * Panda should be arriving this week * Not going to rely on an IS deployed instance of Hudson/Jenkins for short-term experimentation. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Minutes for Mentor team meeting - 2011-2-15
The wiki formatted minutes are at: https://wiki.linaro.org/Mentoring/Status/2011-02-15 Please direct suggestions or comments to Matt or Andy. Cheers, Matt == Team Highlights == * Wiki Additions * https://wiki.linaro.org/Mentoring/Additions-l-m-c * Email setup * https://wiki.linaro.org/Internal/Process/ThunderbirdSetup * https://wiki.linaro.org/Internal/Process/MuttSetup * https://wiki.linaro.org/Internal/Process/CalendarSetup * https://wiki.linaro.org/Mentoring/HowTo/UbuntuDevelopmentProcess * https://wiki.linaro.org/Mentoring/KernelDeploy == Action Items and Minutes == * Training the Trainers checklist - Both * IRC quick reference link - Matt * Xchat tutorial - Ericm's request - Andy * Conference Call System rewrite - Matt * Tailored new staff to-do list - Add to New Staff task? - Both * Recorded new staff checklist - Maybe a google form - Matt * Review survey - individuals and trends * Mumble - Matt * Gobby - Andy * Tech lead feedback email * Break out Angus' email into to-do items - Andy * Mapping between Launchpad projects and Linaro teams - Both * Android information - Andy * Extend category tag usage * Waiting on Trainers - should we suggest people == Risks / Issues == * Risk - Unable to recruit trainers within member organizations - carry over from last week * Mitigation - Perform mentoring tasks from within this team * Mitigation - Break responsibilities into smaller portions and recruit multiple trainers * Information we have developed is not easy to find or accessible == Miscellaneous == * Holidays - Feb 21, 2011 - US President's day ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Correction - Minutes for Mentor team meeting - 2011-2-15
On 02/15/2011 05:11 PM, Matt Waddel wrote: snip * Wiki Additions * https://wiki.linaro.org/Mentoring/Additions-l-m-c This should be: * https://wiki.linaro.org/Mentoring/HowTo/AddingNewHardwareSupport ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Announcing the Linaro porting jam
Hello, my fellow ARM aficionados! The Linaro Developer Platform Team is pleased to announce a new initiative to help improve the state of software on ARM: the ARM porting jam. Starting today, February 16th, we will be running a weekly IRC jam on Wednesdays from 1400-1800 UTC to bring developers together to work on all manner of userspace porting bugs, with the aim of fixing portability issues and getting the fixes delivered to our upstreams. An initial porting queue of known issues can be found here: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue Interested in making the software in Ubuntu run better on ARM? Stop on by the #linaro channel on irc.linaro.org today! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
