Re: [android-kernel] Linaro and common- tree

[Tim Bird]

On 10/05/2011 08:37 AM, Andy Green wrote:
> Hi -
> 
> Recently at Linaro we've started a new tree 
> linaro-androidization-tracking, which is pretty much "common-3.1"[1] at 
> the moment on 3.1-rc8 basis.
> 
> http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
> 
> We have already been running a kernel tree tracking Linus HEAD since 
> 2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD, 
> so we have some experience with the rough and tumble.
> 
> What we missed having was an "all year round" Androidization tree that 
> we could combine it with to casually create Android versions of the work 
> we were doing on Vanilla Linus HEAD basis.  We used common-3.0 for that 
> for a while late in the kernel release cycle when it was tracking Linus 
> HEAD itself and that was great.  But common-3.0 like the name suggests 
> is really a release tree, and it stops tracking at release, and a new 
> one starts up only late in the next kernel release cycle.
> 
> Actually, it would be a big advantage for many folks to not be doing 
> their Android kernel development on lagging releases, but by tracking 
> Linus HEAD.  They would have access to latest stuff already and they 
> don't have to think about backport or later forwardport stuff to a new 
> release, it's constantly tracking HEAD and being adapted.
> 
> One side-effect of using this tracking methodology is if they want 
> release trees, they can just clone their tracking branch at the time 
> Linus HEAD is at a release point and bam, a hopefully fully working 
> release tree is there.  Another very nice side-effect is they can do the 
> bulk of the work once on a Vanilla Linus HEAD basis, and get and Android 
> version of that work routinely by merging or rebasing in the 
> Androidization tree - instead of doing and validating work twice on 
> separate Vanilla and Android trees.
> 
> So linaro-androidization-tracking is our attempt at that Linus HEAD 
> Androidization tree, moving it on regularly and fixing breakage as it 
> happens throughout the cycle.  It's generic same as common-, it should 
> be usable for any arch or board to Androidize a vanilla kernel that is 
> on the same Linus HEAD basis just by merge or rebase action.
> 
> 
> It seemed this effort might be interesting for the guys that make the 
> common- trees, since if there was a tracking Androidization tree, in 
> fact common- releases for release trees like common-3.1 would just 
> naturally fall out of it when Linus HEAD was at 3.1.  So I'd be very 
> happy to hear any opinions about that.
> 
> Another side-issue is we are also looking at refactoring the 
> Androidization patchset into topic branches, at the moment they're kind 
> of reflecting the history that they were applied on plus or minus some 
> munging around.  So, all the net core patches for example would be 
> together in one series, then all the wireless ones in a series on top of 
> that, etc.  It seems they would be easier to maintain then, opinions on 
> that approach are also welcome.

I've been working on a set of broken-out Android patches, in quilt format,
with exactly the same goal.  It's much easier (at least for me) to maintain the
differences as distinct patches using quilt, rather than as a series (or set
of branches) of git commits.

But possibly I'm just missing how to do this easily with git.
I would very much like to compare approaches, and possibly share
the workload of maintaining such a thing.
 -- Tim

=
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=


___
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

[Saravana Kannan]

On 09/22/2011 03:26 PM, Mike Turquette wrote:

diff --git a/include/linux/clk.h b/include/linux/clk.h
index 1d37f42..d6ae10b 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
+#ifdef CONFIG_GENERIC_CLK
+
+struct clk_hw {
+   struct clk *clk;
+};
+
+/**
+ * struct clk_hw_ops -  Callback operations for hardware clocks; these are to
+ * be provided by the clock implementation, and will be called by drivers
+ * through the clk_* API.
+ *
+ * @prepare:   Prepare the clock for enabling. This must not return until
+ * the clock is fully prepared, and it's safe to call clk_enable.
+ * This callback is intended to allow clock implementations to
+ * do any initialisation that may sleep. Called with
+ * prepare_lock held.
+ *
+ * @unprepare: Release the clock from its prepared state. This will typically
+ * undo any work done in the @prepare callback. Called with
+ * prepare_lock held.
+ *
+ * @enable:Enable the clock atomically. This must not return until the
+ * clock is generating a valid clock signal, usable by consumer
+ * devices. Called with enable_lock held. This function must not
+ * sleep.
+ *
+ * @disable:   Disable the clock atomically. Called with enable_lock held.
+ * This function must not sleep.
+ *
+ * @recalc_rateRecalculate the rate of this clock, by quering hardware
+ * and/or the clock's parent. Called with the global clock mutex
+ * held. Optional, but recommended - if this op is not set,
+ * clk_get_rate will return 0.
+ *
+ * @get_parent Query the parent of this clock; for clocks with multiple
+ * possible parents, query the hardware for the current
+ * parent. Currently only called when the clock is first
+ * registered.
+ *
+ * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
+ * implementations to split any work between atomic (enable) and sleepable
+ * (prepare) contexts.  If a clock requires sleeping code to be turned on, this
+ * should be done in clk_prepare. Switching that will not sleep should be done
+ * in clk_enable.
+ *
+ * Typically, drivers will call clk_prepare when a clock may be needed later
+ * (eg. when a device is opened), and clk_enable when the clock is actually
+ * required (eg. from an interrupt). Note that clk_prepare *must* have been
+ * called before clk_enable.
   */
+struct clk_hw_ops {
+   int (*prepare)(struct clk_hw *);
+   void(*unprepare)(struct clk_hw *);
+   int (*enable)(struct clk_hw *);
+   void(*disable)(struct clk_hw *);
+   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.


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


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)

[Fathi Boudra]

On 5 October 2011 20:35, Christian Robottom Reis  wrote:
> On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
>> libjpeg-turbo is available in Oneiric, using v62 emulation. The performance
>> improvements aren't significant at the moment.
>
> 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.

>> There's definitely some work coming to my mind:
>> - package libjpeg-turbo with v8 compatibility mode enabled
>> - test v8 emulation mode (it seems there's some functions marked as stubs,
>>   need to be confirmed)
>> - run tjbench as part of LAVA tests to get comparisons (plain libjpeg vs ljt)
>> - benchmark on Android platform
>
> Agreed. And you could tack onto this optimizing any other routines that
> are not currently NEON optimized and worth it.
>
>> What's the MM WG plan for ljt? Is there some blueprints in MM WG backlog for
>> the items I mentioned?
>
> Same question here!

___
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 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. There's probably benefit to v8 if a distribution switch
from v6 to v8. Though, performance is more relevant to us (point taken for v6).

>> At any rate, -turbo as an upstream is the only sane decision.
>
> Agreed.
>
> --
> Mans Rullgard / mru

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

Re: Linaro and common- tree

[Andy Green]

On 6 October 2011 06:14, Mathieu Poirier  wrote:

> Good afternoon Andy,
>
> I am currently working on rebasing the STE GLK kernel to the
> androidization branch.  Doing so I have the following questions:
>
> 1. You have made it clear that linaro-androidization-tracking is
> tracking Linus HEAD but is it also tracking kernel/common.git HEAD on
> the android side
>

It's not tracking it in terms of using it as a basis.  We would follow it
and pick new stuff that looked relevant.  But right now, there is no
common-3.1 branch we have access to that we can pick from.


> 2. What will be the rebase strategy ?  Every week ?  And when you do
> rebase, how do you intend to let the followers (like me) know ?


If you think about how you will consume the tree, your desire to use it at a
particular basis will be driven by your own rebase schedule for your vanilla
tree.  So if you have your tracking tree going on -rc5, you are going to
want -rc5 Androidization tree.  If you don't have -rc5 tracking tree, you
don't care if we have -rc5 Androidization tree or not.

What I suggest is for your tracking branch don't rebase against Linus repo
direct but rebase against this

http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/linux-2.6-master

it is the last pull that we did from Linus tree, all of our TILT trees and
the Androidization tree will be using that as their basis.  It's always pure
Linus tree but the basis is exactly what we are using in our other trees.

Sometimes (ie, after -rc0) we will be blocked from pushing the
Androidization tree for a while because it's regressed.  The approach we
will take then is not to push an update until the known regressions are at
least contained or at best gone.  However, your LT tracking tree is likely
going to be in a similar position at that time for the same reasons.

Otherwise we'll be trying to provide it for each -rc at least and make those
persistent using either tags or the branch archive repo we already run.

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

Re: [android-kernel] Linaro and common- tree

[Andy Green]

On 6 October 2011 02:36, Tim Bird  wrote:

> On 10/05/2011 08:37 AM, Andy Green wrote:
>
> > Another side-issue is we are also looking at refactoring the
> > Androidization patchset into topic branches, at the moment they're kind
> > of reflecting the history that they were applied on plus or minus some
> > munging around.  So, all the net core patches for example would be
> > together in one series, then all the wireless ones in a series on top of
> > that, etc.  It seems they would be easier to maintain then, opinions on
> > that approach are also welcome.
>
> I've been working on a set of broken-out Android patches, in quilt format,
> with exactly the same goal.  It's much easier (at least for me) to maintain
> the
> differences as distinct patches using quilt, rather than as a series (or
> set
> of branches) of git commits.
>
> But possibly I'm just missing how to do this easily with git.
> I would very much like to compare approaches, and possibly share
>

Thanks a lot for the reply Tim.  I can describe how I manage this flow in
detail.  Actually, since we would interact through pure git, it's not
necessary to unify the patch management scheme to be able to cooperate.  But
since I spent so much time on exactly this subject I guess we both find it
interesting to describe it.

There are a number of valid ways to come at managing the topic patchsets and
quilt is certainly one of them.  Another approach that would work is to use
git cherry-pick to throw around series of patches from one branch to
another.  The way I have been using though is stgit.

stgit has the advantages of quilt in terms of managing itself the members of
the series.  If you try to do it with git cherry-pick, you have to have
explicit secondary branches floating around to take the series from and keep
tracking of what came from where and what basis it was on, etc, it doesn't
seem it will scale well to dozens of topic and multiple branches.  stgit has
a further characteristic that it stores applied / pushed patches from the
series in absolutely pure git commits, so at any time you can push what you
have to remote git and that's exactly what people will pull with no stgit on
their side.  Stgit is like quilt in terms of patch stack operation, push,
pop, float, "goto", support for rebase, re-ordering, apply conflict
management, import, export, mail and so on.  Stgit series, what is and is
not applied, all state in fact, is bound to a specific git branch.  So when
you checkout a different branch in git, the stgit context for that branch is
made active and nothing is lost about stgit in the previous branch.  In that
way, it's like some extra features integrated on top of git.

Here's a tree I maintain with many topic branches using that flow

http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking

if you go back through the gitweb history, you can see it is formed from a
set of other tracking-topic- branches each rebased on top of each other.  I
have a set of scripts to automate this rebasing.  If I have something to fix
or change at tracking-topic-hdmiaudio for example, I would move to that
branch, change or add patches there, build and confirm the kernel works at
that patchlevel, then use my scripts to rebase the topic branches on top of
it, confirm we didn't break anything, and push the changed branches to
public git.

The main downside is management by stgit is slow.  I have a fast build
machine but stgit just uses one thread and favours correctness over speed,
it's constantly checking to see if any files were changed behind its back in
the tree for example.  Fully rebasing all my trees is a matter of 90
minutes, although that includes a bunch of special rebase trees that are
different from what we're discussing.

The most important characteristic with managing the series at each topic
level is that the topic patch series must strictly be sitting purely on top
of the basis.  git rebase, another candidate for handling the topic series,
depending on the relationship of the two trees, will not always provide that
feature in my experience.


> the workload of maintaining such a thing.
>

That's great we have had the same thoughts looking at the same situation.

What I am expecting is we get an easy ride until Linus kernel 3.1 release,
at which point a backlog of disruptive patches will be applied to Linus HEAD
for 3.2-rc0 and there is some work to do.  We should keep in contact and
figure out how to react to it when the extent of it is known.  If it's
reasonable amount of work I can take care of it, if it's getting a bit much
it will be really great to be able to figure out how to share the load.

Something else to consider about refactor scheme is when an official
common-3.2 is coming say at 3.2-rc7.  Unless we are able to interest common-
maintainers in our scheme, that will not be structured according to our
refactor.  I gave this some thought, the worst that can happen is we have to
discard 

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

[Kurt Taylor]

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


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

Re: Linaro and common- tree

[Mathieu Poirier]

Good afternoon Andy,

I am currently working on rebasing the STE GLK kernel to the
androidization branch.  Doing so I have the following questions:

1. You have made it clear that linaro-androidization-tracking is
tracking Linus HEAD but is it also tracking kernel/common.git HEAD on
the android side ?

2. What will be the rebase strategy ?  Every week ?  And when you do
rebase, how do you intend to let the followers (like me) know ?

Best regards,
Mathieu.

On 11-10-05 09:37 AM, Andy Green wrote:
> Hi -
> 
> Recently at Linaro we've started a new tree
> linaro-androidization-tracking, which is pretty much "common-3.1"[1] at
> the moment on 3.1-rc8 basis.
> 
> http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
> 
> We have already been running a kernel tree tracking Linus HEAD since
> 2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD,
> so we have some experience with the rough and tumble.
> 
> What we missed having was an "all year round" Androidization tree that
> we could combine it with to casually create Android versions of the work
> we were doing on Vanilla Linus HEAD basis.  We used common-3.0 for that
> for a while late in the kernel release cycle when it was tracking Linus
> HEAD itself and that was great.  But common-3.0 like the name suggests
> is really a release tree, and it stops tracking at release, and a new
> one starts up only late in the next kernel release cycle.
> 
> Actually, it would be a big advantage for many folks to not be doing
> their Android kernel development on lagging releases, but by tracking
> Linus HEAD.  They would have access to latest stuff already and they
> don't have to think about backport or later forwardport stuff to a new
> release, it's constantly tracking HEAD and being adapted.
> 
> One side-effect of using this tracking methodology is if they want
> release trees, they can just clone their tracking branch at the time
> Linus HEAD is at a release point and bam, a hopefully fully working
> release tree is there.  Another very nice side-effect is they can do the
> bulk of the work once on a Vanilla Linus HEAD basis, and get and Android
> version of that work routinely by merging or rebasing in the
> Androidization tree - instead of doing and validating work twice on
> separate Vanilla and Android trees.
> 
> So linaro-androidization-tracking is our attempt at that Linus HEAD
> Androidization tree, moving it on regularly and fixing breakage as it
> happens throughout the cycle.  It's generic same as common-, it should
> be usable for any arch or board to Androidize a vanilla kernel that is
> on the same Linus HEAD basis just by merge or rebase action.
> 
> 
> It seemed this effort might be interesting for the guys that make the
> common- trees, since if there was a tracking Androidization tree, in
> fact common- releases for release trees like common-3.1 would just
> naturally fall out of it when Linus HEAD was at 3.1.  So I'd be very
> happy to hear any opinions about that.
> 
> Another side-issue is we are also looking at refactoring the
> Androidization patchset into topic branches, at the moment they're kind
> of reflecting the history that they were applied on plus or minus some
> munging around.  So, all the net core patches for example would be
> together in one series, then all the wireless ones in a series on top of
> that, etc.  It seems they would be easier to maintain then, opinions on
> that approach are also welcome.
> 
> -Andy
> 
> [1] TI have a tree on omapzoom where we got the patches from
> 
> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1
> 
> 


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

android-build prefixes: staging- landing- tracking-

[Zach Pfeffer]

I've had a couple of questions about some new prefixes that are
showing up on https://android-build.linaro.org.

Here's the breakdown:

staging-

LT board support patches + jstultz's common Android tree, this is a
pretty stable point

landing-

LT board support patches on some version of the kernel

tracking-

LT board support patches + Linus HEAD + the Android tracking branch



Only jstultz's common Android tree, the so-called upstreamed only support

These builds go into the LEB ranking system. This system gives the
build a star value depending on what's working (Ethernet, Audio,
etc..). If a build attains a certain star value it is called an LEB.

Feel free to catch me on this thread or on irc or mumble if you've got
any comments or questions.

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

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

[Mans Rullgard]

On 5 October 2011 17:22, Christian Robottom Reis  wrote:
> On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
>> - Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts 6ch)
>
> Nice -- what are the results looking like?

The results I see are not consistent with what Feng Wei reports.  I'm
waiting for him to return from holiday so we can figure out what is
causing the discrepancy.  Despite the differences, both results show
the libav dts decoder is fairly well optimised.  No obvious low-hanging
fruit remains.

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

[Mans Rullgard]

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.

> At any rate, -turbo as an upstream is the only sane decision.

Agreed.

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

[Christian Robottom Reis]

On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
> libjpeg-turbo is available in Oneiric, using v62 emulation. The performance
> improvements aren't significant at the moment.

What are we using to measure these improvements? What is the -turbo
lib being used for?

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

> There's definitely some work coming to my mind:
> - package libjpeg-turbo with v8 compatibility mode enabled
> - test v8 emulation mode (it seems there's some functions marked as stubs,
>   need to be confirmed)
> - run tjbench as part of LAVA tests to get comparisons (plain libjpeg vs ljt)
> - benchmark on Android platform

Agreed. And you could tack onto this optimizing any other routines that
are not currently NEON optimized and worth it.

> What's the MM WG plan for ljt? Is there some blueprints in MM WG backlog for
> the items I mentioned?

Same question here!
-- 
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: Announcing linaro-media-create and live-build integration

[James Westby]

Hi Tom,

That's a cool idea, thanks for doing it.

Thanks,

James

On Tue, 27 Sep 2011 10:23:52 -0500, Tom Gall  wrote:
> Hi All,
> 
> As part of the 11.09 cycle I've completed an extension to live-build3
> that add linaro-media-create. This means with this branch of linaro's
> live-build 3 one is able to build your custom image and directly
> output it to either your SD media or to a file which you an dd
> directly to the media of your choice.
> 
> The extension lives in a bzr branch at
> lp:~tom-gall/live-build/integrate-linaro-media-create
> 
> This code should be considered beta quality. There are bugs. The code
> is however useful. It will be especially useful when combined with the
> cross build support for live-build that was announced as part of the
> 11.07 cycle.
> 
> I've updated my HOWTO which can be found here:
> 
> https://wiki.linaro.org/LiveHelper/Hacking
> 
> If you run into issues please either file a bug in launchpad
> https://bugs.launchpad.net/linaro-ubuntu , post to the list, or grab
> me on irc. (tgall_foo or Dr_Who)
> 
> -- 
> 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

___
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 5 October 2011 19: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.
>
>> - 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)?

here's some comments and a question...

libjpeg-turbo is available in Oneiric, using v62 emulation. The performance
improvements aren't significant at the moment. Debian/Ubuntu P are going to
move to libjpeg8 by default making current package obsolete in the future.
There's definitely some work coming to my mind:
- package libjpeg-turbo with v8 compatibility mode enabled
- test v8 emulation mode (it seems there's some functions marked as stubs,
  need to be confirmed)
- run tjbench as part of LAVA tests to get comparisons (plain libjpeg vs ljt)
- benchmark on Android platform

What's the MM WG plan for ljt? Is there some blueprints in MM WG backlog for
the items I mentioned?

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



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

Re: Linaro and common- tree

[Nicolas Pitre]

On Wed, 5 Oct 2011, Andy Green wrote:

> Actually, it would be a big advantage for many folks to not be doing their
> Android kernel development on lagging releases, but by tracking Linus HEAD.
> They would have access to latest stuff already and they don't have to think
> about backport or later forwardport stuff to a new release, it's constantly
> tracking HEAD and being adapted.

Amen!


Nicolas

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

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

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

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

[Jesse Barker]

Those are only the session blueprints for the scheduler.  Once we've
captured all the info we need (broken each up into individual feature
blueprints that would satisfy the requirements), those will go away
(be marked "implemented").  I don't see how we get around it (well, I
suppose we could keep our planning manual and ad hoc, but I wanted to
make sure folks could use the scheduler to make sure they were able to
attend other important sessions).

cheers,
Jesse

On Wed, Oct 5, 2011 at 9:14 AM, Christian Robottom Reis  wrote:
> On Tue, Oct 04, 2011 at 12:17:11PM +0300, Ilias Biris wrote:
>>   * Benchmarking:
>> https://linaro-public.papyrs.com/public/4143/GWG2011-BENCHMARK-DASHBOARD, 
>> also
>> in Launchpad
>> https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-benchmark-dashboard
>>
>>   * Webkit port using CAIRO-GLES:
>> https://linaro-public.papyrs.com/public/4146/GWG2011-WEBKIT-CAIRO-GLES/#
>> also in Launchpad
>> https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-webkit-cairo-gles
>
> Once we have the show on the road (i.e. the roadmap items estimatded,
> approved and scheduled for Q4) would it make sense to kill the
> blueprints above? I don't like the idea of having duplication (or a
> 1-to-1 mapping) there, and ISTM that you really want to have blueprints
> that are smaller sized than what these are.
> --
> 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
>

___
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 Tue, Oct 04, 2011 at 12:17:11PM +0300, Ilias Biris wrote:
>   * Benchmarking:
> https://linaro-public.papyrs.com/public/4143/GWG2011-BENCHMARK-DASHBOARD, also
> in Launchpad
> https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-benchmark-dashboard
> 
>   * Webkit port using CAIRO-GLES:
> https://linaro-public.papyrs.com/public/4146/GWG2011-WEBKIT-CAIRO-GLES/#
> also in Launchpad
> https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-webkit-cairo-gles

Once we have the show on the road (i.e. the roadmap items estimatded,
approved and scheduled for Q4) would it make sense to kill the
blueprints above? I don't like the idea of having duplication (or a
1-to-1 mapping) there, and ISTM that you really want to have blueprints
that are smaller sized than what these are.
-- 
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

Linaro and common- tree

[Andy Green]

Hi -

Recently at Linaro we've started a new tree linaro-androidization-tracking,
which is pretty much "common-3.1"[1] at the moment on 3.1-rc8 basis.

http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary

We have already been running a kernel tree tracking Linus HEAD since 2.6.39,
which has OMAP4 / Panda enablement stuff on top of Linus HEAD, so we have
some experience with the rough and tumble.

What we missed having was an "all year round" Androidization tree that we
could combine it with to casually create Android versions of the work we
were doing on Vanilla Linus HEAD basis.  We used common-3.0 for that for a
while late in the kernel release cycle when it was tracking Linus HEAD
itself and that was great.  But common-3.0 like the name suggests is really
a release tree, and it stops tracking at release, and a new one starts up
only late in the next kernel release cycle.

Actually, it would be a big advantage for many folks to not be doing their
Android kernel development on lagging releases, but by tracking Linus HEAD.
They would have access to latest stuff already and they don't have to think
about backport or later forwardport stuff to a new release, it's constantly
tracking HEAD and being adapted.

One side-effect of using this tracking methodology is if they want release
trees, they can just clone their tracking branch at the time Linus HEAD is
at a release point and bam, a hopefully fully working release tree is
there.  Another very nice side-effect is they can do the bulk of the work
once on a Vanilla Linus HEAD basis, and get and Android version of that work
routinely by merging or rebasing in the Androidization tree - instead of
doing and validating work twice on separate Vanilla and Android trees.

So linaro-androidization-tracking is our attempt at that Linus HEAD
Androidization tree, moving it on regularly and fixing breakage as it
happens throughout the cycle.  It's generic same as common-, it should be
usable for any arch or board to Androidize a vanilla kernel that is on the
same Linus HEAD basis just by merge or rebase action.


It seemed this effort might be interesting for the guys that make the
common- trees, since if there was a tracking Androidization tree, in fact
common- releases for release trees like common-3.1 would just naturally fall
out of it when Linus HEAD was at 3.1.  So I'd be very happy to hear any
opinions about that.

Another side-issue is we are also looking at refactoring the Androidization
patchset into topic branches, at the moment they're kind of reflecting the
history that they were applied on plus or minus some munging around.  So,
all the net core patches for example would be together in one series, then
all the wireless ones in a series on top of that, etc.  It seems they would
be easier to maintain then, opinions on that approach are also welcome.

-Andy

[1] TI have a tree on omapzoom where we got the patches from

http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1

(Apologies for any duplication, googlegroups needs mail sent from Google
mail)

-- 
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 and common- tree

[Andy Green]

Hi -

Recently at Linaro we've started a new tree 
linaro-androidization-tracking, which is pretty much "common-3.1"[1] at 
the moment on 3.1-rc8 basis.


http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary

We have already been running a kernel tree tracking Linus HEAD since 
2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD, 
so we have some experience with the rough and tumble.


What we missed having was an "all year round" Androidization tree that 
we could combine it with to casually create Android versions of the work 
we were doing on Vanilla Linus HEAD basis.  We used common-3.0 for that 
for a while late in the kernel release cycle when it was tracking Linus 
HEAD itself and that was great.  But common-3.0 like the name suggests 
is really a release tree, and it stops tracking at release, and a new 
one starts up only late in the next kernel release cycle.


Actually, it would be a big advantage for many folks to not be doing 
their Android kernel development on lagging releases, but by tracking 
Linus HEAD.  They would have access to latest stuff already and they 
don't have to think about backport or later forwardport stuff to a new 
release, it's constantly tracking HEAD and being adapted.


One side-effect of using this tracking methodology is if they want 
release trees, they can just clone their tracking branch at the time 
Linus HEAD is at a release point and bam, a hopefully fully working 
release tree is there.  Another very nice side-effect is they can do the 
bulk of the work once on a Vanilla Linus HEAD basis, and get and Android 
version of that work routinely by merging or rebasing in the 
Androidization tree - instead of doing and validating work twice on 
separate Vanilla and Android trees.


So linaro-androidization-tracking is our attempt at that Linus HEAD 
Androidization tree, moving it on regularly and fixing breakage as it 
happens throughout the cycle.  It's generic same as common-, it should 
be usable for any arch or board to Androidize a vanilla kernel that is 
on the same Linus HEAD basis just by merge or rebase action.



It seemed this effort might be interesting for the guys that make the 
common- trees, since if there was a tracking Androidization tree, in 
fact common- releases for release trees like common-3.1 would just 
naturally fall out of it when Linus HEAD was at 3.1.  So I'd be very 
happy to hear any opinions about that.


Another side-issue is we are also looking at refactoring the 
Androidization patchset into topic branches, at the moment they're kind 
of reflecting the history that they were applied on plus or minus some 
munging around.  So, all the net core patches for example would be 
together in one series, then all the wireless ones in a series on top of 
that, etc.  It seems they would be easier to maintain then, opinions on 
that approach are also welcome.


-Andy

[1] TI have a tree on omapzoom where we got the patches from

http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1 



--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


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

Re: Announce: TILT tracking Androidization trees

[Andy Green]

On 10/05/2011 07:38 PM, Asac said:

On Tue, Oct 4, 2011 at 5:33 PM, Andy Green mailto:andy.gr...@linaro.org>> wrote:




One thing that isn't entirely clear from what you describe is
whether we
would do the forward porting for new linus HEAD versions on our
own or
if we would wait until we get a first androidization from either
google
or our members?


You're right it's a good question.  What I have in mind is not to
leave the patchset as the current pile of semi-history patches all
intermingled but impose topic-branch ordering on them.

So for example, I was quite surprised to see so many patches on net
core subsystem, lots on net / wireless subsystem too all through the
series.  It would be interesting to re-order the patches so we had
all the net core stuff in one layer, wireless-related stuff in
another layer all together and so on, same way tilt-tracking is
composed.  We don't have to get OCD about it and do everything, we
can have a topic at the end with stuff contaminated from all
directions and leave it like it is for now.  But I guess most
patches will go into a topic if it is ordered correctly.


Thats an interesting idea. We should not miss the opportunity to discuss
the idea of reordering the patches with AOSP to see if they would be
willing to take/collaborate on such an effort. Can you kick off such
discussion on AOSP mailing lists?


Sure I'll propose it cc-ing linaro-dev and -kernel.

It's two separate issues for these guys if they want to have a fulltime 
tracking kernel to get away from "the -rc7 blues" they must suffer from 
at the moment, and if refactoring the patchset is helpful for them or not.



OK good. It's set up but we seem to have build issues; guess android
team will fix that later today:
https://android-build.linaro.org/builds/~linaro-android/tracking-panda/.


No worries, I appreciate it's on its way.

-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


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

Re: Announce: TILT tracking Androidization trees

[Andy Doan]

I wanted to point out something cool Andy did with his git repo that
other maintainers should think about.

He's created a file, README.html in the root of his repository on
git.linaro.org. This file details his branches and some known issues. It
hooks into gitweb so it makes it easier for people to understand things:




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

Re: Announce: TILT tracking Androidization trees

[Alexander Sack]

On Tue, Oct 4, 2011 at 5:33 PM, Andy Green  wrote:

> On 10/04/2011 10:36 PM, Somebody in the thread at some point said:
>
> Hi -
>
> 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.
>>
>>
>>
>> Sounds like an interesting approach to me. Will you try keep this
>> running as a pilot for one linus head cycle? I think that would give us
>> good initial data to decide how to do all this officially across the
>> organization in future.
>>
>
> Yes that's my plan.  It should be at its worst after 3.1 release in terms
> of conflicts needing fixing for tracking, then at its worst around 3.2-rc7
> or whatever when next common shows up in terms of refreshing against its
> 'upstream' so to speak.  My experience with the TILT patchset and tracking
> suggests we can probably cope, but well we have to see what happens during
> that cycle.
>
>
>  One thing that isn't entirely clear from what you describe is whether we
>> would do the forward porting for new linus HEAD versions on our own or
>> if we would wait until we get a first androidization from either google
>> or our members?
>>
>
> You're right it's a good question.  What I have in mind is not to leave the
> patchset as the current pile of semi-history patches all intermingled but
> impose topic-branch ordering on them.
>
> So for example, I was quite surprised to see so many patches on net core
> subsystem, lots on net / wireless subsystem too all through the series.  It
> would be interesting to re-order the patches so we had all the net core
> stuff in one layer, wireless-related stuff in another layer all together and
> so on, same way tilt-tracking is composed.  We don't have to get OCD about
> it and do everything, we can have a topic at the end with stuff contaminated
> from all directions and leave it like it is for now.  But I guess most
> patches will go into a topic if it is ordered correctly.
>
>
Thats an interesting idea. We should not miss the opportunity to discuss the
idea of reordering the patches with AOSP to see if they would be willing to
take/collaborate on such an effort. Can you kick off such discussion on AOSP
mailing lists?


>> What is holding you back from using the build service atm?
>>
>
> Nothing on our side, in fact I have requested it.
>
> It just needs somebody to cut-and-paste the "panda-LEB" XML and change the
> kernel branch name to 'tilt-android-tracking'.  There was no ETA for it so I
> have rolled our own because I can't get official ones as it stands.  Ongoing
> official Linaro ones will be very welcome.
>
>
OK good. It's set up but we seem to have build issues; guess android team
will fix that later today:
https://android-build.linaro.org/builds/~linaro-android/tracking-panda/.



-- 
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: [PATCH v2 4/7] clk: Add simple gated clock

[Saravana Kannan]

On 09/26/2011 04:30 PM, Rob Herring wrote:

On 09/26/2011 05:37 PM, Turquette, Mike wrote:

On Mon, Sep 26, 2011 at 12:37 PM, Jamie Iles  wrote:

On Mon, Sep 26, 2011 at 02:10:32PM -0500, Rob Herring wrote:

On 09/26/2011 01:40 PM, Jamie Iles wrote:

On Mon, Sep 26, 2011 at 01:33:08PM -0500, Rob Herring wrote:

+static void clk_gate_set_bit(struct clk_hw *clk)
+{
+ struct clk_gate *gate = to_clk_gate(clk);
+ u32 reg;
+
+ reg = __raw_readl(gate->reg);
+ reg |= BIT(gate->bit_idx);
+ __raw_writel(reg, gate->reg);


Don't these read-mod-writes need a spinlock around it?

It's possible to have an enable bits and dividers in the same register.
If you did a set_rate and while doing an enable/disable, there would be
a problem. Also, it may be 2 different clocks in the same register, so
the spinlock needs to be shared and not per clock.


Well the prepare lock will be held here and I believe that would be
sufficient.


No, the enable spinlock is protecting enable/disable. But set_rate is
protected by the prepare mutex. So you clearly don't need locking if you
have a register of only 1 bit enables. If you have a register accessed
by both enable/disable and prepare/unprepare/set_rate, then you need
some protection.


OK fair point, but I would guess that if you had a clock like this then
you probably wouldn't use this simple gated clock would you?  (speaking
from my world where we have quite simple clocks ;-))


I think it is a safe assumption that if a register controls both
enable/disable and some programmable divider then,

1) those controls are probably for the same clock
2) that clock won't be using the cookie-cutter gated-clock
implementation anyways


By definition of simple gated clock, the other bits have to be for
another clock. The restriction is that all the other bits can only be
clock gate bits.



Rob, do you feel these assumptions are OK and locking can remain the
same in this patch?


Perhaps it is rare enough that it is not worth it use generic code in
this case. If so, the documentation should be clear about this
constraint. It is not something anyone will have hit before because
everyone used a single global lock. Now with the api being split between
2 locks, this adds a new complexity.


I kinda agree with Rob on this. There are very few, if any, such simple 
clocks on MSM chips. It's very easy to a SoC clock developer to 
accidentally use these simple clocks without realizing the point that 
Rob brings up.



I think the simple gated clock code should be usable for any clock
controlled by a single bit in a 32-bit register independent of other
things in that register.


To take care of the scenario Rob bring up, the prepare/unprepare and 
enable/disable code will have to grab a per-tree register-lock before 
accessing any registers. The prepare/unprepare code should obviously be 
written to hold this register-lock for as small of a duration as 
possible. For example, if the prepare code is doing voltage increase, 
the register-lock should be grabber _after_ the voltage is increased. At 
least, this is approximately how the MSM clock code can be mapped onto 
this generic framework.


I think we should just go ahead and implement the per-tree register lock 
so that the generic clock implementations are more useful. The lock will 
really be held only for a very short time and hence shouldn't matter 
that there is a single lock for all the clocks in a tree.


Thomas,

Did you get a chance to send out your patches with support for per-tree 
locking? I would really like to see that as part of the first patch 
series that gets pulled in.


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