RE: [gst-devel] Camerabin2 Prototype and IRC Meeting

[Sachin GUPTA]

Hi Rob,

   This doesnot seem to be based upon 3 port camera src bin that was in your 
branch.Is it something planned in future or there is someother plan.

Thanks
Sachin


From: linaro-dev-boun...@lists.linaro.org 
[mailto:linaro-dev-boun...@lists.linaro.org] On Behalf Of Clark, Rob
Sent: Sunday, December 05, 2010 11:00 PM
To: linaro-dev@lists.linaro.org
Subject: Fwd: [gst-devel] Camerabin2 Prototype and IRC Meeting

in case any of the multimedia/middleware folks interested in camerabin2 didn't 
notice this email from gst-devel list:

-- Forwarded message --
From: Thiago Sousa Santos 
mailto:thiago.sousa.san...@collabora.co.uk>>
Date: Fri, Dec 3, 2010 at 11:30 PM
Subject: Re: [gst-devel] Camerabin2 Prototype and IRC Meeting
To: Discussion of the development of GStreamer 
mailto:gstreamer-de...@lists.sourceforge.net>>


On Thu, 2010-12-02 at 12:07 -0300, Thiago Sousa Santos wrote:
> Hello,
>
> As mentioned some time ago, we started planning camerabin2.
>
> The good news is that a small prototype is ready at
> http://gitorious.org/gstreamer-camerabin2/gst-plugins-bad
>
> It is as simple as it gets, being able to take pictures, record videos
> and showing a viewfinder. Feedback, code review, patches, tests are
> welcome. I'm currently trying to get the code in shape to push it as an
> experimental plugin into -bad module.
>
> I'd like arrange meeting with people interested in camerabin2 to discuss
> desired features and problems with this new design. I'm already poking
> some people that mentioned interest to set up a date and time. We'd like
> to do this soon, so expect it to be early next week (Monday or Tuesday).

Based on the feedback I got from the interested people and their
timezones:
http://www.timeanddate.com/worldclock/meetingtime.html?day=7&month=12&year=2010&p1=101&p2=209&p3=64&p4=37

I guess 14PM UTC, Tuesday is a nice option. We'd meet on IRC on
#camerabin2.

Any major problems with this?

>
> Details on camerabin2 design are on the wiki:
> http://www.gstreamer.net/wiki/CameraBin
>
> --
> Thiago
>
>
>
> --
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> ___
> gstreamer-devel mailing list
> gstreamer-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



--
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
___
gstreamer-devel mailing list
gstreamer-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Dynamic hwcaps

[Dave Martin]

On Sun, Dec 5, 2010 at 2:12 PM, Thomas Petazzoni
 wrote:
> Hi,
>
> On Fri, 3 Dec 2010 16:28:27 +
> Dave Martin  wrote:
>
>> This allows for more active power management of such functional
>> blocks: if the CPU is not fully loaded, you can turn them off -- the
>> kernel can spot when there is significant idle time and do this.  If
>> the CPU becomes fully loaded, applications which have soft-realtime
>> constraints can notice this and switch to their accelerated code
>> (which will cause the kernel to switch the functional unit(s) on).
>> Or, the kernel can react to increasing CPU load by speculatively turn
>> it on instead.  This is analogous to the behaviour of other power
>> governors in the system.  Non-aware applications will still work
>> seamlessly -- these may simply run accelerated code if the hardware
>> supports it, causing the kernel to turn the affected functional
>> block(s) on.
>
> From a power management perspective, is it really useful to load the
> CPU instead of using specialized units which usually provide more
> computing power per watt consumed ?

No--- but you can't in general just exchange cycles on one functional
unit for cycles on another in the same way as you

Suppose 90% if your code (by execution time) can take advantage of a
specialised functional unit.  Should you turn that unit on?

Now, suppose only 5% of the code can take advantage, but the platform
is not completely busy.  Turning on a special functional unit consumes
extra power and will provide no speedup to the user -- is it still
worth turning it on?  What if the CPU is fully loaded doing other work
and your program is close to missing its realtime deadlines -- should
you turn on the separate unit now?

It not an easy thing to judge -- really, I'm just wondering whether
dynamic adaptation is feasible at all and whether it's worth
experimenting with...

> When the CPU is idle, it can enter sleep states to save power and let a
> more specialized unit do the optimized work. For example, when doing
> video decoding, probably specialized DSPs to a much better job from a
> power management perspective than the CPU would do, so it's better to
> keep the CPU idle and let the DSP do its video decoding job. No?

Often, definitely yes; however, it depends on various factors -- not
least, the software must have been ported to make use of the DSP in
order for this to be possible at all.

But the performance and power aspects are not trivial: separate DSP
units tend to have high setup and teardown costs, so as above, if the
total load on the DSP will be low, it may not be worth using it at all
from a power perspective; and using a DSP in the wrong way can also
lead to slower execution than doing everything on the CPU.

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Dynamic hwcaps

[Dave Martin]

On Sun, Dec 5, 2010 at 3:14 PM, Mark Mitchell  wrote:
> On 12/3/2010 11:35 AM, Dave Martin wrote:
>
>> What you describe is one of two mechanisms currently in use--- the
>> other is for a single library to contain two implementations of
>> certain functions and to choose between them based on the hwcaps.
>> Typically, one set of functions is chosen a library initialisation
>> time.  Some libraries, such as libpixman, are implementated this way;
>> and it's often preferable since the the proportion of functions in a
>> library which get significant benefit from special instruction set
>> extensions is often pretty small.
>
> I've believed for a long time that we should try to encourage this
> approach.  The current approach (different libraries for each hardware
> configuration) is prevalent, both in the toolchain ("multilibs") and in
> other libraries -- but it seems to me premised on the idea that one is
> building everything from source for one's particular hardware.  In the
> earlier days of FOSS, the typical installation model was to download a
> source tarball, build it, and install it on your local machine.  In that
> context, tuning the library "just so" for your machine made sense.  But,
> to enable binary distribution, having to have N copies of a library (let
> alone an application) for N different ARM core variants just doesn't
> make sense to me.

Just so, and as discussed before improvements to package managers
could help here to avoid installing duplicate libraries.  (I believe
that rpm may have some capability here (?) but deb does not at
present).

> So, I certainly think that things like STT_GNU_IFUNC (which enable
> determination of which routine to use at application start-up) make a
> lot of sense.
>
> I think your idea of exposing whether a unit is "ready", to allow even
> more fine-grained choices as an application runs, is clever.  I don't
> really know enough to say whether most applications could take advantage
> of that.  One of the problems I see is that you need global information,
> not local information.  In particular, if I'm using NEON to implement
> the inner loop of some performance-critical application, then when the
> unit is not ready, I want the kernel to wake it up already!  But, if I'm
> just using NEON to do some random computation off the critical path, I'm
> probably happy to do it slowly if that's more efficient than waking up
> the NEON unit.  But, which of these cases I'm in isn't always locally
> known at the point I'm doing the computation; the computation may be
> buried in a small library routine.

That's a fair concern -- I haven't explored the policy aspect much.
One possibility is that if the kernel sees system load nearing 100%,
it turns NEON on regardless.  But that's a pretty crude lever, and
might not bring a benefit if the software isn't able to use NEON.
Subtler approaches might involve the kernel collecting statistics on
applications' use of functional units, or some participation from
applications with realtime requirements.  Obviously, this is a but
fuzzy for now...

>
> Do we have good examples of applications that could profit from this
> capability?

Currently, I don't have many examples-- the main one is related to the
discussions aroung using NEON for memcpy().  This can be a performance
win on some platforms, but except when the system is heavily loaded,
or when NEON happens to be turned on anyway, it may not be
advantageous for the user or overall system performance.

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [gst-devel] Camerabin2 Prototype and IRC Meeting

[Clark, Rob]

Hi Sachin,

Thiago has pulled in my 3-port src bin patch into the camerabin2 plugin..
 only difference is for now everything is in gst/camerabin2 (whereas the
basecamsrc would need to be in gst-libs for it to be extended outside of the
camerabin2 plugin).  I'm not entirely sure why this was changed, but it
should be an easy thing to change back.

BR,
-R

On Mon, Dec 6, 2010 at 4:40 AM, Sachin GUPTA wrote:

>  Hi Rob,
>
>This doesnot seem to be based upon 3 port camera src bin that was in
> your branch.Is it something planned in future or there is someother plan.
>
> Thanks
> Sachin
>
>  --
> *From:* linaro-dev-boun...@lists.linaro.org [mailto:
> linaro-dev-boun...@lists.linaro.org] *On Behalf Of *Clark, Rob
> *Sent:* Sunday, December 05, 2010 11:00 PM
> *To:* linaro-dev@lists.linaro.org
> *Subject:* Fwd: [gst-devel] Camerabin2 Prototype and IRC Meeting
>
> in case any of the multimedia/middleware folks interested in camerabin2
> didn't notice this email from gst-devel list:
>
> -- Forwarded message --
> From: Thiago Sousa Santos 
> Date: Fri, Dec 3, 2010 at 11:30 PM
> Subject: Re: [gst-devel] Camerabin2 Prototype and IRC Meeting
> To: Discussion of the development of GStreamer <
> gstreamer-de...@lists.sourceforge.net>
>
>
> On Thu, 2010-12-02 at 12:07 -0300, Thiago Sousa Santos wrote:
> > Hello,
> >
> > As mentioned some time ago, we started planning camerabin2.
> >
> > The good news is that a small prototype is ready at
> > http://gitorious.org/gstreamer-camerabin2/gst-plugins-bad
> >
> > It is as simple as it gets, being able to take pictures, record videos
> > and showing a viewfinder. Feedback, code review, patches, tests are
> > welcome. I'm currently trying to get the code in shape to push it as an
> > experimental plugin into -bad module.
> >
> > I'd like arrange meeting with people interested in camerabin2 to discuss
> > desired features and problems with this new design. I'm already poking
> > some people that mentioned interest to set up a date and time. We'd like
> > to do this soon, so expect it to be early next week (Monday or Tuesday).
>
> Based on the feedback I got from the interested people and their
> timezones:
>
> http://www.timeanddate.com/worldclock/meetingtime.html?day=7&month=12&year=2010&p1=101&p2=209&p3=64&p4=37
>
> I guess 14PM UTC, Tuesday is a nice option. We'd meet on IRC on
> #camerabin2.
>
> Any major problems with this?
>
> >
> > Details on camerabin2 design are on the wiki:
> > http://www.gstreamer.net/wiki/CameraBin
> >
> > --
> > Thiago
> >
> >
> >
> >
> --
> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> > Tap into the largest installed PC base & get more eyes on your game by
> > optimizing for Intel(R) Graphics Technology. Get started today with the
> > Intel(R) Software Partner Program. Five $500 cash prizes are up for
> grabs.
> > http://p.sf.net/sfu/intelisp-dev2dev
> > ___
> > gstreamer-devel mailing list
> > gstreamer-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>
>
> --
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to
> build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
>  ___
> gstreamer-devel mailing list
> gstreamer-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Notes & Actions: Linaro User Platform Weekly Status Meeting 12/01

[Tom Gall]

Greetings,

Enclosed you'll find a link to the agenda, notes and actions from the
Linaro User Platforms Weekly Status meeting dated December 1st held in
#linaro-meeting on irc.freenode.net at 13:00 UTC.

https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-12-01

Status Summary:
* spandex benchmark suite packaged up and test definition for abrek created
* new spec created for autocolorspace convertor selection and playbin2
new property in gstreamer
* Implementation of GLProxy library begun
* Packaging of meegotouch compositor and companion packages begun
* All live-helper.configs updated for natty alpha1
* VP8 design document,Infrastructure related-Host Pc,Tools, ffmpeg etc

Regards,
Tom (tgall_foo)
User 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

[PATCH v2 0/3] ARM: omap: Thumb-2 kernel compatibility fixes

[Dave Martin]

These patches enable the omap kernel to build and work in
Thumb-2 (CONFIG_THUMB2_KERNEL).

They may make useful reading for all low-level BSP maintainers,
since in general similar issues tend to crop up whenever migrating
code to support Thumb-2.

Tested on: omap3 (Beagle xM A2)
Not tested on any other platforms yet.

Dave Martin (3):
  ARM: omap: Enable low-level omap3 PM code to work with
CONFIG_THUMB2_KERNEL
  ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL
  ARM: omap4: Convert END() to ENDPROC() for correct linkage with
CONFIG_THUMB2_KERNEL

 arch/arm/mach-omap2/include/mach/omap4-common.h |5 +++
 arch/arm/mach-omap2/omap-headsmp.S  |2 +-
 arch/arm/mach-omap2/omap44xx-smc.S  |8 ++--
 arch/arm/mach-omap2/pm.h|2 +
 arch/arm/mach-omap2/pm34xx.c|   13 ++--
 arch/arm/mach-omap2/sleep34xx.S |   37 +--
 arch/arm/mach-omap2/sram34xx.S  |   34 +++-
 arch/arm/plat-omap/include/plat/sram.h  |1 +
 arch/arm/plat-omap/sram.c   |   10 +-
 9 files changed, 90 insertions(+), 22 deletions(-)


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Dave Martin]

For the Thumb-2 case, the "wfi" mnemonic is used, since in this
case the tools will necessarily be new enough to support it.

Signed-off-by: Dave Martin 
---
KernelVersion: 2.6.37-rc4

 arch/arm/mach-omap2/include/mach/omap4-common.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h 
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 2744dfe..c6b1320 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -17,8 +17,13 @@
  * wfi used in low power code. Directly opcode is used instead
  * of instruction to avoid mulit-omap build break
  */
+#ifdef CONFIG_THUMB2_KERNEL
+#define do_wfi()   \
+   __asm__ __volatile__ ("wfi" : : : "memory")
+#else
 #define do_wfi()   \
__asm__ __volatile__ (".word0xe320f003" : : : "memory")
+#endif
 
 #ifdef CONFIG_CACHE_L2X0
 extern void __iomem *l2cache_base;
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v2 3/3] ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL

[Dave Martin]

almost all code for v7+ platforms) is deprecated/incorrect.

ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.

omap_secondary_startup might still need to be changed to ARM,
depending on the compatibility status of bootloaders.

Signed-off-by: Dave Martin 
---
KernelVersion: 2.6.37-rc4

 arch/arm/mach-omap2/omap-headsmp.S |2 +-
 arch/arm/mach-omap2/omap44xx-smc.S |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
b/arch/arm/mach-omap2/omap-headsmp.S
index 6ae937a..4ee6aec 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -45,5 +45,5 @@ hold: ldr r12,=0x103
 * should now contain the SVC stack for this core
 */
b   secondary_startup
-END(omap_secondary_startup)
+ENDPROC(omap_secondary_startup)
 
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S 
b/arch/arm/mach-omap2/omap44xx-smc.S
index 1980dc3..e69d37d 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -29,7 +29,7 @@ ENTRY(omap_smc1)
dsb
smc #0
ldmfd   sp!, {r2-r12, pc}
-END(omap_smc1)
+ENDPROC(omap_smc1)
 
 ENTRY(omap_modify_auxcoreboot0)
stmfd   sp!, {r1-r12, lr}
@@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
dsb
smc #0
ldmfd   sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
+ENDPROC(omap_modify_auxcoreboot0)
 
 ENTRY(omap_auxcoreboot_addr)
stmfd   sp!, {r2-r12, lr}
@@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
dsb
smc #0
ldmfd   sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
+ENDPROC(omap_auxcoreboot_addr)
 
 ENTRY(omap_read_auxcoreboot0)
stmfd   sp!, {r2-r12, lr}
@@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
smc #0
mov r0, r0, lsr #9
ldmfd   sp!, {r2-r12, pc}
-END(omap_read_auxcoreboot0)
+ENDPROC(omap_read_auxcoreboot0)
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: maverick linux-meta-linaro pull request

[Tim Gardner]

On 12/03/2010 10:01 PM, John Rigby wrote:

The following changes since commit 61cb9ff7af265a28043724678b4d3b0482c2e525:

   LINARO: Linaro-2.6.35.1008.13 (2010-10-22 07:02:42 -0600)

are available in the git repository at:
   git://git.linaro.org/ubuntu/linux-meta-linaro.git master

John Rigby (1):
   LINARO: Linaro-2.6.35.1010.14

  meta-source/debian/changelog |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)


Pulled, pushed, and uploaded.

--
Tim Gardner tim.gard...@canonical.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work with CONFIG_THUMB2_KERNEL

[Dave Martin]

sleep34xx.S, sram34xx.S:

  * Added ENDPROC() directives for all exported function symbols.
Without these, exported function symbols are not correctly
identified as Thumb by the linker, causing incorrect linkage.
This is needed to avoid some calls to the functions ending up
with the CPU in the wrong instruction set.

  * Added .align directives where needed to ensure that .word won't
be misaligned.  (Note that ENTRY() implies .align; no extra
.align has been added for these cases.)

  * Exported new "base address" symbols for functions which get
copied to sram by code outside sleep34xx.S (applies to
save_secure_ram_context and omap32xx_cpu_suspend), and fix up
the relevant address arithmetic so that these will be copied
and called correctly by the Thumb code in the rest of the
kernel.

  * Explicitly build a few parts of sleep34xx.S as ARM.

  * lock_scratchpad_sem is kept as ARM because of the need to
synchronise with hardware (?) using the SWP instruction.

  * save_secure_ram_context and omap34xx_cpu_suspend are built
as ARM in case the Secure World firmware expects to decode
the comment field from the SMC (aka smi) instructions.

This can be undone later if the firmware is confirmed as
able to decode the Thumb SMC encoding (or ignores the
comment field).

  * es3_sdrc_fix should presumably only be called from the
low-level wakeup code.  To minimise the diff, switched this
to ARM and demoted it to be a local symbol, since I believe
it shouldn't be called from outside anyway.

 To prevent future maintainence problems, it would probably be
 a good idea to demote _all_ functions which aren't called
 externally to local.  (i.e., everything except for
 get_es3_restore_pointer, get_restore_pointer,
 omap34xx_cpu_suspend and save_secure_ram_context).

 For now, I've left these as-is to minimise disruption.

   * Use a separate base register instead of PC-relative stores in
 sram34xx.S.  This isn't permitted in Thumb-2, but at least
 some versions of gas will silently output non-working code,
 leading to unpredictable run-time behaviour.

pm34xx.c, pm.h, sram.c, sram.h:

  * Resolve some memory addressing issues where a function symbol's
value is assumed to be equal to the start address of the
function body for the purpose of copying some low-level code
from sleep34xx.S to SRAM.

This assumption breaks for Thumb, since Thumb functions symbols
have bit 0 set to indicate the Thumb-ness.  This would result
in a non-working, off-by-one copy of the function body.

Tested on Beagle xM A2:
  * CONFIG_THUMB2_KERNEL && !CONFIG_SMP_ON_UP
  * CONFIG_THUMB2_KERNEL && CONFIG_SMP_ON_UP
  * !CONFIG_THUMB2_KERNEL && !CONFIG_SMP_ON_UP
  * !CONFIG_THUMB2_KERNEL && CONFIG_SMP_ON_UP

Signed-off-by: Dave Martin 
---
KernelVersion: 2.6.37-rc4

 arch/arm/mach-omap2/pm.h   |2 +
 arch/arm/mach-omap2/pm34xx.c   |   13 --
 arch/arm/mach-omap2/sleep34xx.S|   37 +--
 arch/arm/mach-omap2/sram34xx.S |   34 +---
 arch/arm/plat-omap/include/plat/sram.h |1 +
 arch/arm/plat-omap/sram.c  |   10 +++-
 6 files changed, 80 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..c333bfd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -80,7 +80,9 @@ extern void save_secure_ram_context(u32 *addr);
 extern void omap3_save_scratchpad_contents(void);
 
 extern unsigned int omap24xx_idle_loop_suspend_sz;
+extern char *const omap34xx_cpu_suspend_base;
 extern unsigned int omap34xx_suspend_sz;
+extern char *const save_secure_ram_context_base;
 extern unsigned int save_secure_ram_context_sz;
 extern unsigned int omap24xx_cpu_suspend_sz;
 extern unsigned int omap34xx_cpu_suspend_sz;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..93f0ee8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -982,11 +982,18 @@ static int __init clkdms_setup(struct clockdomain *clkdm, 
void *unused)
 
 void omap_push_sram_idle(void)
 {
-   _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
+   _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend_base,
omap34xx_cpu_suspend_sz);
-   if (omap_type() != OMAP2_DEVICE_TYPE_GP)
-   _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
+   _omap_sram_idle += (char *)omap34xx_cpu_suspend -
+   omap34xx_cpu_suspend_base;
+
+   if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+   _omap_save_secure_sram = omap_sram_push(
+   save_secure_ram_context_base,
save_secure_ram_context_sz);
+   _omap_save_secure_sram += (char *)

Re: maverick linux-linaro pull request

[Tim Gardner]

On 12/03/2010 09:18 PM, John Rigby wrote:

The following changes since commit 2140f30a928b2fc72af85257b15725ddc4144201:

   LINARO: Linaro-2.6.35-1008.15 (2010-10-21 11:24:58 -0600)

are available in the git repository at:
   git://git.linaro.org/ubuntu/linux-linaro.git master



Pulled, pushed, and uploaded with the addition of a tracking bug in the 
changelog (to which you are now assigned).


http://bugs.launchpad.net/bugs/686071

rtg
--
Tim Gardner tim.gard...@canonical.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work with CONFIG_THUMB2_KERNEL

[Catalin Marinas]

On 6 December 2010 17:35, Dave Martin  wrote:
>  * Explicitly build a few parts of sleep34xx.S as ARM.
>
>      * lock_scratchpad_sem is kept as ARM because of the need to
>        synchronise with hardware (?) using the SWP instruction.
>
>      * save_secure_ram_context and omap34xx_cpu_suspend are built
>        as ARM in case the Secure World firmware expects to decode
>        the comment field from the SMC (aka smi) instructions.
>
>        This can be undone later if the firmware is confirmed as
>        able to decode the Thumb SMC encoding (or ignores the
>        comment field).
>
>      * es3_sdrc_fix should presumably only be called from the
>        low-level wakeup code.  To minimise the diff, switched this
>        to ARM and demoted it to be a local symbol, since I believe
>        it shouldn't be called from outside anyway.

I haven't checked the code but does this always work? The kernel isn't
built with interworking enabled, so it's either ARM or Thumb-2.

-- 
Catalin

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work with CONFIG_THUMB2_KERNEL

[Dave Martin]

Hi,

On Mon, Dec 6, 2010 at 6:17 PM, Catalin Marinas  wrote:
> On 6 December 2010 17:35, Dave Martin  wrote:
>>  * Explicitly build a few parts of sleep34xx.S as ARM.
>>
>>      * lock_scratchpad_sem is kept as ARM because of the need to
>>        synchronise with hardware (?) using the SWP instruction.
>>
>>      * save_secure_ram_context and omap34xx_cpu_suspend are built
>>        as ARM in case the Secure World firmware expects to decode
>>        the comment field from the SMC (aka smi) instructions.
>>
>>        This can be undone later if the firmware is confirmed as
>>        able to decode the Thumb SMC encoding (or ignores the
>>        comment field).
>>
>>      * es3_sdrc_fix should presumably only be called from the
>>        low-level wakeup code.  To minimise the diff, switched this
>>        to ARM and demoted it to be a local symbol, since I believe
>>        it shouldn't be called from outside anyway.
>
> I haven't checked the code but does this always work? The kernel isn't
> built with interworking enabled, so it's either ARM or Thumb-2.

Interworking is mandated by EABI, and when building for EABI there is
no such thing as non-interworking C code IIUC: i.e.,
-mno-thumb-interwork does nothing.  Certainly, calls via a function
pointer are assembled as BX instructions, and the linker fixes up
static function calls with the right instruction (BL/BX).

Provided the affected functions are only called from C code, and
providing that legacy tools/ABI aren't used, it should work.  I've
reviewed to make sure that this is the case, and the code as posted
executes correctly on Beagle xM (not including the omap4-specific
code, for which I have no board to test on).

CONFIG_THUMB2_KERNEL already depends on CONFIG_AEABI, so we should be
relatively safe on this point.  Without CONFIG_THUMB2_KERNEL,
everything is built as ARM, so we have no problem.

The two cases where we have to be careful are:

  * Where code assumes that f == ,
which would lead to off-by-one errors by code which tries to copy
function bodies and derive pointers to the copies, due to the setting
of bit 0 of the address to indicate Thumb.  The patch series fix the
instances of this error present in the upstream OMAP BSP, except for
instances in code specific to OMAP2 and earlier which can't usefully
be built for Thumb-2 anyway.

  * Where bootloaders / firmware may jump directly into locations in
the kernel, and assume ARM (or don't interwork correctly), or where
the firmware may implicitly decode instructions from the caller as ARM
(e.g., to examine the SMC instruction comment field).  The most
straightforward way to avoid such problems is to make all such entry
points ARM.  But we could get rid of that if the platform maintainers
believe it's safe.


I did experiment with sticking with pure ARM in the low-level
assembler, with explicit veneers to switch instruction set, but that
gets rather messy and shouldn't really be necessary.  I suspect it
would be harder to maintain also.

Pure Thumb on the other hand is unlikely to be possible in every case:
the OMAP BSP uses SWP, and I've conservatively made the assumption
that bootloaders / firmware may assume they're jumping into ARM code,
and may try to decode SMC instructions as ARM instructions -- these
may not be true in practice, but these are harder to test, and I'm not
in a position to check _every_ bootloader/firmware/kernel combination
...

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[GIT PULL] ~dmart/linux-2.6-arm: i.MX Thumb-2 fixes (partial)

[Dave Martin]

The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac:

  ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 
-0500)

are available in the git repository at:
  git://git.linaro.org/people/dmart/linux-2.6-arm.git 
for-linaro-2.6.36/arm/mxc-thumb2

NOTE: These patches have not yet received any feedback and are
untested.  Consider carefully before merging them to an important
branch.

Dave Martin (1):
  ARM: mxc: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL

 arch/arm/plat-mxc/ssi-fiq.S |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[GIT PULL] ~dmart/linux-2.6-arm: Thumb-2/SMP-on-UP fixes accepted by rmk

[Dave Martin]

The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac:

  ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 
-0500)

are available in the git repository at:
  git://git.linaro.org/people/dmart/linux-2.6-arm.git 
for-linaro-2.6.36/accepted-by-rmk

Dave Martin (16):
  Revert "ARM: Avoid undefined Thumb-2 instructions using PC in 
compressed/head.S"
  ARM: kexec: Add missing memory clobber to inline asm in crash_setup_regs()
  ARM: kexec: Fix crash_setup_regs() for ARMv7 and CONFIG_THUMB2_KERNEL
  ARM: kuser: Fix incorrect cmpxchg syscall in kuser helpers
  ARM: RealView: Correct data alignment in headsmp.S for 
CONFIG_THUMB2_KERNEL
  ARM: vexpress: Correct data alignment in headsmp.S for 
CONFIG_THUMB2_KERNEL
  ARM: Allow SMP_ON_UP to work with Thumb-2 kernels.
  ARM: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL
  ARM: vfp: Correct data alignment for CONFIG_THUMB2_KERNEL
  ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in 
bootp/init.S
  ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in 
kernel/head.S
  ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in 
mm/proc-v7.S
  ARM: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S
  ARM: Thumb-2: Restore sensible zImage header layout for 
CONFIG_THUMB2_KERNEL
  ARM: Thumb-2: Fix long-distance conditional branches in head.S for 
Thumb-2.
  ARM: kprobes: Don't HAVE_KPROBES when CONFIG_THUMB2_KERNEL is selected

 arch/arm/Kconfig  |4 ++--
 arch/arm/boot/Makefile|5 -
 arch/arm/boot/bootp/init.S|2 ++
 arch/arm/boot/compressed/head.S   |   17 ++---
 arch/arm/include/asm/assembler.h  |   22 +++---
 arch/arm/include/asm/kexec.h  |   18 ++
 arch/arm/kernel/entry-armv.S  |6 +++---
 arch/arm/kernel/head.S|   20 +---
 arch/arm/kernel/relocate_kernel.S |2 ++
 arch/arm/mach-realview/headsmp.S  |1 +
 arch/arm/mach-vexpress/headsmp.S  |1 +
 arch/arm/mm/proc-v7.S |4 ++--
 arch/arm/vfp/vfphw.S  |1 +
 13 files changed, 74 insertions(+), 29 deletions(-)

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[GIT PULL] ~dmart/linux-2.6-arm: omap3/4 Thumb-2 fixes

[Dave Martin]

The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac:

  ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 
-0500)

are available in the git repository at:
  git://git.linaro.org/people/dmart/linux-2.6-arm.git 
for-linaro-2.6.36/arm/omap-thumb2

NOTE: These patches have not received significant upstream feedback
and have undergone limited testing.  Consider carefully before
merging these changes to an important branch.

Dave Martin (3):
  ARM: omap: Enable low-level omap3 PM code to work with 
CONFIG_THUMB2_KERNEL
  ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL
  ARM: omap4: Convert END() to ENDPROC() for correct linkage with 
CONFIG_THUMB2_KERNEL

 arch/arm/mach-omap2/include/mach/omap4-common.h |5 +++
 arch/arm/mach-omap2/omap-headsmp.S  |2 +-
 arch/arm/mach-omap2/omap44xx-smc.S  |8 ++--
 arch/arm/mach-omap2/pm.h|2 +
 arch/arm/mach-omap2/pm34xx.c|   13 ++--
 arch/arm/mach-omap2/sleep34xx.S |   37 +--
 arch/arm/mach-omap2/sram34xx.S  |   34 +++-
 arch/arm/plat-omap/include/plat/sram.h  |1 +
 arch/arm/plat-omap/sram.c   |   10 +-
 9 files changed, 90 insertions(+), 22 deletions(-)

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[GIT PULL] ~dmart/linux-2.6-arm: ux500 Thumb-2 fixes (partial)

[Dave Martin]

The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac:

  ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 
-0500)

are available in the git repository at:
  git://git.linaro.org/people/dmart/linux-2.6-arm.git 
for-linaro-2.6.36/arm/ux500-thumb2

NOTE: These patches have not yet received any feedback and are
untested.  Consider carefully before merging them to an important
branch.

Dave Martin (1):
  ARM: ux500: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL

 arch/arm/mach-ux500/headsmp.S |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[GIT PULL] ~dmart/linux-2.6-arm: toolchain bug workarounds for Thumb-2

[Dave Martin]

The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac:

  ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 
-0500)

are available in the git repository at:
  git://git.linaro.org/people/dmart/linux-2.6-arm.git 
for-linaro-2.6.36/dirty/gas-workarounds

NOTE: These patches are workarounds for toolchain bugs
and should not be merged in a branch intended to go upstream.

Dave Martin (2):
  Add local symbols in relocate_kernel.S to work around gas bugs
  ARM: omap: Work around gas pc-relative adr/ldr global label bug for 
Thumb-2

 arch/arm/kernel/relocate_kernel.S |   14 ++
 arch/arm/mach-omap2/sleep34xx.S   |3 ++-
 2 files changed, 12 insertions(+), 5 deletions(-)

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [GIT PULL] ~dmart/linux-2.6-arm: Thumb-2/SMP-on-UP fixes accepted by rmk

[Nicolas Pitre]

Merged and pushed out.  I also merged the OMAP bits since you tested 
them somewhat and I did have a look at it.  I also merged the gas 
workarounds (we're not mainline).  The rest will be for tomorrow.


On Mon, 6 Dec 2010, Dave Martin wrote:

> The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac:
> 
>   ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 
> -0500)
> 
> are available in the git repository at:
>   git://git.linaro.org/people/dmart/linux-2.6-arm.git 
> for-linaro-2.6.36/accepted-by-rmk
> 
> Dave Martin (16):
>   Revert "ARM: Avoid undefined Thumb-2 instructions using PC in 
> compressed/head.S"
>   ARM: kexec: Add missing memory clobber to inline asm in 
> crash_setup_regs()
>   ARM: kexec: Fix crash_setup_regs() for ARMv7 and CONFIG_THUMB2_KERNEL
>   ARM: kuser: Fix incorrect cmpxchg syscall in kuser helpers
>   ARM: RealView: Correct data alignment in headsmp.S for 
> CONFIG_THUMB2_KERNEL
>   ARM: vexpress: Correct data alignment in headsmp.S for 
> CONFIG_THUMB2_KERNEL
>   ARM: Allow SMP_ON_UP to work with Thumb-2 kernels.
>   ARM: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL
>   ARM: vfp: Correct data alignment for CONFIG_THUMB2_KERNEL
>   ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in 
> bootp/init.S
>   ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in 
> kernel/head.S
>   ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in 
> mm/proc-v7.S
>   ARM: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S
>   ARM: Thumb-2: Restore sensible zImage header layout for 
> CONFIG_THUMB2_KERNEL
>   ARM: Thumb-2: Fix long-distance conditional branches in head.S for 
> Thumb-2.
>   ARM: kprobes: Don't HAVE_KPROBES when CONFIG_THUMB2_KERNEL is selected
> 
>  arch/arm/Kconfig  |4 ++--
>  arch/arm/boot/Makefile|5 -
>  arch/arm/boot/bootp/init.S|2 ++
>  arch/arm/boot/compressed/head.S   |   17 ++---
>  arch/arm/include/asm/assembler.h  |   22 +++---
>  arch/arm/include/asm/kexec.h  |   18 ++
>  arch/arm/kernel/entry-armv.S  |6 +++---
>  arch/arm/kernel/head.S|   20 +---
>  arch/arm/kernel/relocate_kernel.S |2 ++
>  arch/arm/mach-realview/headsmp.S  |1 +
>  arch/arm/mach-vexpress/headsmp.S  |1 +
>  arch/arm/mm/proc-v7.S |4 ++--
>  arch/arm/vfp/vfphw.S  |1 +
>  13 files changed, 74 insertions(+), 29 deletions(-)
> 

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Accessing an A9 board

[Michael Hope]

Hi there.  Does anyone have a Cortex-A9 board with Maverick and a hard
disk that I could access?  I've heard that we've regressed on the A9
in some benchmarks from 4.4 to 4.5 and would like to verify.

-- Michael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Landing team pages?

[Michael Opdenacker]

Hi,

I can't find any details about the landing teams on the wiki, except
this https://wiki.linaro.org/LandingTeams

It would be useful to have a Wiki page per landing team, showing the
team members and the corresponding Launchpad pages (if any).

For example, I wanted to reply to a forum question
(http://www.linaro.org/linux-bsps/show/15), but didn't find any link to
the OMAP landing team.

Thank you in advance,

Cheers,

Michael.

-- 
Michael Opdenacker - Community Manager
Linaro, http://linaro.org
Cell: +33 621 604 642
IRC: 'opm' in #linaro on irc.freenode.net


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Dynamic hwcaps

[Mark Mitchell]

On 12/6/2010 5:07 AM, Dave Martin wrote:

>> But,
>> to enable binary distribution, having to have N copies of a library (let
>> alone an application) for N different ARM core variants just doesn't
>> make sense to me.
> 
> Just so, and as discussed before improvements to package managers
> could help here to avoid installing duplicate libraries.  (I believe
> that rpm may have some capability here (?) but deb does not at
> present).

Yes, a smarter package manager could help a device builder automatically
get the right version of a library.  But, something more fundamental has
to happen to avoid the library developer having to *produce* N versions
of a library.  (Yes, in theory, you just type "make" with different
CFLAGS options, but in practice of course it's often more complex than
that, especially if you need to validate the library.)

> Currently, I don't have many examples-- the main one is related to the
> discussions aroung using NEON for memcpy().  This can be a performance
> win on some platforms, but except when the system is heavily loaded,
> or when NEON happens to be turned on anyway, it may not be
> advantageous for the user or overall system performance.

How good of a proxy would the length of the copy be, do you think?  If
you want to copy 1G of data, and NEON makes you 2x-4x faster, then it
seems to me that you probably want to use NEON, almost independent of
overall system load.  But, if you're only going to copy 16 bytes, even
if NEON is faster, it's probably OK not to use it -- the function-call
overhead to get into memcpy at all is probably significant relative to
the time you'd save by using NEON.  In between, it's harder, of course
-- but perhaps if memcpy is the key example, we could get 80% of the
benefit of your idea simply by a test inside memcpy as to the length of
the data to be copied?

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

Dave,
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org; linaro-
> d...@lists.linaro.org
> Subject: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi()
> forCONFIG_THUMB2_KERNEL
>
> For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> case the tools will necessarily be new enough to support it.
>
> Signed-off-by: Dave Martin 
> ---
> KernelVersion: 2.6.37-rc4

The choice of opcode instead of instruction here was not because
of toolchain. The problem was it breaks multi-omap build where
ARMv6 and ARMv7 are build together.

For this reason I NAK this patch.

>
>  arch/arm/mach-omap2/include/mach/omap4-common.h |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> b/arch/arm/mach-omap2/include/mach/omap4-common.h
> index 2744dfe..c6b1320 100644
> --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> @@ -17,8 +17,13 @@
>   * wfi used in low power code. Directly opcode is used instead
>   * of instruction to avoid mulit-omap build break
>   */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define do_wfi() \
> + __asm__ __volatile__ ("wfi" : : : "memory")
> +#else
>  #define do_wfi() \
>   __asm__ __volatile__ (".word0xe320f003" : : :
"memory")
> +#endif
>
>  #ifdef CONFIG_CACHE_L2X0
>  extern void __iomem *l2cache_base;
> --
> 1.7.1
>
>
> ___
> 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

RE: [PATCH v2 3/3] ARM: omap4: Convert END() to ENDPROC() for correctlinkage with CONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org; linaro-
> d...@lists.linaro.org
> Subject: [PATCH v2 3/3] ARM: omap4: Convert END() to ENDPROC() for
> correctlinkage with CONFIG_THUMB2_KERNEL
>
> almost all code for v7+ platforms) is deprecated/incorrect.
>
> ENDPROC() tags the affected symbol as a function symbol, which will
> ensure that link-time fixups don't accidentally switch to the
> wrong instruction set.
>
> omap_secondary_startup might still need to be changed to ARM,
> depending on the compatibility status of bootloaders.
>
> Signed-off-by: Dave Martin 
> ---
> KernelVersion: 2.6.37-rc4

Looks ok to me.
Acked-by: Santosh Shilimkar 
>
>  arch/arm/mach-omap2/omap-headsmp.S |2 +-
>  arch/arm/mach-omap2/omap44xx-smc.S |8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-
> omap2/omap-headsmp.S
> index 6ae937a..4ee6aec 100644
> --- a/arch/arm/mach-omap2/omap-headsmp.S
> +++ b/arch/arm/mach-omap2/omap-headsmp.S
> @@ -45,5 +45,5 @@ hold:   ldr r12,=0x103
>* should now contain the SVC stack for this core
>*/
>   b   secondary_startup
> -END(omap_secondary_startup)
> +ENDPROC(omap_secondary_startup)
>
> diff --git a/arch/arm/mach-omap2/omap44xx-smc.S b/arch/arm/mach-
> omap2/omap44xx-smc.S
> index 1980dc3..e69d37d 100644
> --- a/arch/arm/mach-omap2/omap44xx-smc.S
> +++ b/arch/arm/mach-omap2/omap44xx-smc.S
> @@ -29,7 +29,7 @@ ENTRY(omap_smc1)
>   dsb
>   smc #0
>   ldmfd   sp!, {r2-r12, pc}
> -END(omap_smc1)
> +ENDPROC(omap_smc1)
>
>  ENTRY(omap_modify_auxcoreboot0)
>   stmfd   sp!, {r1-r12, lr}
> @@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
>   dsb
>   smc #0
>   ldmfd   sp!, {r1-r12, pc}
> -END(omap_modify_auxcoreboot0)
> +ENDPROC(omap_modify_auxcoreboot0)
>
>  ENTRY(omap_auxcoreboot_addr)
>   stmfd   sp!, {r2-r12, lr}
> @@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
>   dsb
>   smc #0
>   ldmfd   sp!, {r2-r12, pc}
> -END(omap_auxcoreboot_addr)
> +ENDPROC(omap_auxcoreboot_addr)
>
>  ENTRY(omap_read_auxcoreboot0)
>   stmfd   sp!, {r2-r12, lr}
> @@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
>   smc #0
>   mov r0, r0, lsr #9
>   ldmfd   sp!, {r2-r12, pc}
> -END(omap_read_auxcoreboot0)
> +ENDPROC(omap_read_auxcoreboot0)
> --
> 1.7.1
>
>
> ___
> 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

RE: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

Dave,
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org; linaro-
> d...@lists.linaro.org
> Subject: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to
work
> withCONFIG_THUMB2_KERNEL
>
> sleep34xx.S, sram34xx.S:
>
>   * Added ENDPROC() directives for all exported function symbols.
> Without these, exported function symbols are not correctly
> identified as Thumb by the linker, causing incorrect linkage.
> This is needed to avoid some calls to the functions ending up
> with the CPU in the wrong instruction set.
>
>   * Added .align directives where needed to ensure that .word won't
> be misaligned.  (Note that ENTRY() implies .align; no extra
> .align has been added for these cases.)
>
>   * Exported new "base address" symbols for functions which get
> copied to sram by code outside sleep34xx.S (applies to
> save_secure_ram_context and omap32xx_cpu_suspend), and fix up
> the relevant address arithmetic so that these will be copied
> and called correctly by the Thumb code in the rest of the
> kernel.
>
>   * Explicitly build a few parts of sleep34xx.S as ARM.
>
>   * lock_scratchpad_sem is kept as ARM because of the need to
> synchronise with hardware (?) using the SWP instruction.
>
>   * save_secure_ram_context and omap34xx_cpu_suspend are built
> as ARM in case the Secure World firmware expects to decode
> the comment field from the SMC (aka smi) instructions.
>
> This can be undone later if the firmware is confirmed as
> able to decode the Thumb SMC encoding (or ignores the
> comment field).
>
>   * es3_sdrc_fix should presumably only be called from the
> low-level wakeup code.  To minimise the diff, switched this
> to ARM and demoted it to be a local symbol, since I believe
> it shouldn't be called from outside anyway.
>
>  To prevent future maintainence problems, it would probably be
>  a good idea to demote _all_ functions which aren't called
>  externally to local.  (i.e., everything except for
>  get_es3_restore_pointer, get_restore_pointer,
>  omap34xx_cpu_suspend and save_secure_ram_context).
>
>  For now, I've left these as-is to minimise disruption.
>
>* Use a separate base register instead of PC-relative stores in
>  sram34xx.S.  This isn't permitted in Thumb-2, but at least
>  some versions of gas will silently output non-working code,
>  leading to unpredictable run-time behaviour.
>
> pm34xx.c, pm.h, sram.c, sram.h:
>
>   * Resolve some memory addressing issues where a function symbol's
> value is assumed to be equal to the start address of the
> function body for the purpose of copying some low-level code
> from sleep34xx.S to SRAM.
>
> This assumption breaks for Thumb, since Thumb functions symbols
> have bit 0 set to indicate the Thumb-ness.  This would result
> in a non-working, off-by-one copy of the function body.
>
> Tested on Beagle xM A2:
>   * CONFIG_THUMB2_KERNEL && !CONFIG_SMP_ON_UP
>   * CONFIG_THUMB2_KERNEL && CONFIG_SMP_ON_UP
>   * !CONFIG_THUMB2_KERNEL && !CONFIG_SMP_ON_UP
>   * !CONFIG_THUMB2_KERNEL && CONFIG_SMP_ON_UP
>
> Signed-off-by: Dave Martin 
> ---
> KernelVersion: 2.6.37-rc4

No need to mention but this patch changes lot of things around
power management code. You said " Tested on: omap3 (Beagle xM A2)"

What did you test ? Is it just boot test ? For sure just boot
test is not enough for this patch and needs to test the PM.

>
>  arch/arm/mach-omap2/pm.h   |2 +
>  arch/arm/mach-omap2/pm34xx.c   |   13 --
>  arch/arm/mach-omap2/sleep34xx.S|   37
> +--
>  arch/arm/mach-omap2/sram34xx.S |   34
+--
> -
>  arch/arm/plat-omap/include/plat/sram.h |1 +
>  arch/arm/plat-omap/sram.c  |   10 +++-
>  6 files changed, 80 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 0d75bfd..c333bfd 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -80,7 +80,9 @@ extern void save_secure_ram_context(u32 *addr);
>  extern void omap3_save_scratchpad_contents(void);
>
>  extern unsigned int omap24xx_idle_loop_suspend_sz;
> +extern char *const omap34xx_cpu_suspend_base;
>  extern unsigned int omap34xx_suspend_sz;
> +extern char *const save_secure_ram_context_base;
>  extern unsigned int save_secure_ram_context_sz;
>  extern unsigned int omap24xx_cpu_suspend_sz;
>  extern unsigned int omap34xx_cpu_suspend_sz;
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 0ec8a04..93f0ee8 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/a

Re: Landing team pages?

[Jamie Bennett]

On 7 Dec 2010, at 05:20, Michael Opdenacker  
wrote:

> Hi,
> 
> I can't find any details about the landing teams on the wiki, except
> this https://wiki.linaro.org/LandingTeams
> 
> It would be useful to have a Wiki page per landing team, showing the
> team members and the corresponding Launchpad pages (if any).

There will be when each Landing Team is established. The only one
currently active is the ST-E one and Lee (tech lead) has been asked
to create http://wiki.linaro.org/LandingTeams/ST-E.

> For example, I wanted to reply to a forum question
> (http://www.linaro.org/linux-bsps/show/15), but didn't find any link to
> the OMAP landing team.

That's because there currently isn't one.

> 
Regards,
Jamie.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Fwd: Scalable memory operations with multiple cores

[Robert Fekete]

Hi Everyone knowing awfully lot about memory management and multicore op,

My name is Robert Fekete and I work in the ST-Ericsson Landing Team.

I have a question regarding multicore SMP aware memory operations libc, and
I hope you can have an answer or at least direct me to someone who might
know better. I have already mailed Michael Hope who recommended me to mail
this list(of course).

The issue I am experiencing is that when I am running a memset operation(on
different non overlapping memory areas) on both cores simultaneously they
will affect each other and prolong the work of each processes/cpu's by a
factor of ~3-4(measured in Lauterabach).

i.e. assume a memset op that takes around 1ms (some really big buffer in a
for loop many times)

Non-simultaneous memsets: (total time 2ms, each process execution time 1ms,
x == running)
core1 :
core2 :

Simultaneous memsets: (total time 3ms , each process 3ms)
core1 :
core2 :

Well there are some factors that can explain parts of it.
There is a bandwidth limitation which will peak on one memset meaning that
two memsets cannot possibly go faster and a proper value should be around
2ms(not 3-4ms), The L2$ is 512k which may lead to severe L2$ mess up since
the sceduler is extremely fair and fine granular between the cores. L1$ will
also get hurt.

But the real issue is that the two totally different memops(big ones though)
in parallell will mess up for each other. Not good if one of the processes
on core 1(for example) is a high prio compositor and the second process on
core 2 is a lowprio crap application. The the Low prio crap App will
severely mess up for the compositor. OS prio does not propagate to bus
access prio.

Is there a way to make this behaviour a bit more deterministic...for the
high prio op at least, like a scalable memory operation libc variant.

I read an article about a similar issue on Intel CPUs and the solution in
this case is a scalable memory allocator lib.
http://software.intel.com/en-us/blogs/2009/08/21/is-your-memory-management-multi-core-ready/

More academic reading of the phenomenon:
http://books.google.com/books?id=NF-C2ZQZXekC&pg=PA353&lpg=PA353&dq=multi+core+memset+linux&source=bl&ots=O8mroWf4JM&sig=DZ9hWV-EozkaR9Kawakn5sB8FwQ&hl=en&ei=sgvkTN64CcaJhQf9xczcDg&sa=X&oi=book_result&ct=result&resnum=4&ved=0CCYQ6AEwAzgK#v=onepage&q&f=false

BR
/Robert Fekete
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev