Re: using cpuidle on panda board

2012-01-16 Thread Vincent Guittot 
Hi All,

Thanks for these information, My understand is that I should wait for
the adaptation of the SMP cpuidle proposal for omap4.

Andy, could you warn me when you will have a running smp cpu idle
driver for panda ?

Regards,
Vincent

On 14 January 2012 08:55, Andy Green  wrote:
> On 01/14/2012 12:52 PM, Somebody in the thread at some point said:
>>
>> On Fri, Jan 13, 2012 at 2:41 PM, Amit Kucheria
>>  wrote:
>>>
>>> On Fri, Jan 13, 2012 at 7:14 PM, Dechesne, Nicolas
>>>  wrote:



 On Fri, Jan 13, 2012 at 5:59 PM, Andy Green
  wrote:
>
>
> Amit, do you know of a good place to raid for better cpuidle, closer to
> upstream than OZ?



 wasn't that merged in 3.2? are you looking for that :

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9827266
>>>
>>>
>>> What was merged depends on hotplug, it isn't SMP cpuidle. At this
>>> point, I'm quite confused about the history on what happened to the
>>> SMP cpuidle driver and why it wasn't merged. Mike or Kevin should
>>> know.
>>
>>
>> Amit is correct.  The hotplug-dependent cpuidle got merged.
>>
>> The SMP CPUidle patches have been put on the list and should work
>> patch into a recent kernel:
>> http://article.gmane.org/gmane.linux.ports.tegra/2649
>>
>> However the OMAP4 support seems to be missing:
>> http://article.gmane.org/gmane.linux.ports.arm.omap/69186
>>
>> So this isn't straightforward, but at least it's headed in the right
>> direction.
>
>
> Thanks for the info... it sounds like we should try to add the SMP CPUidle
> from upstream and ask Santosh for his patches and see what happens.
>
> Unfortunately we've been trying to use Andrey's new linux-linaro-tracking as
> a basis and despite fixing some of the problems the resulting tree still
> blows chunks midway through boot.  So I think we'll have to give up on that
> for now and retry later.
>
> -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

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

Re: Architectures to support when releasing binaries

2012-01-16 Thread Javier Martinez Canillas 
On Mon, Jan 16, 2012 at 3:32 AM, Michael Hope  wrote:
> Hi there.  I have a style question.  For the pre-built versions of
> gcc-linaro, should we release a i686 version that also runs on x86_64,
> or do separate i686 and x86_64 builds?
>
> If we do just an i686 version then:
>  * There's less to test
>  * There's one 'linux' binary so less confusion on what to download
> and a simpler download page
>  * Most end users will already have the 32 bit libraries due to Skype or Flash
>
> but it has some downsides:
>  * May not work 'out of the box'
>  * Cryptic failures if you don't have the 32 bit libraries installed
>  * Some users can't install extra packages and may not be allowed the
> 32 bit libraries
>
> There's no real performance or compatibility advantage in also having
> an x86_64 build.
>
> Any thoughts?  I quite like having an i686 only build but am worried
> about the initial experience.
>
> -- Michael
>

Hello Michael,

I've been using the Linaro toolchain in Ubuntu for about 6 months and
a few days ago installed on a machine with Fedora x86_64. I'm not an
GCC expert so probably I'm on the initial experience group.

Since Linaro doesn't have rpms for its tool-chain I first tried to
install each package from source (gcc, gdb, binutils, etc) but then
found your pre-built binaries download page. For me it worked
out-of-the-box, I just had to install the Fedora Linux Standard Base
and 32 lib compatibility packages.

I don't really care if there is some performance gain using an x86_64
tool-chain since I only care of the ARMv7 generated binaries
performance. In this regard the Linaro GCC is far more better than
other ARM compilers both in the size of the generated binaries and
their execution time on our board.

 So, I think is not necessary to have a pre-built version for x86_64.
Users that want an x86_64 tool-chain can always build it using the
crosstool-NG IMHO.

Hope it helps,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain

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

[ACTIVITY] Multimedia WG weekly status report - wk02.2012 (20120109-20120113)

2012-01-16 Thread Ilias Biris 
Hi

please below the summary of the work in Multimedia WG for wk02.2012. The
detailed report (with links) is in
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport

Last meeting minutes are in:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2012-01-10

Achievements
- libjpeg-turbo: updated android code to latest, tjunittest (1 failure),
tjbench, skia-bench. skia-bench not great, new blueprint created to
address (565 and  unoptimized), looking at past qualcomm code.
- linarotv-xbmc live-config building successful. bp complete.
- For DRM : moved to 12.04 / armhf fs, rebuild xserver 1.12 RC1 and
related trees rebase and resubmitted final version of few omapdrm
patches for api changes coming in through drm-next (drmplane/addfb2) and
fbdev-next (omapdss fifomerge api changes)
- Added ucm configs for mx53 HDMI card, added channels and priority
properties in ucm4pa code. Also added priority to ucm config for mx53 to
make analog jack the default sink
- CMA LAVA test running - but also needs to be split into multiple
shorter tests, as it runs out of time
- Porting capture to tinyalsa for e2e audio test support
- Created a git repo for the Speex release for Android
(speex_linaro_android.git under ronynandy in git.linaro.org - there is a
problem preventing it to show properly in gitweb - not being solved by IS)

Issues
- Bug #893402
(https://bugs.launchpad.net/linaro-landing-team-ti/+bug/893402) is
impeding progress in end-to-end audio testing (only a prototype is
available for desktop - pandaboard is not functional). We're working on
the bug, the focus has passed to alsa-lib, pulseaudio and the UCM configs
- #911860 (https://bugs.launchpad.net/bugs/911860) Android NEON
detection is busticated - working on it now
- #912035 (https://bugs.launchpad.net/bugs/912035) Android: skia-bench
segvs - Fix Committed
- #898395 (https://bugs.launchpad.net/bugs/898395) jpegint.h missing in
-dev package - Fix Committed

Risks:
Codec optimisation work: we have 3 blueprints in 12.01 for codecs
optimisation, and we are checking if there will be some which will come
after 12.01

Best regards,


-- 
Ilias Biris ilias.bi...@linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs

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

Re: DisableSuspend.apk

2012-01-16 Thread yong qin 
Hi, all

>> The command  below seems can also disable suspend.
>> adb shell service call power 1 i32 26
this command only seems not works well.

I write a shell script (see the attachment), and run it as following will
disable the suspend:
1.  execute the script
2.  restart android
3.  execute the script again
 I don't know why should execute twice,
 but doing twice do disable the suspend:(

I had tried it on landing-panda#31, and alf_ helped to try on snowball.

Thanks, alf_!

I also wrote a HOWTO about disabling suspend,

https://wiki.linaro.org/Platform/Android/DisableSuspend

please for your reference.

Thanks,
Yongqin Liu

On 15 January 2012 10:45, Zach Pfeffer  wrote:

> Adding the right linaro-android list and the .apk.
>
> On 14 January 2012 20:30, Zach Pfeffer  wrote:
> > Cool. That's a keeper! Thanks!
> >
> > Attached my DisableSuspend.apk.
> >
> > On 14 January 2012 06:44, yong qin  wrote:
> >> Hi, All
> >>
> >> The command  below seems can also disable suspend.
> >> adb shell service call power 1 i32 26
> >>
> >> I have tried on landing-panda and staging-panda, both works.
> >>
> >> Thanks,
> >> Yongqin Liu
> >>
> >> On 22 October 2011 11:10, Zach Pfeffer  wrote:
> >>>
> >>> This will disable suspend (like if you're showing a demo off).
> >>>
> >>>
> >>> -- Forwarded message --
> >>> From: Zach Pfeffer 
> >>> Date: 21 October 2011 20:33
> >>> Subject: Re: DisableSuspend.apk
> >>> To: "bernhard.rosenkranzer" 
> >>>
> >>>
> >>> Sorry, this will work better.
> >>>
> >>> On 21 October 2011 19:58, Zach Pfeffer 
> wrote:
> >>> > Try this
> >>> >
> >>> > --
> >>> > Zach Pfeffer
> >>> > Android Platform Team Lead, Linaro Platform Teams
> >>> > Linaro.org | Open source software for ARM SoCs
> >>> > Follow Linaro: http://www.facebook.com/pages/Linaro
> >>> > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Zach Pfeffer
> >>> Android Platform Team Lead, Linaro Platform Teams
> >>> Linaro.org | Open source software for ARM SoCs
> >>> Follow Linaro: http://www.facebook.com/pages/Linaro
> >>> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
> >>>
> >>>
> >>>
> >>> --
> >>> Zach Pfeffer
> >>> Android Platform Team Lead, Linaro Platform Teams
> >>> Linaro.org | Open source software for ARM SoCs
> >>> Follow Linaro: http://www.facebook.com/pages/Linaro
> >>> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
> >>
> >>
> >
> >
> >
> > --
> > Zach Pfeffer
> > Android Platform Team Lead, Linaro Platform Teams
> > Linaro.org | Open source software for ARM SoCs
> > Follow Linaro: http://www.facebook.com/pages/Linaro
> > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
>
>
>
> --
> Zach Pfeffer
> Android Platform Team Lead, Linaro Platform Teams
> Linaro.org | Open source software for ARM SoCs
> Follow Linaro: http://www.facebook.com/pages/Linaro
> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
>


disbalesuspend.sh
Description: Bourne shell script
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: DisableSuspend.apk

2012-01-16 Thread Alexander Sack 
On Mon, Jan 16, 2012 at 12:45 PM, yong qin  wrote:
> Hi, all
>
>>> The command  below seems can also disable suspend.
>>>     adb shell service call power 1 i32 26
> this command only seems not works well.
>
> I write a shell script (see the attachment), and run it as following will
> disable the suspend:
> 1.  execute the script
> 2.  restart android
> 3.  execute the script again
>      I don't know why should execute twice,
>      but doing twice do disable the suspend:(

The "shell service call power ..." is probably just a runtime setting?
so we have to run it on every boot, no?

Can we add this to a generic place in lava-android-test (or
dispatcher) to ensure we call this first thing every time when booting
up a unit?

-- 
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Re: [ACTIVITY] Multimedia WG weekly status report - wk02.2012 (20120109-20120113)

2012-01-16 Thread Ilias Biris 
On 16/01/12 12:48, Ilias Biris wrote:
> (speex_linaro_android.git under ronynandy in git.linaro.org - there is a
> problem preventing it to show properly in gitweb - not being solved by IS)

Minor typo, it should read "now being solved by IS"

thanks

-- 
Ilias Biris ilias.bi...@linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs

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

Re: Architectures to support when releasing binaries

2012-01-16 Thread Alexander Sack 
On Mon, Jan 16, 2012 at 3:32 AM, Michael Hope  wrote:
> Hi there.  I have a style question.  For the pre-built versions of
> gcc-linaro, should we release a i686 version that also runs on x86_64,
> or do separate i686 and x86_64 builds?
>
> If we do just an i686 version then:
>  * There's less to test
>  * There's one 'linux' binary so less confusion on what to download
> and a simpler download page
>  * Most end users will already have the 32 bit libraries due to Skype or Flash
>
> but it has some downsides:
>  * May not work 'out of the box'
>  * Cryptic failures if you don't have the 32 bit libraries installed

Can we improve error reporting for those? Or maybe shipping a
check-install script that probes for proper 32-bit libs?

>  * Some users can't install extra packages and may not be allowed the
> 32 bit libraries

What libs are potentially missing? How many of those could get linked
in statically?

-- 
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Re: [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation

2012-01-16 Thread Rob Lee 
>> I don't like how ACTIVE does not have available notification callbacks
>> like HOT and CRITICAL do.  Perhaps I fail to grasp why they aren't there
>> but besides just applying a cooling device, one might want to do something
>> else as well upon hitting these trip points.  So that said, it might be nice
>> to add a notification to STATE_ACTIVE as well.
> Well I added ACTIVE_STATE trip type as just some additional features
> over trip type ACTIVE. Also each thermal zone can have more then one
> trip types so HOT notifications can still be used. But I like your
> suggestion of putting notfications in all the trip types. Lets see if
> the maintainers agree to this idea.
Thinking about it a bit more, I didn't consider HOT because it only
notifies when you cross above this trip point and not below and the
use case I had in mind would ideally want to be notified in both
cases.  Also, if ACTIVE/ACTIVE_STATE trip types will always have
cooling devices bound to them, then the notification could be put in
the cooling device code if desired.  I think these features are
separate from your main effort and can be addressed in separate future
patch.

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

[PATCH] mx53_loco: add DA9053 PMIC support

2012-01-16 Thread Ying-Chun Liu (PaulLiu) 
From: "Ying-Chun Liu (PaulLiu)" 

Hi,

This patch adds da9053 init for Freescale QuickStart Loco board.
DA9053 is a MFD device. On QuickStart Loco board we are using the regulators
provided by it.

Please help us to review this patch.

Many Thanks.

Ying-Chun Liu (PaulLiu) (1):
  mx53_loco: add DA9053 PMIC support

 arch/arm/mach-mx5/board-mx53_loco.c   |  128 +
 arch/arm/plat-mxc/include/mach/irqs.h |   10 +++-
 2 files changed, 137 insertions(+), 1 deletions(-)

-- 
1.7.8.3


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

[PATCH] mx53_loco: add DA9053 PMIC support

2012-01-16 Thread Ying-Chun Liu (PaulLiu) 
From: "Ying-Chun Liu (PaulLiu)" 

Add DA9052 PMIC support for Freescale QuickStart Loco board.
The model of PMIC on QuickStart Loco board is "da9053-aa".

Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: Amit Kucheria 
Cc: Sascha Hauer 
---
 arch/arm/mach-mx5/board-mx53_loco.c   |  128 +
 arch/arm/plat-mxc/include/mach/irqs.h |   10 +++-
 2 files changed, 137 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mx5/board-mx53_loco.c 
b/arch/arm/mach-mx5/board-mx53_loco.c
index fd8b524..61dd8c9 100644
--- a/arch/arm/mach-mx5/board-mx53_loco.c
+++ b/arch/arm/mach-mx5/board-mx53_loco.c
@@ -23,10 +23,21 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -45,6 +56,32 @@
 #define LOCO_SD1_CDIMX_GPIO_NR(3, 13)
 #define LOCO_ACCEL_EN  IMX_GPIO_NR(6, 14)
 
+#define DA9052_LDO1_VOLT_UPPER 1800
+#define DA9052_LDO1_VOLT_LOWER 600
+#define DA9052_LDO1_VOLT_STEP  50
+#define DA9052_LDO2_VOLT_UPPER 1800
+#define DA9052_LDO2_VOLT_LOWER 600
+#define DA9052_LDO2_VOLT_STEP  25
+#define DA9052_LDO34_VOLT_UPPER3300
+#define DA9052_LDO34_VOLT_LOWER1725
+#define DA9052_LDO34_VOLT_STEP 25
+#define DA9052_LDO567810_VOLT_UPPER3600
+#define DA9052_LDO567810_VOLT_LOWER1200
+#define DA9052_LDO567810_VOLT_STEP 50
+#define DA9052_LDO9_VOLT_STEP  50
+#define DA9052_LDO9_VOLT_LOWER 1250
+#define DA9052_LDO9_VOLT_UPPER 3650
+/* Buck Config Validation Macros */
+#define DA9052_BUCK_CORE_PRO_VOLT_UPPER2075
+#define DA9052_BUCK_CORE_PRO_VOLT_LOWER500
+#define DA9052_BUCK_CORE_PRO_STEP  25
+#define DA9052_BUCK_MEM_VOLT_UPPER 2500
+#define DA9052_BUCK_MEM_VOLT_LOWER 925
+#define DA9052_BUCK_MEM_STEP   25
+#define DA9052_BUCK_PERI_VOLT_UPPER2500
+#define DA9052_BUCK_PERI_VOLT_LOWER925
+#define DA9052_BUCK_PERI_STEP  25
+
 static iomux_v3_cfg_t mx53_loco_pads[] = {
/* FEC */
MX53_PAD_FEC_MDC__FEC_MDC,
@@ -227,6 +264,93 @@ static const struct esdhc_platform_data mx53_loco_sd3_data 
__initconst = {
.wp_type = ESDHC_WP_GPIO,
 };
 
+#define DA9052_LDO(max, min, rname, suspend_mv) \
+{\
+   .constraints = {\
+   .name   = (rname), \
+   .max_uV = (max) * 1000,\
+   .min_uV = (min) * 1000,\
+   .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE\
+   |REGULATOR_CHANGE_STATUS | REGULATOR_CHANGE_MODE,\
+   .valid_modes_mask = REGULATOR_MODE_NORMAL,\
+   .state_mem = { \
+   .uV = suspend_mv * 1000, \
+   .mode = REGULATOR_MODE_NORMAL, \
+   .enabled = (0 == suspend_mv) ? 0 : 1, \
+   .disabled = 0, \
+   }, \
+   },\
+}
+
+/* currently the suspend_mv here takes no effects for DA9053
+preset-voltage have to be done in the latest stage during
+suspend*/
+static struct regulator_init_data da9052_regulators_init[] = {
+   /* BUCKS */
+   DA9052_LDO(DA9052_BUCK_CORE_PRO_VOLT_UPPER,
+  DA9052_BUCK_CORE_PRO_VOLT_LOWER, "DA9052_BUCK_CORE", 850),
+   DA9052_LDO(DA9052_BUCK_CORE_PRO_VOLT_UPPER,
+  DA9052_BUCK_CORE_PRO_VOLT_LOWER, "DA9052_BUCK_PRO", 950),
+   DA9052_LDO(DA9052_BUCK_MEM_VOLT_UPPER,
+  DA9052_BUCK_MEM_VOLT_LOWER, "DA9052_BUCK_MEM", 1500),
+   DA9052_LDO(DA9052_BUCK_PERI_VOLT_UPPER,
+  DA9052_BUCK_PERI_VOLT_LOWER, "DA9052_BUCK_PERI", 2500),
+   DA9052_LDO(DA9052_LDO1_VOLT_UPPER,
+  DA9052_LDO1_VOLT_LOWER, "DA9052_LDO1", 1300),
+   DA9052_LDO(DA9052_LDO2_VOLT_UPPER,
+  DA9052_LDO2_VOLT_LOWER, "DA9052_LDO2", 1300),
+   DA9052_LDO(DA9052_LDO34_VOLT_UPPER,
+  DA9052_LDO34_VOLT_LOWER, "DA9052_LDO3", 3300),
+   DA9052_LDO(DA9052_LDO34_VOLT_UPPER,
+  DA9052_LDO34_VOLT_LOWER, "DA9052_LDO4", 2775),
+   DA9052_LDO(DA9052_LDO567810_VOLT_UPPER,
+  DA9052_LDO567810_VOLT_LOWER, "DA9052_LDO5", 1300),
+   DA9052_LDO(DA9052_LDO567810_VOLT_UPPER,
+  DA9052_LDO567810_VOLT_LOWER, "DA9052_LDO6", 1200),
+   DA9052_LDO(DA9052_LDO567810_VOLT_UPPER,
+  DA9052_LDO567810_VOLT_LOWER, "DA9052_LDO7", 2750),
+   DA9052_LDO(DA9052_LDO567810_VOLT_UPPER,
+  DA9052_LDO567810_VOLT_LOWER, "DA9052_LDO8", 1800),
+   DA9052_LDO(DA9052_LDO9_VOLT_UPPER,
+  DA9052_LDO9_VOLT_LOWER, "DA9052_LDO9", 2500),
+   DA9052_LDO(D

Re: DisableSuspend.apk

2012-01-16 Thread Paul Larson 
> The "shell service call power ..." is probably just a runtime setting?
> so we have to run it on every boot, no?
>
> Can we add this to a generic place in lava-android-test (or
> dispatcher) to ensure we call this first thing every time when booting
> up a unit?
>
> I shoved it temporarily into my dispatcher running locally.  A better
solution going forward is to probably allow for some board-defined extra
setup steps that run right after boot.  In this case, I also had to add a
sleep for about 15 seconds because this service doesn't seem to be
available as soon as the board is booted.

It does work great though, and I'm able to keep the board up and running
with it!  Thanks for figuring this out Yongqin!

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

Re: DisableSuspend.apk

2012-01-16 Thread Alexander Sack 
On Mon, Jan 16, 2012 at 6:24 PM, Paul Larson  wrote:
>
>> The "shell service call power ..." is probably just a runtime setting?
>> so we have to run it on every boot, no?
>>
>> Can we add this to a generic place in lava-android-test (or
>> dispatcher) to ensure we call this first thing every time when booting
>> up a unit?
>>
> I shoved it temporarily into my dispatcher running locally.  A better
> solution going forward is to probably allow for some board-defined extra
> setup steps that run right after boot.  In this case, I also had to add a


My understanding is that this is not a board specific feature and we
have to disable suspend on all boards that run android in LAVA.

> It does work great though, and I'm able to keep the board up and running
> with it!  Thanks for figuring this out Yongqin!
>

cool...

-- 
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Linaro 12.01 release dates and deliveries

2012-01-16 Thread David Zinman 
Greetings,

This is a mail sent to remind you the coming release dates:

* Platform/LTs/WGs components release is January 19th, 2012.
* Linaro 12.01 RC images is January 23rd, 2012.
* Linaro 12.01 release is January 26th, 2012.

Please, confirm the list of components planned to be delivered this month:
http://wiki.linaro.org/Cycles/1201/Release/Status

The release dates and deliveries information is available from the
releasedashboard: http://wiki.linaro.org/Cycles/1201/Release/Dashboard

-- 
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs

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

Re: Linaro 12.01 release dates and deliveries

2012-01-16 Thread Anca Emanuel 
Are you planing something for Precise Pangolin ?
There are LTS plans ?
The time left to decisions is very limited.

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

Re: boot armv7 on qemu-linaro

2012-01-16 Thread Andrei Gherzan 
I just cannot make it (qemu) print all serial messages in in default 
qemu windows and not in the terminal.
If i don't use the argument -serial, i still have to CTRL+3 in the qemu 
window to see serial messages. Any ideas? How can i have all serial 
messages in the default qemu window?


@g

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

Cortex a15 in linaro?

2012-01-16 Thread Andrei Gherzan 

Hello.

Is there any cortex a15 board emulated in linaro?

Thank you,
@g

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

Re: Cortex a15 in linaro?

2012-01-16 Thread Peter Maydell 
On 16 January 2012 18:43, Andrei Gherzan  wrote:
> Is there any cortex a15 board emulated in linaro?

You don't say specifically but I'm going to assume you mean
"in qemu-linaro".

I'm working on a patchset for the Versatile Express A15 board.
This is currently in the "upstream review" stage. There are some
big caveats, though:
 * the A15 CPU emulated will *not* include emulation of LPAE,
   Virtualization extensions or TrustZone; you can boot a Linux
   kernel compiled for A15-without-LPAE, but this is definitely
   not going to be of any use to you if you wanted to test
   Xen/KVM/hypervisor type code on a model.
 * this is not (at least initially) going to be a "supported"
   platform model for Linaro, as it is primarily intended to
   help us as we work on KVM for the Cortex-A15. So you can try
   it but we don't promise to do anything if it doesn't work :-)
 * there is not as yet any Linaro "hardware pack" for the A15,
   so you will be on your own for putting together a kernel,
   user space, etc.

Having said that, it's quite likely a vexpress-a15 will appear in
qemu-linaro 2012.02.

-- PMM

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

Re: [PATCH] mx53_loco: add DA9053 PMIC support

2012-01-16 Thread Mark Brown 
On Tue, Jan 17, 2012 at 01:10:53AM +0800, Ying-Chun Liu (PaulLiu) wrote:

> +#define DA9052_LDO1_VOLT_UPPER   1800
> +#define DA9052_LDO1_VOLT_LOWER   600
> +#define DA9052_LDO1_VOLT_STEP50

This is almost certainly wrong - you should rarely if ever need the
voltage step in a consumer or machine driver.  

> +#define DA9052_LDO(max, min, rname, suspend_mv) \
> +{\
> + .constraints = {\
> + .name   = (rname), \
> + .max_uV = (max) * 1000,\
> + .min_uV = (min) * 1000,\
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE\
> + |REGULATOR_CHANGE_STATUS | REGULATOR_CHANGE_MODE,\
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,\

This looks *very* odd - apart from anything else you're setting
REGULATOR_CHANGE_MODE but only permitting one mode.  You're also
allowing things to be changed but not providing any consumers which
means nothing can ever change any of them.

It looks awfully like you've just copied the supported feature set of
the PMIC rather than configured things for your board.

> +static struct regulator_init_data da9052_regulators_init[] = {
> + /* BUCKS */
> + DA9052_LDO(DA9052_BUCK_CORE_PRO_VOLT_UPPER,
> +DA9052_BUCK_CORE_PRO_VOLT_LOWER, "DA9052_BUCK_CORE", 850),

If you're going to specify names they should be names which are
meaningful for your board - usually the name used to identify the
relevant rail or rails in the schematic.

> +#define MX53_LOCO_DA9052_IRQ (6*32 + 11) /* GPIO7_11 */
> +
> +static int __init loco_da9052_init(struct da9052 *da9052)
> +{
> + /* Configuring for DA9052 interrupt servce */
> + /* s3c_gpio_setpull(DA9052_IRQ_PIN, S3C_GPIO_PULL_UP); */
> +

I apprecate that my code can be inspirational at times but you probably
don't want to cut'n'paste this bit.  :)

> + /* Set interrupt as LOW LEVEL interrupt source */
> + irq_set_irq_type(gpio_to_irq(MX53_LOCO_DA9052_IRQ),
> +  IRQF_TRIGGER_LOW);

Why is this needed?  The PMIC driver should do the right thing when it
requests the interrupt...

> @@ -273,6 +397,10 @@ static struct i2c_board_info mx53loco_i2c_devices[] = {
>   {
>   I2C_BOARD_INFO("mma8450", 0x1C),
>   },
> + {
> + I2C_BOARD_INFO("da9053-aa", 0x90 >> 1),
> + .platform_data = &da9052_plat,
> + },

You're mixing different ways of numbering I2C devices here.

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

[ACTIVITY] Graphics WG weekly status report - wk02.2012 (20120109-20120113)

2012-01-16 Thread Ilias Biris 
Hello

please find below the summary of the status report from Graphics WG for
wk02.2012. The full report can be found in
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport

The last meeting minutes are in
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2012-01-11

== Achievements ==
- dma-buf : Merged into mainline! - into Linus' tree for 3.3: see here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=a125a3945c950caef001f22055bf201a36568533

- submitted abstract of proposal to talk at ELC - by Sumit Semwal
together with Rob Clark from Multimedia - on 'dma-buf: an introduction'

- glmark2 live-fps implemented and merged upstream

- Unity3D: Resolved build issues with compiz/nux/unity gles2 stack,
built stack for desktop OpenGL in Precise, tracked down compiz display
issues. Nux 2.0 was released with GL|ES support

- Display GPU perf Events through LAVA: Created Linaro Android Origen
image with Mali profiling libs and kernel driver and executed sample job
file on lava-server with the image created and worked successfully. Also
updated Mali kernel driver with profiling options
(git://git.linaro.org/people/chunsangjeong/mali-dev.git)


== Issues ==
- Unity/nux/compiz: Marc and Alexandros are now looking at the work
involved in managing the pieces needed to be merged upstream. The merge
process is underway with Canonical DX and Graphics team is helping to
smooth out any possible issues. However, while the unity and nux
branches are relatively effort free to merge (everything is ifdef'ed
specifically for arm), compiz upstream refuses to let the patches into
the stable branch the desktop team builds from. To get them in anyway
the solution proposed by desktop side is to carry a distro patch in the
package until desktop switches to the other upstream branch - this
carries the obvious risk of the patch getting out of sync and needing
constant fixing and updating.

- Dashboard bugs: #881789 - timeout in image deployment and #904796 -
provide staging/development lava server instances are a risk for our
work with the dashboard

- Need to screen out what kinds of profiling data would be shown through
LAVA without .py files from ARM since ARM MPD has indicated it's not
allowed to open parsers(.py files from ARM) to public, which are used
for making profiling data visible by using Python

- Origen doesn't have h/w(Mali) accelerated Ubuntu and it takes a lot of
time to set up proper LAVA test environment

== Risks ==
Even though there are actions now taken to deal with Unity/Nux/Compiz,
it is possible that those packages are have issues which may require
more time for the release. Marc (IRC: marcoil) and Alexandros (IRC:
alf_) are working on this now


== Next steps ==
- Work is progressing for the release. The group will also work on
#907151: glmark2 SIGSEGV on ICS for Origen.

- Please note that from DX side it has been communicated that Unity 5.2
will be released on week 04 (Estimate) with the GLES branch

- Planning is also continuing for Connect

Best regards,

-- 
Ilias Biris ilias.bi...@linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs

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

Re: [PATCH] mx53_loco: add DA9053 PMIC support

2012-01-16 Thread Russell King - ARM Linux 
On Tue, Jan 17, 2012 at 01:10:53AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> diff --git a/arch/arm/mach-mx5/board-mx53_loco.c 
> b/arch/arm/mach-mx5/board-mx53_loco.c
> index fd8b524..61dd8c9 100644
> --- a/arch/arm/mach-mx5/board-mx53_loco.c
> +++ b/arch/arm/mach-mx5/board-mx53_loco.c
> @@ -23,10 +23,21 @@
>  #include 
>  #include 

You have this ^^^ include, which includes asm/gpio.h, and in turn
mach/gpio.h, but...

>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 

you include mach/gpio.h here?  I don't see why you need mach/irqs.h
either.

That brings into this another question: you're adding 9 new linux/
includes above.  How many of those do you _actually_ need?  Eg, I
don't see you adding anything from linux/err.h to this file, so why
do you need this header?

Please don't add include files unnecessarily.

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

Re: [PATCH] mx53_loco: add DA9053 PMIC support

2012-01-16 Thread Rtp 
"Ying-Chun Liu (PaulLiu)"  writes:

Hi,

> From: "Ying-Chun Liu (PaulLiu)" 
>
> Add DA9052 PMIC support for Freescale QuickStart Loco board.
> The model of PMIC on QuickStart Loco board is "da9053-aa".
>
> Signed-off-by: Ying-Chun Liu (PaulLiu) 
> Cc: Amit Kucheria 
> Cc: Sascha Hauer 
> ---
>  arch/arm/mach-mx5/board-mx53_loco.c   |  128 
> +
>  arch/arm/plat-mxc/include/mach/irqs.h |   10 +++-
>  2 files changed, 137 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-mx5/board-mx53_loco.c 
> b/arch/arm/mach-mx5/board-mx53_loco.c
> index fd8b524..61dd8c9 100644
> --- a/arch/arm/mach-mx5/board-mx53_loco.c
> +++ b/arch/arm/mach-mx5/board-mx53_loco.c
> @@ -23,10 +23,21 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -45,6 +56,32 @@
>  #define LOCO_SD1_CD  IMX_GPIO_NR(3, 13)
>  #define LOCO_ACCEL_ENIMX_GPIO_NR(6, 14)
>  
> +#define DA9052_LDO1_VOLT_UPPER   1800
> +#define DA9052_LDO1_VOLT_LOWER   600
> +#define DA9052_LDO1_VOLT_STEP50
> +#define DA9052_LDO2_VOLT_UPPER   1800
> +#define DA9052_LDO2_VOLT_LOWER   600
> +#define DA9052_LDO2_VOLT_STEP25
> +#define DA9052_LDO34_VOLT_UPPER  3300
> +#define DA9052_LDO34_VOLT_LOWER  1725
> +#define DA9052_LDO34_VOLT_STEP   25
> +#define DA9052_LDO567810_VOLT_UPPER  3600
> +#define DA9052_LDO567810_VOLT_LOWER  1200
> +#define DA9052_LDO567810_VOLT_STEP   50
> +#define DA9052_LDO9_VOLT_STEP50
> +#define DA9052_LDO9_VOLT_LOWER   1250
> +#define DA9052_LDO9_VOLT_UPPER   3650
> +/* Buck Config Validation Macros */
> +#define DA9052_BUCK_CORE_PRO_VOLT_UPPER  2075
> +#define DA9052_BUCK_CORE_PRO_VOLT_LOWER  500
> +#define DA9052_BUCK_CORE_PRO_STEP25
> +#define DA9052_BUCK_MEM_VOLT_UPPER   2500
> +#define DA9052_BUCK_MEM_VOLT_LOWER   925
> +#define DA9052_BUCK_MEM_STEP 25
> +#define DA9052_BUCK_PERI_VOLT_UPPER  2500
> +#define DA9052_BUCK_PERI_VOLT_LOWER  925
> +#define DA9052_BUCK_PERI_STEP25
> +

The _STEP #defines looks unused. What about removing them ?

>  static iomux_v3_cfg_t mx53_loco_pads[] = {
>   /* FEC */
>   MX53_PAD_FEC_MDC__FEC_MDC,
> @@ -227,6 +264,93 @@ static const struct esdhc_platform_data 
> mx53_loco_sd3_data __initconst = {
>   .wp_type = ESDHC_WP_GPIO,
>  };
>  
> +#define DA9052_LDO(max, min, rname, suspend_mv) \
> +{\
> + .constraints = {\
> + .name   = (rname), \
> + .max_uV = (max) * 1000,\
> + .min_uV = (min) * 1000,\
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE\
> + |REGULATOR_CHANGE_STATUS | REGULATOR_CHANGE_MODE,\
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,\
> + .state_mem = { \
> + .uV = suspend_mv * 1000, \
> + .mode = REGULATOR_MODE_NORMAL, \
> + .enabled = (0 == suspend_mv) ? 0 : 1, \
> + .disabled = 0, \
> + }, \
> + },\
> +}
> +
> +/* currently the suspend_mv here takes no effects for DA9053
> +preset-voltage have to be done in the latest stage during
> +suspend*/
> +static struct regulator_init_data da9052_regulators_init[] = {
> + /* BUCKS */
> + DA9052_LDO(DA9052_BUCK_CORE_PRO_VOLT_UPPER,
> +DA9052_BUCK_CORE_PRO_VOLT_LOWER, "DA9052_BUCK_CORE",
> 850),

You're using some #define for min/max. Why not for suspend_mv ? Also, if
#defines are similar enough, I guess you can go further with something
like (untested) :
#define DA9052_LDO(prefix, rname) \
{\
 .constraints = {\
 .name   = (rname), \
 .max_uV = (prefix ## _VOLT_UPPER) * 1000,\
 .min_uV = (prefix ## _VOLT_LOWER) * 1000,\
 .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE\
 |REGULATOR_CHANGE_STATUS | REGULATOR_CHANGE_MODE,\
 .valid_modes_mask = REGULATOR_MODE_NORMAL,\
 .state_mem = { \
 .uV = (prefix ## _VOLT_SUSP) * 1000, \
 .mode = REGULATOR_MODE_NORMAL, \
 .enabled = (0 == (prefix ## _VOLT_SUSP)) ? 0 : 1, \
 .disabled = 0, \
 }, \
 },\
}

and then:

DA9052(DA9052_BUCK_CORE_PRO, "DA9052_BUCK_CORE"),

> + DA9052_LDO(DA9052_BUCK_CORE_PRO_VOLT_UPPER,
> +DA9052_BUCK_CORE_PRO_VOLT_LOWER, "DA9052_BUCK_PRO", 950),
> + DA9052_LDO(DA9052_BUCK_MEM_V

Re: DisableSuspend.apk

2012-01-16 Thread yong qin 
On 17 January 2012 01:38, Alexander Sack  wrote:

> On Mon, Jan 16, 2012 at 6:24 PM, Paul Larson 
> wrote:
> >
> >> The "shell service call power ..." is probably just a runtime setting?
> >> so we have to run it on every boot, no?
> >>
> >> Can we add this to a generic place in lava-android-test (or
> >> dispatcher) to ensure we call this first thing every time when booting
> >> up a unit?
> >>
> > I shoved it temporarily into my dispatcher running locally.  A better
> > solution going forward is to probably allow for some board-defined extra
> > setup steps that run right after boot.  In this case, I also had to add a
>
>
> My understanding is that this is not a board specific feature and we
> have to disable suspend on all boards that run android in LAVA.
>
yes, it is not board specific feature.
I tend to add the process in the disablesuspend.sh into dispatcher like the
modification did in branch
https://code.launchpad.net/~liuyq0307/lava-dispatcher/fix-898530/+merge/84939
and actually it should be added to lava-dispatcher as you said.

but before doing that, I think it's better to make clear why it needs to
restart and needs to be executed twice:(
I will investigate about it.
I don't think the restart is needed by feeling.

Thanks,
Yongqin Liu
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: boot armv7 on qemu-linaro

2012-01-16 Thread Deepti Kalakeri 
On Tue, Jan 17, 2012 at 12:06 AM, Andrei Gherzan  wrote:

> I just cannot make it (qemu) print all serial messages in in default qemu
> windows and not in the terminal.
> If i don't use the argument -serial, i still have to CTRL+3 in the qemu
> window to see serial messages. Any ideas? How can i have all serial
> messages in the default qemu window?
>

Did you try using the -serial stdio option when starting the VM, that
should help to get the serial console messages.

>
> @g
>
>
> __**_
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/**mailman/listinfo/linaro-dev
>



-- 
Thanks and Regards,
Deepti
Infrastructure Team Member, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

gold generate broken sysv-style hash table when --hash-style=both

2012-01-16 Thread Kito Cheng 
Hello,

Recently we are make the dynamic linker support GNU-style hash, but
for the compatible reason we build android with  -Wl,--hash-style=both
instead of -Wl,--hash-style=gnu.

And then we discover this bug in gold, gold generate broken sysv-style
hash table when --hash-style=both, we already file a bug to bugzilla
for bintuils[1].

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=13597

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

Re: Linaro 12.01 release dates and deliveries

2012-01-16 Thread Fathi Boudra 
Hi,

On 16 January 2012 20:15, Anca Emanuel wrote:
> Are you planing something for Precise Pangolin ?
> There are LTS plans ?
> The time left to decisions is very limited.

We plan to have Precise based images, on armhf architecture.
Otherwise, we contribute our components regularly and they're picked up:
linaro-image-tools, linux-linaro, u-boot-linaro, gcc, gdb, qemu, nux,
libjpeg-turbo, etc...

With regard to LTS, we have planned:
- switch to libjpeg-turbo on Ubuntu - done
- merge GL ES 2 support on Unity,/Nux/Compiz - in progress

Cheers,
-- 
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs

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