Re: [Question] About the Gator and the Power Probe
On 4 September 2012 18:51, Jon Medhurst (Tixy) t...@linaro.org wrote: On Tue, 2012-09-04 at 17:43 +0800, Hongbo Zhang wrote: I just know there is a Linaro Overlay PPA for this gator, I didn't add this PPA manually, by default there is no such PPA. I think this is the reason of old version gatord. This PPA should be added by default in all Linaro images because it is the PPA which contains most of Linaro's output. If it doesn't then it's a bug which needs reporting and fixing. Which image or hwpack are you using? Can you double check if the image's root file system has the file etc/apt/sources.list.d/linaro-overlay-ppa.list I am using the July release (no Aug Ubuntu release for Snowball) . and I have the file: # cat /etc/apt/sources.list.d/linaro-overlay-ppa.list # Linaro Overlay PPA deb http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu precise main deb-src http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu precise main -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Powertop][PATCH] Fix timer and work perf events timestamp tracing
Incorrect timer and work perf events timestamp tracing is one
of the reason for reporting usage over 100%. This patch will
resolve the issue by
- rejecting the events for which entry timestamp is not recorded.
Currently these events exit timestamp itself is considered as
usage period resulting in over 100% usage.
- clearing event timestamps from global map at the end of each
measurement to avoid collision with earlier recorded timestamps.
Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org
---
src/process/timer.cpp | 5 -
src/process/work.cpp | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/process/timer.cpp b/src/process/timer.cpp
index 8917490..db074c4 100644
--- a/src/process/timer.cpp
+++ b/src/process/timer.cpp
@@ -79,7 +79,8 @@ uint64_t timer::done(uint64_t time, uint64_t timer_struct)
{
int64_t delta;
- if (running_since[timer_struct] time)
+ if (running_since.find(timer_struct) == running_since.end() ||
+ running_since[timer_struct] time)
return 0;
delta = time - running_since[timer_struct];
@@ -147,6 +148,8 @@ void clear_timers(void)
all_timers.erase(it);
it = all_timers.begin();
}
+
+ running_since.clear();
}
bool timer::is_deferred(void)
diff --git a/src/process/work.cpp b/src/process/work.cpp
index 82f13a2..e436643 100644
--- a/src/process/work.cpp
+++ b/src/process/work.cpp
@@ -56,7 +56,8 @@ uint64_t work::done(uint64_t time, uint64_t work_struct)
{
int64_t delta;
- if (running_since[work_struct] time)
+ if (running_since.find(work_struct) == running_since.end() ||
+ running_since[work_struct] time)
return 0;
delta = time - running_since[work_struct];
@@ -102,6 +103,8 @@ void clear_work(void)
all_work.erase(it);
it = all_work.begin();
}
+
+ running_since.clear();
}
--
1.7.11.3
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: llct stable trees
On 09/05/12 17:19, the mail apparently from Andy Green included: On 09/04/12 12:13, the mail apparently from Ricardo Salveti included: Hi - 1) Can we have linux stable point release content in tilt-3.4? Rather than my doing it, isn't it better to add it to llc-3.4 and merge it on the lt history tree periodically? That way every lt can get them from one place. I don't see why merging the stable release contents would be an issue. We could keep updating the tree based on stable-only releases, as long as we still have at least one Landing Team interested on consuming it. This would be another job that would probably be automated by Andrey's scripts. Right it should usually be simple, although don't forget there is quite a lot of avant garde content in llct, such as Androidization. Just today I saw Xavier at TI find that merging of stable had a patch conflicting with llct Androidization content. So, it turns out that is a good example. I researched the conflict and found a thread from RMK rejecting the patch 96714b5dfe283cd8ab13aac1f9ccb565064af152 that seems to have come in by Androidization series via llct. http://lists.infradead.org/pipermail/linux-arm-kernel/2010-May/014116.html We decided to take the kernel.org stable version of the patch 6019ae78aa65afe273da8c0dfeed8e89fb5edf8f which removes some locking evil in the Androidization version, which RMK noted opened up a horrible race. Xavier then found a ghastly bug that had previously been impossible to track down disappeared. So we now know that 96714b5dfe283cd8ab13aac1f9ccb565064af152 we had been happily pushing out on everyone in llct-3.4 is a terrible idea, not just for TILT but any kernel that has it in will suffer from very hard to reproduce mm instability under stress, and needs reverting in favour of the version that went in kernel.org stable. But now we know about that flaw in llct-3.4 should we not do something about it? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On Wed, Sep 5, 2012 at 3:52 PM, Rajagopal Venkat rajagopal.ven...@linaro.org wrote: Incorrect timer and work perf events timestamp tracing is one of the reason for reporting usage over 100%. This patch will resolve the issue by - rejecting the events for which entry timestamp is not recorded. Currently these events exit timestamp itself is considered as usage period resulting in over 100% usage. - clearing event timestamps from global map at the end of each measurement to avoid collision with earlier recorded timestamps. Tried it few times on Panda Board. Tested-by: Viresh Kumar viresh.ku...@linaro.org ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH v5] media: add v4l2 subdev driver for S5K4ECGX sensor
This patch adds driver for S5K4ECGX sensor with embedded ISP SoC, S5K4ECGX, which is a 5M CMOS Image sensor from Samsung The driver implements preview mode of the S5K4ECGX sensor. capture (snapshot) operation, face detection are missing now. Following controls are supported: contrast/saturation/brightness/sharpness Signed-off-by: Sangwook Lee sangwook@linaro.org Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Scott Bambrough scott.bambro...@linaro.org --- Changes since v4: - replaced register tables with the function from Sylwester - updated firmware parsing function with CRC32 check firmware generator from user space: git://git.linaro.org/people/sangwook/fimc-v4l2-app.git Changes since v3: - used request_firmware to configure initial settings - added parsing functions to read initial settings - updated regulator API - reduced preview setting tables by experiment Changes since v2: - added GPIO (reset/stby) and regulators - updated I2C read/write, based on s5k6aa datasheet - fixed set_fmt errors - reduced register tables a bit - removed vmalloc Changes since v1: - fixed s_stream(0) when it called twice - changed mutex_X position to be used when strictly necessary - add additional s_power(0) in case that error happens - update more accurate debugging statements - remove dummy else drivers/media/i2c/Kconfig|7 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4ecgx.c | 1019 ++ include/media/s5k4ecgx.h | 37 ++ 4 files changed, 1064 insertions(+) create mode 100644 drivers/media/i2c/s5k4ecgx.c create mode 100644 include/media/s5k4ecgx.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 9a5a059..55b3bbb 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -484,6 +484,13 @@ config VIDEO_S5K6AA This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M camera sensor with an embedded SoC image signal processor. +config VIDEO_S5K4ECGX +tristate Samsung S5K4ECGX sensor support +depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API +---help--- + This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M + camera sensor with an embedded SoC image signal processor. + source drivers/media/i2c/smiapp/Kconfig comment Flash devices diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 088a460..a720812 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o +obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c new file mode 100644 index 000..0f12d46 --- /dev/null +++ b/drivers/media/i2c/s5k4ecgx.c @@ -0,0 +1,1019 @@ +/* + * Driver for s5k4ecgx (5MP Camera) from Samsung + * a quarter-inch optical format 1.4 micron 5 megapixel (Mp) + * CMOS image sensor. + * + * Copyright (C) 2012, Linaro, Sangwook Lee sangwook@linaro.org + * Copyright (C) 2012, Insignal Co,. Ltd, Homin Lee suap...@insignal.co.kr + * + * Based on s5k6aa, noon010pc30 driver + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include linux/clk.h +#include linux/crc32.h +#include linux/ctype.h +#include linux/delay.h +#include linux/firmware.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/module.h +#include linux/regulator/consumer.h +#include linux/slab.h +#include linux/vmalloc.h + +#include media/media-entity.h +#include media/s5k4ecgx.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-mediabus.h +#include media/v4l2-subdev.h + +static int debug; +module_param(debug, int, 0644); + +#define S5K4ECGX_DRIVER_NAME s5k4ecgx +#define S5K4ECGX_FIRMWARE s5k4ecgx.bin + +/* Firmware revision information */ +#define REG_FW_REVISION0x71a6 +#define REG_FW_VERSION 0x71a4 +#define S5K4ECGX_REVISION_1_1 0x11 +#define S5K4ECGX_FW_VERSION0x4ec0 + +/* General purpose parameters */ +#define REG_USER_BRIGHTNESS0x722c +#define REG_USER_CONTRAST 0x722e +#define REG_USER_SATURATION0x7230 + +#define REG_G_NEW_CFG_SYNC 0x724a +#define REG_G_PREV_IN_WIDTH0x7250 +#define REG_G_PREV_IN_HEIGHT 0x7252 +#define REG_G_PREV_IN_XOFFS0x7254
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
Hi,
On (09/05/12 15:52), Rajagopal Venkat wrote:
Incorrect timer and work perf events timestamp tracing is one
of the reason for reporting usage over 100%. This patch will
resolve the issue by
- rejecting the events for which entry timestamp is not recorded.
how is that possible?
do you mean erasing between measurements?
schematically:
measure0:
ev1.start
ev2.start
ev2.end
processing
clear
measure1:
ev3.start
ev1.end
ev3.end
processing
clear
if so, then we're loosing events, which is no good. reporting less than 100%
is ok, but reporting less than real is not.
p.s.
I'll try to check emails, but most probably will be off-line most of the day.
-ss
Currently these events exit timestamp itself is considered as
usage period resulting in over 100% usage.
- clearing event timestamps from global map at the end of each
measurement to avoid collision with earlier recorded timestamps.
Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org
---
src/process/timer.cpp | 5 -
src/process/work.cpp | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/process/timer.cpp b/src/process/timer.cpp
index 8917490..db074c4 100644
--- a/src/process/timer.cpp
+++ b/src/process/timer.cpp
@@ -79,7 +79,8 @@ uint64_t timer::done(uint64_t time, uint64_t timer_struct)
{
int64_t delta;
- if (running_since[timer_struct] time)
+ if (running_since.find(timer_struct) == running_since.end() ||
+ running_since[timer_struct] time)
return 0;
delta = time - running_since[timer_struct];
@@ -147,6 +148,8 @@ void clear_timers(void)
all_timers.erase(it);
it = all_timers.begin();
}
+
+ running_since.clear();
}
bool timer::is_deferred(void)
diff --git a/src/process/work.cpp b/src/process/work.cpp
index 82f13a2..e436643 100644
--- a/src/process/work.cpp
+++ b/src/process/work.cpp
@@ -56,7 +56,8 @@ uint64_t work::done(uint64_t time, uint64_t work_struct)
{
int64_t delta;
- if (running_since[work_struct] time)
+ if (running_since.find(work_struct) == running_since.end() ||
+ running_since[work_struct] time)
return 0;
delta = time - running_since[work_struct];
@@ -102,6 +103,8 @@ void clear_work(void)
all_work.erase(it);
it = all_work.begin();
}
+
+ running_since.clear();
}
--
1.7.11.3
___
PowerTop mailing list
power...@lists.01.org
https://lists.01.org/mailman/listinfo/powertop
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] bit-LITTLE-MP-v7 - IMPORTANT
Hi Viresh, On Mon, Sep 03, 2012 at 06:21:26AM +0100, Viresh Kumar wrote: On 28 August 2012 10:37, Viresh Kumar viresh.ku...@linaro.org wrote: I have updated https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTree as per our last discussion. Please see if i have missed something. Hi Guys, I will be sending PULL request of big-LITTLE-MP-v7 today as per schedule. Do let me know if you want anything to be included in it before that. @Morten: What should i do with patch reported by Santosh: ARM-Add-HMP-scheduling-support-for-ARM-architecture Do i need to apply it over your branch? The patch is already in the original patch set, so I'm not sure why it is missing. http://linux-arm.org/git?p=arm-bls.git;a=commit;h=1416200dd62551aa9ac4aa207b0c66651ccbff2c It needs to be there for the HMP scheduling to work. Regards, Morten ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 09/05/2012 05:44 AM, Sergey Senozhatsky wrote:
Hi,
On (09/05/12 15:52), Rajagopal Venkat wrote:
Incorrect timer and work perf events timestamp tracing is one
of the reason for reporting usage over 100%. This patch will
resolve the issue by
- rejecting the events for which entry timestamp is not recorded.
how is that possible?
do you mean erasing between measurements?
schematically:
measure0:
ev1.start
ev2.start
ev2.end
processing
clear
measure1:
ev3.start
ev1.end
ev3.end
processing
clear
if so, then we're loosing events, which is no good. reporting less than 100%
is ok, but reporting less than real is not.
p.s.
I'll try to check emails, but most probably will be off-line most of the day.
-ss
Yes! This is a hard issues. Some report say CPU usage over 100% which in
some cases is correct. For instance for IA, a CPU can run over 100% of
it's listed frequency. For instance listed freq could be 3.4 but in
turbo mode the freq govonor can request max and be given 3.8Ghz for a
duration. Also overall if all processor cores are running at 100% you
essentially can have a overall usage of over 100%.
There have been some cases reported where CPU usage is WAY over 100% and
that is an issue, but I have has a hard time reproducing the issues.
This can be tricky business, so care is needed.
-Chris
Currently these events exit timestamp itself is considered as
usage period resulting in over 100% usage.
- clearing event timestamps from global map at the end of each
measurement to avoid collision with earlier recorded timestamps.
Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org
---
src/process/timer.cpp | 5 -
src/process/work.cpp | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/process/timer.cpp b/src/process/timer.cpp
index 8917490..db074c4 100644
--- a/src/process/timer.cpp
+++ b/src/process/timer.cpp
@@ -79,7 +79,8 @@ uint64_t timer::done(uint64_t time, uint64_t timer_struct)
{
int64_t delta;
- if (running_since[timer_struct] time)
+ if (running_since.find(timer_struct) == running_since.end() ||
+ running_since[timer_struct] time)
return 0;
delta = time - running_since[timer_struct];
@@ -147,6 +148,8 @@ void clear_timers(void)
all_timers.erase(it);
it = all_timers.begin();
}
+
+ running_since.clear();
}
bool timer::is_deferred(void)
diff --git a/src/process/work.cpp b/src/process/work.cpp
index 82f13a2..e436643 100644
--- a/src/process/work.cpp
+++ b/src/process/work.cpp
@@ -56,7 +56,8 @@ uint64_t work::done(uint64_t time, uint64_t work_struct)
{
int64_t delta;
- if (running_since[work_struct] time)
+ if (running_since.find(work_struct) == running_since.end() ||
+ running_since[work_struct] time)
return 0;
delta = time - running_since[work_struct];
@@ -102,6 +103,8 @@ void clear_work(void)
all_work.erase(it);
it = all_work.begin();
}
+
+ running_since.clear();
}
--
1.7.11.3
___
PowerTop mailing list
power...@lists.01.org
https://lists.01.org/mailman/listinfo/powertop
___
PowerTop mailing list
power...@lists.01.org
https://lists.01.org/mailman/listinfo/powertop
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] acpi : remove power from acpi_processor_cx structure
On Saturday, September 01, 2012, Rafael J. Wysocki wrote: On Friday, August 31, 2012, Daniel Lezcano wrote: On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote: On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote: Remove the power field as it is not used. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Acked. Hi Rafael, I did not see this patch going in. Is it possible to merge it ? I think so. I'll take care of it when I get back from LinuxCon/Plumbers Conf. (early next week). Applied to the linux-next branch of the linux-pm.git tree as v3.7 material. Are there any other patches you want me to consider for v3.7? Rafael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH 1/3] bootwrapper: Fix misaligned Hyp mode vector table
Currently, it looks like we rely on luck in order to fall through to the correct vector when a Hyp Trap exception occurs. This patch aligns the Hyp mode vector table explicitly to a 32-byte boundary, as required by the architecture. Signed-off-by: Dave Martin dave.mar...@linaro.org --- boot.S | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/boot.S b/boot.S index 61cd93f..0acd243 100644 --- a/boot.S +++ b/boot.S @@ -12,6 +12,17 @@ .arch_extension virt .text +.align 5 +/* Once we get rid of monitor.S, use these smc vectors too! */ +hyp_vectors: + .word 0 /* reset */ + .word 0 /* undef */ + .word 0 /* svc */ + .word 0 /* pabt */ + .word 0 /* dabt */ + b into_hyp_mode /* hvc */ + .word 0 /* irq */ + .word 0 /* fiq */ .globl start start: @@ -68,7 +79,7 @@ start: mcr p15, 0, r0, c12, c0, 1 @ Monitor vector base address @ Set up hvbar so hvc comes back here. - ldr r0, =vectors + ldr r0, =hyp_vectors mov r7, #0xfff0 smc #0 @ Set HVBAR @@ -79,17 +90,6 @@ start: @ This is how we enter hyp mode, for booting the next stage. hvc #0 -/* Once we get rid of monitor.S, use these smc vectors too! */ -vectors: - .word 0 /* reset */ - .word 0 /* undef */ - .word 0 /* svc */ - .word 0 /* pabt */ - .word 0 /* dabt */ - b into_hyp_mode /* hvc */ - .word 0 /* irq */ - .word 0 /* fiq */ - into_hyp_mode: @ Check CPU nr again mrc p15, 0, r0, c0, c0, 5 @ MPIDR (ARMv7 only) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH 3/3] bootwrapper: Delay switch to Hyp mode until kernel entry
Signed-off-by: Dave Martin dave.mar...@linaro.org
---
boot.S| 15 +--
semi_loader.h |6 --
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/boot.S b/boot.S
index 128f74e..8ab68ba 100644
--- a/boot.S
+++ b/boot.S
@@ -96,8 +96,6 @@ start:
mov r7, #0xfff0
smc #0 @ Set HVBAR
- enter_hyp
-
@ Check CPU nr again
mrc p15, 0, r0, c0, c0, 5 @ MPIDR (ARMv7 only)
and r0, r0, #15 @ CPU number
@@ -125,6 +123,8 @@ start:
ldr r1, [r0]
cmp r1, #0
beq 1b
+
+ enter_hyp
mov pc, r1 @ branch to the given address
#endif
@@ -170,6 +170,17 @@ __semi_call:
#endif
mov pc, lr
+.globl __boot_kernel
+__boot_kernel:
+ stmfd sp!, {r0-r3}
+
+ enter_hyp
+
+ ldr lr, [sp], #4
+ ldmfd sp!, {r0-r3}
+ bx lr
+.type __boot_kernel, %function
+
@
@ Data
@
diff --git a/semi_loader.h b/semi_loader.h
index 6afba40..29f3d63 100644
--- a/semi_loader.h
+++ b/semi_loader.h
@@ -90,10 +90,12 @@ struct loader_info {
void load_kernel(struct loader_info *info);
+void __boot_kernel(unsigned entry_point,
+ unsigned r0, unsigned r1, unsigned r2, unsigned r3);
+
static void boot_kernel(struct loader_info *info,
unsigned r0, unsigned r1, unsigned r2, unsigned r3) {
- ((void (*)(unsigned, unsigned, unsigned, unsigned))info-kernel_entry)(
- r0, r1, r2, r3);
+ __boot_kernel(info-kernel_entry, r0, r1, r2, r3);
}
#endif /* ! SEMI_LOADER_H */
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH 2/3] bootwrapper: Refactor entry into Hyp mode to be more reusable
* Split Hyp mode entry out into a separate macro. * hvc now jumps back to the caller in Hyp mode instead of branching to a fixed label. Signed-off-by: Dave Martin dave.mar...@linaro.org --- boot.S | 23 +++ 1 files changed, 15 insertions(+), 8 deletions(-) diff --git a/boot.S b/boot.S index 0acd243..128f74e 100644 --- a/boot.S +++ b/boot.S @@ -12,6 +12,15 @@ .arch_extension virt .text +.macro enter_hyp + @ We can't call hvc from secure mode, so drop down first. + mov r7, #0x + smc #0 @ Change to NS-mode + + @ This is how we enter hyp mode, for booting the next stage. + hvc #0 +.endm + .align 5 /* Once we get rid of monitor.S, use these smc vectors too! */ hyp_vectors: @@ -20,10 +29,14 @@ hyp_vectors: .word 0 /* svc */ .word 0 /* pabt */ .word 0 /* dabt */ - b into_hyp_mode /* hvc */ + b 1f .word 0 /* irq */ .word 0 /* fiq */ +/* Return directly back to the caller without leaving Hyp mode: */ +1: mrs lr, elr_hyp + mov pc, lr + .globl start start: #ifdef SMP @@ -83,14 +96,8 @@ start: mov r7, #0xfff0 smc #0 @ Set HVBAR - @ We can't call hvc from secure mode, so drop down first. - mov r7, #0x - smc #0 @ Change to NS-mode - - @ This is how we enter hyp mode, for booting the next stage. - hvc #0 + enter_hyp -into_hyp_mode: @ Check CPU nr again mrc p15, 0, r0, c0, c0, 5 @ MPIDR (ARMv7 only) and r0, r0, #15 @ CPU number -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH 0/3] Delay switch to Non-Secure Hyp until kernel entry
The bootwrapper is really doubling as firmware, so it doesn't make sense for it to drop out of the Secure World before getting a chance to parse its parameters and configuration. Instead, it should make sense to delay switching to the Normal World for as long as possible so that we have a chance to do any required firmware-level configuration in the Secure World first. This quick hack is ***completely untested***, since I'm not working with any suitable kernel tree right now. If someone with a KVM tree ready to run could give it a try, that would definitely save me some time. Review also welcome (naturally) Cheers ---Dave Dave Martin (3): bootwrapper: Fix misaligned Hyp mode vector table bootwrapper: Refactor entry into Hyp mode to be more reusable bootwrapper: Delay switch to Hyp mode until kernel entry boot.S| 58 +--- semi_loader.h |6 +++- 2 files changed, 42 insertions(+), 22 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] bit-LITTLE-MP-v7 - IMPORTANT
On 5 September 2012 19:16, Morten Rasmussen morten.rasmus...@arm.com wrote: The patch is already in the original patch set, so I'm not sure why it is missing. http://linux-arm.org/git?p=arm-bls.git;a=commit;h=1416200dd62551aa9ac4aa207b0c66651ccbff2c It needs to be there for the HMP scheduling to work. Surprisingly, it wasn't there in my tree since beginning... I have included it now. :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 5 September 2012 18:14, Sergey Senozhatsky
sergey.senozhat...@gmail.com wrote:
Hi,
On (09/05/12 15:52), Rajagopal Venkat wrote:
Incorrect timer and work perf events timestamp tracing is one
of the reason for reporting usage over 100%. This patch will
resolve the issue by
- rejecting the events for which entry timestamp is not recorded.
how is that possible?
do you mean erasing between measurements?
schematically:
measure0:
ev1.start
ev2.start
ev2.end
processing
clear
measure1:
ev3.start
ev1.end
evX.end
These events are causing numbers to go wrong.
delta = time - running_since[timer_struct];
accumulated_runtime += delta
Since running_since[timer_struct] returns zero, event timestamp
itself gets added to accumulated_runtime, causing usage to go
high something like 2693%.
ev3.end
processing
clear
if so, then we're loosing events, which is no good. reporting less than 100%
is ok, but reporting less than real is not.
I did thought of it. Yes, agree that, we are loosing events for which
start timestamp
is not recorded. I believe correct solution would be to consider these
events end
timestamp relative to first_stamp(src/process/do_process.cpp).
p.s.
I'll try to check emails, but most probably will be off-line most of the day.
-ss
Currently these events exit timestamp itself is considered as
usage period resulting in over 100% usage.
- clearing event timestamps from global map at the end of each
measurement to avoid collision with earlier recorded timestamps.
Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org
---
src/process/timer.cpp | 5 -
src/process/work.cpp | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/process/timer.cpp b/src/process/timer.cpp
index 8917490..db074c4 100644
--- a/src/process/timer.cpp
+++ b/src/process/timer.cpp
@@ -79,7 +79,8 @@ uint64_t timer::done(uint64_t time, uint64_t timer_struct)
{
int64_t delta;
- if (running_since[timer_struct] time)
+ if (running_since.find(timer_struct) == running_since.end() ||
+ running_since[timer_struct] time)
return 0;
delta = time - running_since[timer_struct];
@@ -147,6 +148,8 @@ void clear_timers(void)
all_timers.erase(it);
it = all_timers.begin();
}
+
+ running_since.clear();
}
bool timer::is_deferred(void)
diff --git a/src/process/work.cpp b/src/process/work.cpp
index 82f13a2..e436643 100644
--- a/src/process/work.cpp
+++ b/src/process/work.cpp
@@ -56,7 +56,8 @@ uint64_t work::done(uint64_t time, uint64_t work_struct)
{
int64_t delta;
- if (running_since[work_struct] time)
+ if (running_since.find(work_struct) == running_since.end() ||
+ running_since[work_struct] time)
return 0;
delta = time - running_since[work_struct];
@@ -102,6 +103,8 @@ void clear_work(void)
all_work.erase(it);
it = all_work.begin();
}
+
+ running_since.clear();
}
--
1.7.11.3
___
PowerTop mailing list
power...@lists.01.org
https://lists.01.org/mailman/listinfo/powertop
--
Regards,
Rajagopal
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 9/5/2012 9:56 AM, Rajagopal Venkat wrote: measure1: ev3.start ev1.end evX.end These events are causing numbers to go wrong. but out of a 20 second window.. this is a tiny tiny window... if you see 100.1% I'd buy this reasoning. but you're seeing much more than that. if so, then we're loosing events, which is no good. reporting less than 100% is ok, but reporting less than real is not. I did thought of it. Yes, agree that, we are loosing events for which start timestamp we can't lose those! those are the events that give us the initial CPU frequency in the window etc ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 5 September 2012 22:39, Arjan van de Ven ar...@linux.intel.com wrote: On 9/5/2012 9:56 AM, Rajagopal Venkat wrote: measure1: ev3.start ev1.end evX.end These events are causing numbers to go wrong. but out of a 20 second window.. this is a tiny tiny window... if you see 100.1% I'd buy this reasoning. but you're seeing much more than that. How about generating a report for 1sec duration? Since timestamp itself is added to accumulated_runtime, the usage percentage is really dependent on event end timestamp value. if so, then we're loosing events, which is no good. reporting less than 100% is ok, but reporting less than real is not. I did thought of it. Yes, agree that, we are loosing events for which start timestamp we can't lose those! those are the events that give us the initial CPU frequency in the window etc Yes agree. I will submit the next version patch considering those events end timestamp relative to first_stamp(src/process/do_process.cpp). -- Regards, Rajagopal ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 9/5/2012 10:19 AM, Rajagopal Venkat wrote: On 5 September 2012 22:39, Arjan van de Ven ar...@linux.intel.com wrote: On 9/5/2012 9:56 AM, Rajagopal Venkat wrote: measure1: ev3.start ev1.end evX.end These events are causing numbers to go wrong. but out of a 20 second window.. this is a tiny tiny window... if you see 100.1% I'd buy this reasoning. but you're seeing much more than that. How about generating a report for 1sec duration? even for 1 second... still it's miniscule compared to this whole 1 second the amount of setup/teardown time just is not that huge. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 5 September 2012 22:52, Arjan van de Ven ar...@linux.intel.com wrote: On 9/5/2012 10:19 AM, Rajagopal Venkat wrote: On 5 September 2012 22:39, Arjan van de Ven ar...@linux.intel.com wrote: On 9/5/2012 9:56 AM, Rajagopal Venkat wrote: measure1: ev3.start ev1.end evX.end These events are causing numbers to go wrong. but out of a 20 second window.. this is a tiny tiny window... if you see 100.1% I'd buy this reasoning. but you're seeing much more than that. How about generating a report for 1sec duration? even for 1 second... still it's miniscule compared to this whole 1 second the amount of setup/teardown time just is not that huge. Here are some perf timestamps, (3979299431) (3979303554) (4079217947) (4091306943) (4091322535) (4091336882) When 1sec report is generated and if above timestamp gets added to timer accumulated_runtime, no wonder why such huge usage is reported. -- Regards, Rajagopal ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] Fix timer and work perf events timestamp tracing
On 9/5/2012 10:45 AM, Rajagopal Venkat wrote: On 5 September 2012 22:52, Arjan van de Ven ar...@linux.intel.com wrote: On 9/5/2012 10:19 AM, Rajagopal Venkat wrote: On 5 September 2012 22:39, Arjan van de Ven ar...@linux.intel.com wrote: On 9/5/2012 9:56 AM, Rajagopal Venkat wrote: measure1: ev3.start ev1.end evX.end These events are causing numbers to go wrong. but out of a 20 second window.. this is a tiny tiny window... if you see 100.1% I'd buy this reasoning. but you're seeing much more than that. How about generating a report for 1sec duration? even for 1 second... still it's miniscule compared to this whole 1 second the amount of setup/teardown time just is not that huge. Here are some perf timestamps, (3979299431) (3979303554) (4079217947) (4091306943) (4091322535) (4091336882) When 1sec report is generated and if above timestamp gets added to timer accumulated_runtime, no wonder why such huge usage is reported. question is... how did these get here? is the kernel reporting garbage time ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v5] media: add v4l2 subdev driver for S5K4ECGX sensor
Hi Sangwook,
On 09/05/2012 02:28 PM, Sangwook Lee wrote:
This patch adds driver for S5K4ECGX sensor with embedded ISP SoC,
S5K4ECGX, which is a 5M CMOS Image sensor from Samsung
The driver implements preview mode of the S5K4ECGX sensor.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/brightness/sharpness
Signed-off-by: Sangwook Leesangwook@linaro.org
Cc: Sylwester Nawrockis.nawro...@samsung.com
Cc: Scott Bambroughscott.bambro...@linaro.org
Overall it looks good, thank you for patiently addressing all my
comments ;) There might be some rough edges here and there, but it's
all easy to fix. Please see below.
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v4:
- replaced register tables with the function from Sylwester
- updated firmware parsing function with CRC32 check
firmware generator from user space:
git://git.linaro.org/people/sangwook/fimc-v4l2-app.git
Changes since v3:
- used request_firmware to configure initial settings
- added parsing functions to read initial settings
- updated regulator API
- reduced preview setting tables by experiment
Changes since v2:
- added GPIO (reset/stby) and regulators
- updated I2C read/write, based on s5k6aa datasheet
- fixed set_fmt errors
- reduced register tables a bit
- removed vmalloc
Changes since v1:
- fixed s_stream(0) when it called twice
- changed mutex_X position to be used when strictly necessary
- add additional s_power(0) in case that error happens
- update more accurate debugging statements
- remove dummy else
drivers/media/i2c/Kconfig|7 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k4ecgx.c | 1019
++
include/media/s5k4ecgx.h | 37 ++
4 files changed, 1064 insertions(+)
create mode 100644 drivers/media/i2c/s5k4ecgx.c
create mode 100644 include/media/s5k4ecgx.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9a5a059..55b3bbb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -484,6 +484,13 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K4ECGX
+tristate Samsung S5K4ECGX sensor support
+depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
+---help---
+ This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M
+ camera sensor with an embedded SoC image signal processor.
+
source drivers/media/i2c/smiapp/Kconfig
comment Flash devices
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 088a460..a720812 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
new file mode 100644
index 000..0f12d46
--- /dev/null
+++ b/drivers/media/i2c/s5k4ecgx.c
@@ -0,0 +1,1019 @@
+/*
+ * Driver for s5k4ecgx (5MP Camera) from Samsung
+ * a quarter-inch optical format 1.4 micron 5 megapixel (Mp)
+ * CMOS image sensor.
+ *
+ * Copyright (C) 2012, Linaro, Sangwook Leesangwook@linaro.org
+ * Copyright (C) 2012, Insignal Co,. Ltd, Homin Leesuap...@insignal.co.kr
+ *
+ * Based on s5k6aa, noon010pc30 driver
+ * Copyright (C) 2011, Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#includelinux/clk.h
+#includelinux/crc32.h
+#includelinux/ctype.h
+#includelinux/delay.h
+#includelinux/firmware.h
+#includelinux/gpio.h
+#includelinux/i2c.h
+#includelinux/module.h
+#includelinux/regulator/consumer.h
+#includelinux/slab.h
+#includelinux/vmalloc.h
What do we need this header for ?
+
+#includemedia/media-entity.h
+#includemedia/s5k4ecgx.h
+#includemedia/v4l2-ctrls.h
+#includemedia/v4l2-device.h
+#includemedia/v4l2-mediabus.h
+#includemedia/v4l2-subdev.h
...
+
+static int s5k4ecgx_set_ahb_address(struct v4l2_subdev *sd)
+{
+ int ret;
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ /* Set APB peripherals start address */
+ ret = s5k4ecgx_i2c_write(client, AHB_MSB_ADDR_PTR, GEN_REG_OFFSH);
+ if (ret)
+ return ret;
+ /*
+ * FIXME: This is copied from
