[ACTIVITY] Android Platform Team 2011-09-26 to 2011-10-02

[Zach Pfeffer]

I'm filing this because Tony's off at training this week.

Key Points for wider discussion
===
 * The 11.09 release went out. Great job everyone!
 * There are new Android build naming conventions: staging- landing-
tracking- 

Team Highlights
===
 * 11.10 planning is done
 * mmtest is in Android now
 * Working on UVC camera support
 * Benchmarking libjpeg-turbo
 * Building igloo without the proprietary components
 * WiFi bring up on Origen

Miscellaneous
===
 * Tony and Frans will be back

Bugs
===
 * Critical
  * 863440 - iMX53 kernel does not boot
  * 865648 - Gerrit changes are not automatically checked before merging

 * High
  * 817315 - eth0 doesn't get a valid MAC address on startup
  * 823313 - Android LEB fails to mount system and user partition
  * 851006 - WiFi doesn't work on Android Origen
  * 856066 - The display doesn't come up on the latest Panda-LEB build on 4460  
  * 856072 - Bionic domain name functions are not thread-safe on pre-3.0 Android
  * 859309 - adb on beagle crashes with Linaro U-Boot 2011.09.1 
  * 860542 - Snowball: Hang when DUT goes to suspend, (USB OTG port is
free - no cables connected)
  * 865258 - adb on panda and staging-panda hangs when device goes to
suspend mode
  * 867527 - All binaries and libraries are mapped rwx on both text and data
  * 868895 - Display failed to come up on 4460 with staging-panda build 15
  * 869514 - Android tracking-panda build 9 crashes during suspend  
  * 869537 - Android tracking-panda build 9 fails to boot on 4460   

Blueprints:
===
 https://launchpad.net/linaro-android/+milestone/11.10

-- 
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

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

[ANN] 11.09 Release Post-mortem and Lessons Learned

[David Zinman]

Greetings,

Here is the post-mortem and lessons learned review for Linaro release 11.09.
Thanks to the teams who have contributed to this.

Release Review: 2011.09

Android

Highlights

Earlier Toolchain release date was very helpful.
Tracking toolchain tip was helpful.
LTs were more responsive to bugs.

Issues

BPs can sometimes be unclear. What to do and and why.
Suggestions:
Make clear where the BP comes from - traceability to
requirement.
Be prudent with Headline and Done criteria.
Make sure BPs are gardened regulaly and WIs are updated.
LTs and WGs are not agreeing with all our plans that involve them.
Suggestions:
PM to add affected groups to each BP and Bug and talk one-on-one
with them
and their PM at the start of the cycle (maybe co-team kickoffs)?

Some tasks could not be completed in the cycle.
Suggestions:
If something doesn't work after a week of effort, lets regroup
on it.
Its hard to see which groups need to work on a BP.
Suggestions:
Assignee must assert that co-workers are subscribed and properly
bugged for progress.
Use the prescribed syntax in WI for describing who does what.
The PM should also be bugging the other teams PM.
iMX53 was difficult.
Suggestions:
We need to gear up with JTAG debuggers.
We need to get the iMX53 LT more engaged.
Sometimes we can't have our way (probably we'd have had less
trouble if we had
started with the LT kernel than with trying to build a
LT/jstultz hybrid).
Get SoC documentation.

Ask LT members for PoCs.
Work the community sites.

Read commit logs for PoCs.
Post on android-building and android-platform.

Blueprints that have unfinished items should not be marked as
'implemented' until a review is done.
This was the case with
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-snowball-a-release.


Work Items


https://blueprints.launchpad.net/linaro-android/+spec/enable-faketsd-on-leb-panda
done - But after release, noted in blueprint
This was a verification issue that fell through the cracks


https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-integrate-glmark2
postponed items broken out into a new blueprint - not a bug since
the items need discussion before the work will be done


https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-snowball-a-release
Many items here have been postponed, yet the BP is marked
implemented.


https://blueprints.launchpad.net/linaro-android/+spec/update-gerrit-and-lava-integration
postponed items - New blueprint created for 11.10:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-enhance-gerrit-and-lava-integration


https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-fix-power-top
Bugs to be logged against

Developer Platform

Highlights

Production development cycle since there was more time for development.
CI for daily builds was started.
Evaluation of derived distro worked well.
Debug symbols for kernel delivered: makes tool building easier.

Issues

Work items should be more descriptive in order to be more
understandable.
Some components from the working groups were not delivered on Thursday
Communicating respin: getting better, but a defined process is needed.
Separate upstreaming activities from monthly cycle.

Work Items

Cross Buildable Nano PPA, Natty based did not make the release.
Rationale: technical development issues
Suggestions:
Better estimation and sizing effort

OMAP 4 SPL USB support at U-Boot did not make the release.
Rationale:
Partial Delivery?
Suggestions:

Star Rating process definition and documentation did not make the
release.
Rationale: This blueprint has been stagnating
Partial Delivery?
Suggestions:

CI with the Linux Linaro packages was split. Unfinished work items have
been re-targeted
to CI with the Linux Linaro packages - Jenkins and LAVA Integration for
release 11.10.
Issues: poorly planned and estimated, was put off track by resource
dependency.

Bug #865547 has been logged against Cross Buildable Nano PPA, Natty
based
This blueprint was planned poorly and badly estimated.

OMAP 4 SPL USB support at U-Boot has been moved to the backlog since it
has not been started and has been stagnating for a while.

The issue of enabling boot loader testing should be brought to TSC
concerning blueprint CI with the U-Boot-Linaro packages
Requires improved LAVA support
A possible solution could be SPL USB booting support rather than
JTAG

Added Bug #865573 to track postponed item from blueprint Change hwpa

Re: Announce: TILT tracking Androidization trees

[Zach Pfeffer]

On 4 October 2011 06:23, Andy Green  wrote:
> Hi -
>
> TI Landing Team has added a couple of new trees to our git repo over the
> weekend
>
> http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
>
> Both of them track Linus HEAD, currently at 3.1-rc8.
>
> First is "linaro-androidization-tracking", this is Linus HEAD plus a set of
> Androidization patches formed from common-3.0 and common-3.1. "common-3.1
> you say?", yes, TI needed a tracking Androidization tree and have made their
> own public one using pieces from common-3.1.
>
> You can find TI's tree that was an ingredient in this here if you're
> interested, it's public
>
> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1
>
> Due to android.git.kernel.org down, AFAIK there's no public access to
> common-3.1 direct otherwise at the moment.
>
> So what's this tree good for?  If you have a kernel for any arch or board
> that is based on Linus HEAD, 3.1-rc8 at the moment, you can merge or rebase
> a copy of it with linaro-androidization-tracking to create an Android
> version of the same kernel.
>
> That's very handy if you did your work to get stuff looking good on Vanilla
> Linus HEAD and don't want to repeat the effort to get the same features
> coming in an Android kernel.
>
> Until now there was no way to casually Androidize a Linus HEAD basis tree
> unless it happened common-3.x was tracking it, which it only does for a
> short period at the end.  It meant that you had to use old release to start
> integrating and adding drivers for Android and backport from HEAD anything
> nice that was coming.  Now with this tree, you can do your work on Linus
> HEAD and fork off working release trees when Linus HEAD goes through a
> release.
>
> This Androidization tree is generic and should be usable for any arch or
> board, there's nothing TI specific in there.  Why then is TI Landing team
> announcing it / TI go to the effort of creating their original one we based
> off?  Nobody else in Linaro wanted to do the work to create and maintain it,
> so we own it at the moment.  We'll have to see how tough it is to keep
> tracking Linus HEAD through the post-release patchstorm but reviewing the
> Androidization patchset I'm cautiously optimistic.
>
> I don't have any connection to Google guys who are basically doing the same
> work on common-3.x, but it would be very cool to be able to cooperate with
> them on bringing this Androidization patchset forward for everyone's
> benefit.
>
>
> The second branch is "tilt-android-tracking".  This is our main tracking
> branch tilt-tracking for Panda enablement we have been running for some
> months combined with "linaro-androidization-tracking" above.
>
> This gets you an effective Panda enabled "3.1 preview" kernel that we have
> had for a while on Vanilla also on Android in an ongoing way.
>
> Current status of it is
>
>  + 1080p SGX acceleration
>  - Suspend borked
>  - WLAN borked
>
> But we only generated it Sunday, we are working on those issues now.
>
> Lastly TILT is also providing tracking versions of the Android autobuilt
> Panda-LEB tarballs that are ready to use.  These are the Autobuilt tarballs
> with the kernel replaced with a tracking one by us.  You can find them
> linked from our git repo in tilt-android-tracking column of the status table
> there.

For those who are interested. We have a tracking-panda build running
with this tree at https://android-build.linaro.org.

I've tested:

https://android-build.linaro.org/builds/~linaro-android/tracking-panda/#build=9

It passes:

Boots 0xBench Busybox YouTube Ethernet ADB GLMark2 Wi-Fi Bluetooth

It fails:

Resumes

For reference, here's the 11.09 test wrap up:
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnpUtxWjZbP9dGFDUk5kNXBoeWZDb3MyUmJ4cnBHTEE&hl=en_US#gid=0

It also only boots on the 4430 not the 4460.

The following bugs are related to this effort so far:

Android tracking-panda build 9 fails to boot on 4460
https://bugs.launchpad.net/u-boot-linaro/+bug/869537

Android tracking-panda build 9 crashes during suspend
https://bugs.launchpad.net/linaro-android/+bug/869514

 __linux__ is not getting defined in android-build
https://bugs.launchpad.net/linaro-android/+bug/868550

-Zach

> -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-kernel mailing list
> linaro-ker...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-kernel
>



-- 
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

___
linaro-dev mailin

Oneiric image directory on snapshots.linaro.org

[Paul Larson]

I know this has come up before, but I'd like to raise it again: Is there any
reason for the lack of consistency between directory layouts for:
http://snapshots.linaro.org/oneiric/
vs.
http://snapshots.linaro.org/11.05-daily/

Would it be possible to rename the oneiric directory to 11.11-daily and
split the hwpacks off into a linaro-hwpacks directory like the 11.04 images?
Also, keeping some kind of -oneiric or -11.11 on the image/hwpack dirs
probably makes sense, but are we planning on changing anything after these
become the default LEB images?

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

Re: Connect 2011 Q4 - SoC Technology Group

[Christian Robottom Reis]

On Mon, Sep 19, 2011 at 05:36:14PM +0100, Lee Jones wrote:
> (Go and get yourself a coffee) :)
> 
> The idea of this new group has gained enough traction such that we have
> decided to run multiple sessions at Connect. Before we can start to plan
> the sessions however, we need to gain a better idea of interested
> parties. So, who and in what capacity do people wish to participate?
> 
> What is the SoC Technology Group (STG)?
> 
> Broadly speaking it's a splinter/pseudo group of technical engineers
> from each applicable Working Group. Although it could easily contain
> members from Platform, Infrastructure and/or Landing Teams. The primary
> role of the STG would be to enable feature sets being produced by the
> Working Groups on each of our supported boards. This team will focus
> heavily on the upstream kernel.

(Having said what I did in the past email about not going forward with
the creation of an STG unit, I'm +1 on us doing a cross-team experiment
at Connect to discuss STG-related issues, produce a work plan and even
kill some work items as part of it. If there is demand and interest,
I promise to chip in and help coordinate.)
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
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: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Ricardo Salveti]

On Thu, Oct 6, 2011 at 1:06 PM, Kurt Taylor  wrote:
>
>
> On 6 October 2011 09:38, Christian Robottom Reis  wrote:
>>
>> On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
>> > There are only 3 left from the list that are bounded enough to consider:
>> > 1) Compressed data api into ALSA - driver specific kernel work and
>> > ALSA/ASoC
>> > plumbing, prob not a good fit for mmwg yet
>>
>> I think this is worth sketching out. Who could actually sit down and
>> write a good description (even if without AC) so I can share the topic.
>>
>> > 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg,
>> > already
>> > proposed as a possible requirement for the new STG team in that mail
>> > thread
>>
>> They don't use ALSA at all? And wouldn't this be better done within the
>> ST-Ericsson LT?
>
> As I understand it, they do not use ALSA. I had originally proposed it be
> done in the ST-E LT, but Lee proposed that it be moved to the STG team (full
> email thread).

Hm, it also sounds more related with the ST-E LT than STG, even now
that the LT is fully back.

>> > 3) End to end audio tests for integration - new proposal by Alexander,
>> > blueprints are already created, investigation underway, but I can write
>> > up a
>> > papyrs page for it if we need to take it in front of the TSC
>>
>> Hmm, this is actually already represented inside a drafted blueprint:
>>
>>        https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#
>
> Excellent, I will delete my papyrs page for it then.

Great, and this is something we'll need to work together (Platform,
MMWG and Validation), but it's ok for the Platform to lead it.

Cheers,
-- 
Ricardo Salveti de Araujo

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Ricardo Salveti]

On Thu, Oct 6, 2011 at 7:28 AM, Mans Rullgard  wrote:
> On 6 October 2011 06:44, Fathi Boudra  wrote:
>> On 6 October 2011 00:43, Mans Rullgard  wrote:
>>> On 5 October 2011 18:35, Christian Robottom Reis  wrote:
 On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
> Debian/Ubuntu P are going to move to libjpeg8 by default making
> current package obsolete in the future.

 Note that when we asked Darrell about this he questioned the performance
 benefits of version 8. Mans probably knows more.
>>>
>>> There is no benefit to v8.  v7 added support for the rarely/never used
>>> arithmetic coding option, left out of earlier versions due to patent
>>> issues.  Since nobody uses this mode, supporting it is irrelevant.
>>> v8 only adds some experimental, non-standard coding options even less
>>> relevant to any real-world uses.  What is relevant is, however, that
>>> v8 is significantly slower than v6 in the default configuration.  I
>>> don't remember if this slowdown was present already in v7.
>>
>> According to Bill Allombert, v8 support more image format
>
> Yes, v8 (and v7) supports the arithmetic coding mode defined in the
> JPEG spec.  Since nobody ever uses this, it is not important.  If you
> mean more non-JPEG formats are supported by the cjpeg/djpeg tools,
> that is of little importance since nobody uses those in "production"
> either.
>
>> and provide a higher image quality.
>
> Maybe.  I have not seen any tests to substantiate this claim.
> When *decoding* v8 actually produces poorer results in some cases
> due to using dct-based upscaling of chroma planes (this is also
> the cause of the slowdown).
>
>> There's probably benefit to v8 if a distribution switch
>> from v6 to v8.
>
> Distributions sometimes do things without good reasons.

And it seems it's not yet clear for distro maintainers which libjpeg
is the best one to use. A few projects already use it by default, like
Firefox, Chromium, Fedora, but it seems we still need to prove the
benefits by showing the numbers across platforms.

Would like to have at least one session for this topic at UDS,
comparing the results and discussing Debian's plans, so we can agree
and try the transition as soon P cycle starts.

Cheers,
-- 
Ricardo Salveti de Araujo

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Mark Brown]

On Thu, Oct 06, 2011 at 11:38:35AM -0300, Christian Robottom Reis wrote:
> On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:

> > There are only 3 left from the list that are bounded enough to consider:
> > 1) Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC
> > plumbing, prob not a good fit for mmwg yet

> I think this is worth sketching out. Who could actually sit down and
> write a good description (even if without AC) so I can share the topic.

Note that there's already an API from Intel which people are relatively
happy with, it mostly just needs some fettling for kernel integration -
after that it's just a realtively straightforward integration question,
more or less.

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Thu, Oct 06, 2011 at 11:06:32AM -0500, Kurt Taylor wrote:
> On 6 October 2011 09:38, Christian Robottom Reis  wrote:
> 
> > On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
> > > There are only 3 left from the list that are bounded enough to consider:
> > > 1) Compressed data api into ALSA - driver specific kernel work and
> > ALSA/ASoC
> > > plumbing, prob not a good fit for mmwg yet
> >
> > I think this is worth sketching out. Who could actually sit down and
> > write a good description (even if without AC) so I can share the topic.
> >
> > > 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
> > > proposed as a possible requirement for the new STG team in that mail
> > thread
> >
> > They don't use ALSA at all? And wouldn't this be better done within the
> > ST-Ericsson LT?
> >
> 
> As I understand it, they do not use ALSA. I had originally proposed it be
> done in the ST-E LT, but Lee proposed that it be moved to the STG team
> (full email thread).

Right, but since STG isn't going forward as a unit of itself, we should
look at this again.
-- 
Christian Robottom Reis   | [+55 16] 3376 0125 | http://launchpad.net/~kiko
Canonical Ltd.| [+55 16] 9112 6430 | http://async.com.br/~kiko

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

Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure

[Turquette, Mike]

On Wed, Oct 5, 2011 at 6:17 PM, Saravana Kannan  wrote:
> On 09/22/2011 03:26 PM, Mike Turquette wrote:
>> +       unsigned long   (*recalc_rate)(struct clk_hw *);
>> +       long            (*round_rate)(struct clk_hw *, unsigned long);
>> +       struct clk *    (*get_parent)(struct clk_hw *);
>> +};
>
> I would like to understand the need for recalc rate if that's something that
> we want to go into the common framework (even if it's optional). I have
> mostly heard only second hand explanations of the need for recalc_rate(), so
> I might not have the full picture. But for all the cases that I can think
> of, recalc_rate seems like a paradox.

Recalc rate has four main uses that I can think of off the top of my head:
1) clk_set_rate is called on clock0, which is a non-leaf clock.  All
clocks "below" clock0 have had their rates changed, yet no one called
clk_set_rate on those child clocks.  We use recalc to walk the
sub-tree of children and recalculate their rates based on the new rate
of their parent, clock0.

2) exact same as #1, but using clk_set_parent instead of clk_set_rate.
 Again, changing the rate of a clock "high up" in the tree will affect
the rates of many child clocks below it.

3) at boot-time/init-time when we don't trust the bootloader and need
to determine the clock rates by parsing registers

4) modeling rates for clocks that we don't really control.  This is
not as common as the above three, but there are times when we're
interested in knowing a clock rate (perhaps for debug purposes), but
it's scaling logic is in firmware or somehow independent of the Linux
clock framework.

> If recalc_rate() is used to make sure the "current rate" of a "clock A" is
> always known even if it's parent "clock B"'s rate is changed, then it also
> means that the rate of "clock A" can change without clk_set_rate(clock A,
> new rate). That in turn means that the clk_get_rate() just gives the
> instantaneous snapshot of the rate. So, any use of clk_get_rate(clock A) for
> anything other than printing/logging the return value is broken code. In

For most clocks, the first three examples I give above will cover all
of the times that a clock's rate will change.  As long as a
recalc/tree-walk is present then clk->rate is not out of sync and thus
printing/reading that value is not broken.

> which case, do we really care for recalc_rate()? We could just return the
> rate that it was set to when clk_set_rate() was called and call it a day or
> return 0 for such clocks to indicate that the clock rate is "unknown".

What's the point of tracking a rate if it can't be trusted?  Also, it
is important to recalc rates whenever changes are made "high up" in
the clock tree once we start to work on rate-change-arbitration
issues, etc.

Regards,
Mike

> The whole concept of trying to recalculate the rate for a clock makes me
> feel uneasy since it promotes misunderstanding the behavior of the clock and
> writing bad code based on that misunderstanding.
>
> I would like to hear to real usecases before I propose some alternatives
> that I have in mind.
>
> Thanks,
> Saravana
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Kurt Taylor]

On 6 October 2011 09:38, Christian Robottom Reis  wrote:

> On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
> > There are only 3 left from the list that are bounded enough to consider:
> > 1) Compressed data api into ALSA - driver specific kernel work and
> ALSA/ASoC
> > plumbing, prob not a good fit for mmwg yet
>
> I think this is worth sketching out. Who could actually sit down and
> write a good description (even if without AC) so I can share the topic.
>
> > 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
> > proposed as a possible requirement for the new STG team in that mail
> thread
>
> They don't use ALSA at all? And wouldn't this be better done within the
> ST-Ericsson LT?
>

As I understand it, they do not use ALSA. I had originally proposed it be
done in the ST-E LT, but Lee proposed that it be moved to the STG team (full
email thread).


>
> > 3) End to end audio tests for integration - new proposal by Alexander,
> > blueprints are already created, investigation underway, but I can write
> up a
> > papyrs page for it if we need to take it in front of the TSC
>
> Hmm, this is actually already represented inside a drafted blueprint:
>
>https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#
>

Excellent, I will delete my papyrs page for it then.


>
> Can you, Alexander and Ricardo figure out whether this should be split
> out?
> --
> Christian Robottom Reis, Engineering VP
> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
> Linaro.org: Open Source Software for ARM SoCs
>



-- 

Kurt Taylor (irc krtaylor)
Linaro Multimedia
Linaro.org * **│ *Open source software for ARM SoCs
Follow *Linaro: *Facebook  |
Twitter|
Blog 
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Mans Rullgard]

On 6 October 2011 16:41, Tom Gall  wrote:
> On Thu, Oct 6, 2011 at 9:30 AM, Christian Robottom Reis  
> wrote:
>> On Thu, Oct 06, 2011 at 08:44:01AM +0300, Fathi Boudra wrote:
>>> On 6 October 2011 00:43, Mans Rullgard  wrote:
>>> > On 5 October 2011 18:35, Christian Robottom Reis  wrote:
>>> >> On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
>>> >>> Debian/Ubuntu P are going to move to libjpeg8 by default making
>>> >>> current package obsolete in the future.
>>> >>
>>> >> Note that when we asked Darrell about this he questioned the performance
>>> >> benefits of version 8. Mans probably knows more.
>>> >
>>> > There is no benefit to v8.  v7 added support for the rarely/never used
>>> > arithmetic coding option, left out of earlier versions due to patent
>>> > issues.  Since nobody uses this mode, supporting it is irrelevant.
>>> > v8 only adds some experimental, non-standard coding options even less
>>> > relevant to any real-world uses.  What is relevant is, however, that
>>> > v8 is significantly slower than v6 in the default configuration.  I
>>> > don't remember if this slowdown was present already in v7.
>>>
>>> According to Bill Allombert, v8 support more image format and provide
>>> a higher image quality.
>>
>> I really question this statement based on what Mans and Darrell have
>> both said (a number of times now). Where is the hard data that shows
>> this is true?
>
> Sounds like there needs to be a discussion with Bill. I would be
> interested how he is measuring image "quality.

IIRC v7 or v8 made some changes to the quantisation, which could in
theory improve quality at a set target size.  I haven't done any
tests myself so I can't say if it works as intended.  Also, what
improves one image might degrade another.  On top of that, image
quality is very subjective and hard to measure.  A change improving
a metric like PSNR can very well decrease subjective visual quality.

-- 
Mans Rullgard / mru

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Tom Gall]

On Thu, Oct 6, 2011 at 9:30 AM, Christian Robottom Reis  wrote:
> On Thu, Oct 06, 2011 at 08:44:01AM +0300, Fathi Boudra wrote:
>> On 6 October 2011 00:43, Mans Rullgard  wrote:
>> > On 5 October 2011 18:35, Christian Robottom Reis  wrote:
>> >> On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
>> >>> Debian/Ubuntu P are going to move to libjpeg8 by default making
>> >>> current package obsolete in the future.
>> >>
>> >> Note that when we asked Darrell about this he questioned the performance
>> >> benefits of version 8. Mans probably knows more.
>> >
>> > There is no benefit to v8.  v7 added support for the rarely/never used
>> > arithmetic coding option, left out of earlier versions due to patent
>> > issues.  Since nobody uses this mode, supporting it is irrelevant.
>> > v8 only adds some experimental, non-standard coding options even less
>> > relevant to any real-world uses.  What is relevant is, however, that
>> > v8 is significantly slower than v6 in the default configuration.  I
>> > don't remember if this slowdown was present already in v7.
>>
>> According to Bill Allombert, v8 support more image format and provide
>> a higher image quality.
>
> I really question this statement based on what Mans and Darrell have
> both said (a number of times now). Where is the hard data that shows
> this is true?

Sounds like there needs to be a discussion with Bill. I would be
interested how he is measuring image "quality.

> --
> Christian Robottom Reis, Engineering VP
> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
> Linaro.org: Open Source Software for ARM SoCs

-- 
Regards,
Tom

"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
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

Updated Libjpeg-turbo benchmarks

[Tom Gall]

All,

For those that care about such things, located in the linaro wiki :
https://wiki.linaro.org/TomGall/LibJpegTurbo is benchmarking
information and numbers from various arm boards and OSes. Much thanks
must be given to Chao Yang for collecting the android numbers. The
page is an evolving beast but I thought worth drawing your attention
to.

OSes include:
Android 2.3.5
Linux (Linaro natty)

Libs measured include:
libjpeg62
libjpeg62 + android extentions
libjpeg-turbo - 1.1.90
libjpeg-turbo - 1.1.90 + android extentions

I've also included some some graphs for those that might want a higher
level comparison.

I will at some point add libjpeg v8 numbers into the mix.

Feedback most welcome.
-- 
Regards,
Tom

"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Thu, Oct 06, 2011 at 05:38:06PM +0300, Fathi Boudra wrote:
> > I think Tom and Ricardo should probably talk to Bill about it; I see
> > this as being a very questionable move. I'd much rather move to seeing
> > libjpeg deprecated into a libjpeg-legacy-8b package for good and -turbo
> > become the actual system version.
> 
> 
> I own the ITP on Debian and already talk to Bill about our plans with ljt.
> 

That's good to know. So now you can convince him to stop this madness ;-)
-- 
Christian Robottom Reis   | [+55 16] 3376 0125 | http://launchpad.net/~kiko
Canonical Ltd.| [+55 16] 9112 6430 | http://async.com.br/~kiko

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Fathi Boudra]

On 6 October 2011 17:34, Christian Robottom Reis  wrote:
> On Thu, Oct 06, 2011 at 09:07:19AM +0300, Fathi Boudra wrote:
>> > What are we using to measure these improvements? What is the -turbo
>> > lib being used for?
>>
>> We use tjbench to measure the improvements. The browsers
>> (firefox/chromium) is a use case mentioned on the roadmap but I didn't
>> have seen any results.  Tom knows more.
>>
>> >> Debian/Ubuntu P are going to move to libjpeg8 by default making
>> >> current package obsolete in the future.
>> >
>> > Note that when we asked Darrell about this he questioned the performance
>> > benefits of version 8. Mans probably knows more. At any rate, -turbo as
>> > an upstream is the only sane decision.
>> >
>> > Who is making the choice from the Ubuntu side -- and is there a bug open
>> > for this?
>>
>> Bill Allombert is libjpeg Debian maintainer. At the moment, Ubuntu is
>> following Debian.  There isn't any bug open as the transition didn't
>> started yet.
>
> I think Tom and Ricardo should probably talk to Bill about it; I see
> this as being a very questionable move. I'd much rather move to seeing
> libjpeg deprecated into a libjpeg-legacy-8b package for good and -turbo
> become the actual system version.


I own the ITP on Debian and already talk to Bill about our plans with ljt.


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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
> There are only 3 left from the list that are bounded enough to consider:
> 1) Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC
> plumbing, prob not a good fit for mmwg yet

I think this is worth sketching out. Who could actually sit down and
write a good description (even if without AC) so I can share the topic.

> 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
> proposed as a possible requirement for the new STG team in that mail thread

They don't use ALSA at all? And wouldn't this be better done within the
ST-Ericsson LT?

> 3) End to end audio tests for integration - new proposal by Alexander,
> blueprints are already created, investigation underway, but I can write up a
> papyrs page for it if we need to take it in front of the TSC

Hmm, this is actually already represented inside a drafted blueprint:

https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#

Can you, Alexander and Ricardo figure out whether this should be split
out?
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
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: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Fathi Boudra]

On 6 October 2011 17:30, Christian Robottom Reis  wrote:
>> According to Bill Allombert, v8 support more image format and provide
>> a higher image quality.
>
> I really question this statement based on what Mans and Darrell have
> both said (a number of times now). Where is the hard data that shows
> this is true?

I'll try to get more information. Though I'm not biased, I want the
benchmark results publicly available as well :)

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

Re: [ACTIVITY] Weekly status Graphics WG - wk39.2011 (20110926-20110930)

[Jesse Barker]

On Thu, Oct 6, 2011 at 7:29 AM, Christian Robottom Reis  wrote:
> On Wed, Oct 05, 2011 at 09:19:18AM -0700, Jesse Barker wrote:
>> Those are only the session blueprints for the scheduler.
>
> Of course, I had forgotten about this silliness. Hopefully this is being
> less expensive now that we have less sessions and the UI is a little bit
> better.

Absolutely.  We only have 4 sessions and could possibly have gotten
away with slightly fewer.

>
> Long-term, I really want to see us have the ability to conveniently
> schedule a session independently or not of having a blueprint for us.

Sure.  This is strictly a function of leveraging the summit scheduler.
 For Cambourne and presumably for SF in February, we won't have to
worry about this.

cheers,
Jesse

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Thu, Oct 06, 2011 at 09:07:19AM +0300, Fathi Boudra wrote:
> > What are we using to measure these improvements? What is the -turbo
> > lib being used for?
> 
> We use tjbench to measure the improvements. The browsers
> (firefox/chromium) is a use case mentioned on the roadmap but I didn't
> have seen any results.  Tom knows more.
> 
> >> Debian/Ubuntu P are going to move to libjpeg8 by default making
> >> current package obsolete in the future.
> >
> > Note that when we asked Darrell about this he questioned the performance
> > benefits of version 8. Mans probably knows more. At any rate, -turbo as
> > an upstream is the only sane decision.
> >
> > Who is making the choice from the Ubuntu side -- and is there a bug open
> > for this?
> 
> Bill Allombert is libjpeg Debian maintainer. At the moment, Ubuntu is
> following Debian.  There isn't any bug open as the transition didn't
> started yet.

I think Tom and Ricardo should probably talk to Bill about it; I see
this as being a very questionable move. I'd much rather move to seeing
libjpeg deprecated into a libjpeg-legacy-8b package for good and -turbo
become the actual system version.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
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: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
> > Is there any optimization (or indeed implementation) work being done
> > here by anyone in the MMWG itself (i.e. excluding Tom)?
> 
> Tom willingly jumped on this work when we didn't have anyone else and has
> done a great job. Mans has been advising as needed. I see no need to take it
> away from Tom just because he isnt officially in the MMWG.

You missed my point -- I was asking if there's any implementation work
being done in the MMWG. Tom isn't going to be writing optimization code,
though he will work on integration code, certainly. My question to the
MMWG is whether there's anything valuable left to do in terms of
optimization.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
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: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Thu, Oct 06, 2011 at 08:44:01AM +0300, Fathi Boudra wrote:
> On 6 October 2011 00:43, Mans Rullgard  wrote:
> > On 5 October 2011 18:35, Christian Robottom Reis  wrote:
> >> On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
> >>> Debian/Ubuntu P are going to move to libjpeg8 by default making
> >>> current package obsolete in the future.
> >>
> >> Note that when we asked Darrell about this he questioned the performance
> >> benefits of version 8. Mans probably knows more.
> >
> > There is no benefit to v8.  v7 added support for the rarely/never used
> > arithmetic coding option, left out of earlier versions due to patent
> > issues.  Since nobody uses this mode, supporting it is irrelevant.
> > v8 only adds some experimental, non-standard coding options even less
> > relevant to any real-world uses.  What is relevant is, however, that
> > v8 is significantly slower than v6 in the default configuration.  I
> > don't remember if this slowdown was present already in v7.
> 
> According to Bill Allombert, v8 support more image format and provide
> a higher image quality.

I really question this statement based on what Mans and Darrell have
both said (a number of times now). Where is the hard data that shows
this is true?
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
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: [ACTIVITY] Weekly status Graphics WG - wk39.2011 (20110926-20110930)

[Christian Robottom Reis]

On Wed, Oct 05, 2011 at 09:19:18AM -0700, Jesse Barker wrote:
> Those are only the session blueprints for the scheduler.

Of course, I had forgotten about this silliness. Hopefully this is being
less expensive now that we have less sessions and the UI is a little bit
better.

Long-term, I really want to see us have the ability to conveniently
schedule a session independently or not of having a blueprint for us.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
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: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Kurt Taylor]

On 5 October 2011 17:45, Kurt Taylor  wrote:

>
>
> On 5 October 2011 11:22, Christian Robottom Reis  wrote:
>
>> On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
>> > - Decision on the multimedia content licenses is still pending - TSC to
>> > provide guidance
>>
>> This was approved today.
>>
>
> Excellent!
>
>
>>
>> > - libjpeg-turbo - oneiric upload, 11.09 natty version released to
>> > ppa:linaro-maintainers/overlay, implemented and submitted upstream
>> > (Blueprint:
>> >
>> https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-libstartup
>> ),
>> > benchmarking ltj with tjbench
>>
>> Is there any optimization (or indeed implementation) work being done
>> here by anyone in the MMWG itself (i.e. excluding Tom)?
>>
>
> Tom willingly jumped on this work when we didn't have anyone else and has
> done a great job. Mans has been advising as needed. I see no need to take it
> away from Tom just because he isnt officially in the MMWG.
>
>
>> > - Studying dma-buf scatter list feature - useless on snowball - snowball
>> > doesn't MMU on hw IP. Could use something like sg_is_last() or
>> > sg_is_chain() to say that there is only one piece of memory in the
>> > scatterlist, but the idea for using scatterlist is that the API should
>> > handle both cases - both devices that need contiguous and those that
>> don't
>>
>> That's correct -- even if Snowball lacks an IOMMU for the hardware
>> codecs, it should be able to use CMA to get access to a contiguous area
>> and the dma-buf API should work for it. Who is working on this?
>>
>
> Jesse and I are discussing who does what, but from the mmwg I would like
> Benjamin to work on this, probably with someone else from his team.
>
>
>>
>> > - Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts
>> 6ch)
>>
>> Nice -- what are the results looking like?
>>
>
>> > Please feel free to ask any questions or let me know if you believe that
>> > something is missing
>>
>> Can you get the requirement laundry list polished up a little bit and
>> sent to the TSC for feedback if any topics there look worth pursuing
>> further into requirements?
>>
>
> There are only 3 left from the list that are bounded enough to consider:
> 1) Compressed data api into ALSA - driver specific kernel work and
> ALSA/ASoC plumbing, prob not a good fit for mmwg yet
> 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
> proposed as a possible requirement for the new STG team in that mail thread
> 3) End to end audio tests for integration - new proposal by Alexander,
> blueprints are already created, investigation underway, but I can write up a
> papyrs page for it if we need to take it in front of the TSC
>

I went ahead and created a papyrs page for this:

https://linaro.papyrs.com/page/4778/MMWG2011-E2E-Audio-Test


>
>
>> --
>> Christian Robottom Reis, Engineering VP
>> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
>> 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
>>
>
>
>
> --
>
> Kurt Taylor (irc krtaylor)
> Linaro Multimedia Team Lead
>
> Linaro.org * **│ *Open source software for ARM
> SoCs
>
> Follow *Linaro: *Facebook  | 
> Twitter|
> Blog 
>
>


-- 

Kurt Taylor (irc krtaylor)
Linaro Multimedia Team Lead
Linaro.org * **│ *Open source software for ARM SoCs
Follow *Linaro: *Facebook  |
Twitter|
Blog 
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

sched: ARM: arch_scale_freq_power

[Vincent Guittot]

I work to link the cpu_power of ARM cores to their frequency by using
arch_scale_freq_power. It's explained in the kernel that cpu_power is
used to distribute load on cpus and a cpu with more cpu_power will
pick up more load. The default value is SCHED_POWER_SCALE and I
increase the value if I want a cpu to have more load than another one.
Is there an advised range for cpu_power value as well as some time
scale constraints for updating the cpu_power value ?
I'm also wondering why this scheduler feature is currently disable by default ?

Regards,
Vincent

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

Re: downloading repo -- can't connect to android.git.kernel.org ?

[Paul Sokolovsky]

Hello,

On Tue, 4 Oct 2011 14:19:39 -0700
Jean-Baptiste Queru  wrote:

> Chicken-and-egg: you can't submit a patch for the AOSP web site saying
> that the AOSP servers are down... because the AOSP servers are down.
> 
> We're working on it.


Now that kernel.org is up, any ETA for when we can expect
android.git.kernel.org be back up too? Or at least, can we be sure it
will be the same hosts structure/setup as before?


Thanks,
Paul

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

Re: [ACTIVITY] Multimedia WG - Weekly Status for wk39.2011 (20110926-20110930)

[Mans Rullgard]

On 6 October 2011 06:44, Fathi Boudra  wrote:
> On 6 October 2011 00:43, Mans Rullgard  wrote:
>> On 5 October 2011 18:35, Christian Robottom Reis  wrote:
>>> On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
 Debian/Ubuntu P are going to move to libjpeg8 by default making
 current package obsolete in the future.
>>>
>>> Note that when we asked Darrell about this he questioned the performance
>>> benefits of version 8. Mans probably knows more.
>>
>> There is no benefit to v8.  v7 added support for the rarely/never used
>> arithmetic coding option, left out of earlier versions due to patent
>> issues.  Since nobody uses this mode, supporting it is irrelevant.
>> v8 only adds some experimental, non-standard coding options even less
>> relevant to any real-world uses.  What is relevant is, however, that
>> v8 is significantly slower than v6 in the default configuration.  I
>> don't remember if this slowdown was present already in v7.
>
> According to Bill Allombert, v8 support more image format

Yes, v8 (and v7) supports the arithmetic coding mode defined in the
JPEG spec.  Since nobody ever uses this, it is not important.  If you
mean more non-JPEG formats are supported by the cjpeg/djpeg tools,
that is of little importance since nobody uses those in "production"
either.

> and provide a higher image quality.

Maybe.  I have not seen any tests to substantiate this claim.
When *decoding* v8 actually produces poorer results in some cases
due to using dct-based upscaling of chroma planes (this is also
the cause of the slowdown).

> There's probably benefit to v8 if a distribution switch
> from v6 to v8.

Distributions sometimes do things without good reasons.

-- 
Mans Rullgard / mru

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