Re: Call for topics for the 12.06 linux-linaro* trees

[Ryan Harkin]

On 8 June 2012 13:25, Andrey Konovalov  wrote:

> Greetings,
>
> There will be three linux-linaro trees this month. Also some LTs have
> moved to 3.5, while the others will stay on older kernels.
>
> In addition to linux-linaro-core-tracking and linux-linaro ones
> (described under https://wiki.linaro.org/**Platform/DevPlatform/**
> LinuxLinaroKernelTreeProcess),
> linux-linaro-tracking tree will be created as a merge of the tracking trees
> of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs. Probably
> more LT tracking trees would be added, but I am not sure due to the
> different bases the others use. Each LT's tracking tree act as a topic
> here, so the call for topics doesn't apply to  this tree.
>
> linux-linaro-core-tracking tree is moving to 3.5 (but not published at
> git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been
> created. This is a copy of the most recent v3.4 based
> linux-linaro-core-tracking tree.
> *New generic (not board specific) topics and updates to the existing
> topics are welcomed for the 3.5 based linux-linaro-core-tracking tree*
> The requirements for a topic can be found here:
> https://wiki.linaro.org/**Platform/DevPlatform/**
> LinuxLinaroKernelTreeProcess#**Adding_a_topic_to_linux-**
> linaro_kernel_and_maintaining_**it
> The current topics are:
> * arm_soc/testing/multiplatform
> * svenkatr/ufs-for-linux-linaro
> * svenkatr/emmc-for-linux-linaro
> * amitdanielk/thermal_exynos4_**imx6_work
> * android_jstultz/linaro-**android-3.5-jstultz-rebase
> * lt_arm/tracking-armlt-gator
> * umm_sumitsemwal/umm-3.4-wip (needs updating to 3.5?)
> * lt_samsung/llt/umm_fixes (should be better included into the topic
> above?)
> * android_jstultz/linaro-**configs-3.5
> * ll_quantal/linaro-ubuntu-**sauce-packaging-topic  (needs updating to
> 3.5?)
>
> linux-linaro tree will also move to 3.5. At the time of the 12.06 kernel
> release, it should be at v3.5-rc2 or v3.5-rc3.
> For those who are on v3.4, there is linux-linaro_3.4-2012.05-1 branch.
> *The landing teams*:
> - please let me know if you want your topics to be carried over to 3.5
> based linux-linaro tree.
>

The ARM LT tree has been updated to 3.5-rc1 already, so you should be able
to update our topics.  I'm sure they will work/merge easily with the TI and
Samsung trees...



> - as usual, LT's topics updates and new topics (if any) are welcomed for
> both 3.5 based, and probably 3.4 based linux-linaro trees. If it turns out
> that the 3.4 based linux-linaro tree needs to be updated, I'll create a new
> branch from linux-linaro_3.4-2012.05-1.
>
> Sorry in advance for all the confusion which this post could introduce :)
> Please don't hesitate to comment on it, or to make corrections. Sometimes
> this could be just me not being clear enough.
>
> Thanks,
> Andrey
>
> __**_
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/**mailman/listinfo/linaro-dev
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] perf sched replay: fix event lookup

[Namhyung Kim]

Hi,

On Sat,  9 Jun 2012 13:05:58 +0400, Dmitry Antipov wrote:
> Use new function trace_find_event_by_name to lookup events before
> looking through /sys files. This helps 'perf sched replay' to map
> event names to IDs correctly when processing perf.data recorded
> on another machine.
>

Basically the same approach with the previous reply, please put this
into trace_event__id(). And minor nits below..


> Signed-off-by: Dmitry Antipov 
> ---
>  tools/perf/util/evlist.c|   18 --
>  tools/perf/util/trace-event-parse.c |4 
>  tools/perf/util/trace-event.h   |1 +
>  3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 4ac5f5a..7ebb9c5 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -17,6 +17,7 @@
>  #include 
>  
>  #include "parse-events.h"
> +#include "trace-event.h"
>  
>  #include 
>  
> @@ -231,12 +232,25 @@ int perf_evlist__set_tracepoints_handlers(struct 
> perf_evlist *evlist,
> const struct perf_evsel_str_handler 
> *assocs,
> size_t nr_assocs)
>  {
> + struct event_format *event;
>   struct perf_evsel *evsel;
> + char *p, *sys, *name;
>   int err;
> - size_t i;
> + size_t i, off;
>  
>   for (i = 0; i < nr_assocs; i++) {
> - err = trace_event__id(assocs[i].name);
> + err = -ENOENT;
> + p = strchr(assocs[i].name, ':');
> + if (!p)
> + goto out;

Is this really needed? It looks original trace_event__id() require
this. But because we'll use pevent_find_event_by_name, the 'sys' part
can be omitted from now on?


> + off = p - assocs[i].name;
> + sys = malloc(off + 1);

The malloc() can fail, please check the return value.

Thanks,
Namhyung


> + memcpy(sys, assocs[i].name, off);
> + sys[off] = '\0';
> + name = p + 1;
> + event = trace_find_event_by_name(sys, name);
> + err = event ? event->id : trace_event__id(assocs[i].name);
> + free(sys);
>   if (err < 0)
>   goto out;
>  
> diff --git a/tools/perf/util/trace-event-parse.c 
> b/tools/perf/util/trace-event-parse.c
> index df2fddb..44cbb40 100644
> --- a/tools/perf/util/trace-event-parse.c
> +++ b/tools/perf/util/trace-event-parse.c
> @@ -176,6 +176,10 @@ struct event_format *trace_find_event(int type)
>   return pevent_find_event(pevent, type);
>  }
>  
> +struct event_format *trace_find_event_by_name(const char *sys, const char 
> *name)
> +{
> + return pevent_find_event_by_name(pevent, sys, name);
> +}
>  
>  void print_trace_event(int cpu, void *data, int size)
>  {
> diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
> index 639852a..66f83a0 100644
> --- a/tools/perf/util/trace-event.h
> +++ b/tools/perf/util/trace-event.h
> @@ -40,6 +40,7 @@ int parse_event_file(char *buf, unsigned long size, char 
> *sys);
>  
>  struct pevent_record *trace_peek_data(int cpu);
>  struct event_format *trace_find_event(int type);
> +struct event_format *trace_find_event_by_name(const char *sys, const char 
> *name);
>  
>  unsigned long long
>  raw_field_value(struct event_format *event, const char *name, void *data);

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

Re: Call for topics for the 12.06 linux-linaro* trees

[Andrey Konovalov]

On 06/11/2012 07:33 AM, Tushar Behera wrote:

On 06/08/2012 07:30 PM, Andy Green wrote:

On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included:

Greetings,

There will be three linux-linaro trees this month. Also some LTs have
moved to 3.5, while the others will stay on older kernels.

In addition to linux-linaro-core-tracking and linux-linaro ones
(described under
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess),

linux-linaro-tracking tree will be created as a merge of the tracking
trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs.


I would be publishing 3.4 based Samsung Kernel today. So, you can use
that in linux-linaro-tracking.


OK. Thanks, Tushar!


For reference the TI + Samsung trees I did during Connect can be found
here:

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/unify-samsung-ti

This builds and works for OMAP at least.


Thanks, Andy!
Have had a quick look at it. I could probably ask you about some more 
details of some your fixes with no or too short (for me) comments. But 
this is rather my ignorance/curiosity then an issue.


Thanks,
Andrey

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

Git repo for kernel config fragments created

[Jon Medhurst (Tixy)]

I have created an git repo for the kernel config fragments we produced a
while ago, this is at git://git.linaro.org/kernel/configs.git

The config-core-tracking branch in this repo is intended to be added to
the linux-linaro-core-tracking branch and so be available in all Linaro
kernels. This currently provides three config fragment files:

linaro/configs/linaro-base.conf
   Config options common to all Linaro kernels

linaro/configs/ubuntu.conf
   Config options for all Ubuntu kernels

linaro/configs/android.conf
   Config options for all Android kernels

In addition to these, a board specific config fragment is required to
produce a final kernel config. This may be made available by a Landing
Team's kernel tree (I have done this for vexpress [1]) or; for
experimental purposes, or to support legacy platforms, I have a separate
config-boards-tracking branch of the new configs.git. (Currently this
contains the Origen and iMX5 fragments produced a while ago.)

To create an Ubuntu kernel config from these fragments for a device
called $BOARD, you need to run a command like:

  ARCH=arm scripts/kconfig/merge_config.sh \
linaro/configs/linaro-base.conf linaro/configs/ubuntu.conf \
linaro/configs/$BOARD.conf

For Android, s/ubuntu/android/ in the above.

At some point soonish, I hope to come up with a mechanism whereby
Android builds have the option to dynamically generate their kernel
config as above. John Rigby is planning on adding a similar option to
the Ubuntu packaging jobs.

Hopefully this work will enable:

- easier management of system wide config settings required by working
group output or Linaro policy
- place board specific configuration in the hands of the people
maintaining that boards kernel
- more consistent kernel builds, so teams can test in the same
environment as Linaro's final releases

I intend to maintain git://git.linaro.org/kernel/configs.git and will
keep separate non 'tracking' branches for older kernel versions (I
currently have branches for 3.4).

-- 
Tixy

[1] 
http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=shortlog;h=refs/heads/tracking-armlt-config


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

Re: [PATCH] perf sched replay: fix event lookup

[Arnaldo Carvalho de Melo]

Em Mon, Jun 11, 2012 at 02:46:02PM +0900, Namhyung Kim escreveu:
> On Sat,  9 Jun 2012 13:05:58 +0400, Dmitry Antipov wrote:
> > Use new function trace_find_event_by_name to lookup events before
> > looking through /sys files. This helps 'perf sched replay' to map
> > event names to IDs correctly when processing perf.data recorded
> > on another machine.
> 
> Basically the same approach with the previous reply, please put this
> into trace_event__id(). And minor nits below..

Well, trace_event__id() is private to evlist and evlist so far is a
local thing, i.e. it doesn't know anything about perf.data files.

So I think we should have a per perf.data (perf_session) method that
knows that it shouldn't look _at all_ to /sys, but just at what came in
the perf.data file.

As well when we want something that is on the running machine, even if
we're dealing somehow with a perf.data file, we shouldn't use what is in
it.

- Arnaldo

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

Re: [PATCH] perf report: fix event name reporting

[Arnaldo Carvalho de Melo]

Em Fri, Jun 08, 2012 at 04:23:27PM +0400, Dmitry Antipov escreveu:
> Use trace_find_event to find event name before looking through
> /sys files. This helps 'perf report' to show real event names
> instead of 'unknown:unknown' when processing perf.data recorded
> on another machine.

We have to somehow tell perf_evlist__tty_browse_hists that it should try
to figure out the name of the event by looking at _either_ /sys (local
events) or what came in the perf.data file.

That is because 'perf top' and 'perf report' uses
perf_evlist__tty_browse_hists. One is for local events (top) and the
other for perf.data files, that may or not be for local (in the sense of
running the same kernel for record + report) or for "remote" (running on
the same machine but with a different kernel at record than the one used
at report) or from a different machine altogether, perhaps even
different arch.

So I think that what needs to be done is to cache the right event name
before getting to the hists browser. I.e. when setting up the events
locally or when reading the events from the perf.data header, this way
perf_evsel__name() can be used everywhere and will just return
event->name, BUG_ON if event->name is NULL, i.e. wasn't resolved
already.

- Arnaldo
 
> Signed-off-by: Dmitry Antipov 
> ---
>  tools/perf/builtin-report.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 8c767c6..a6fd309 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -24,6 +24,7 @@
>  #include "util/evlist.h"
>  #include "util/evsel.h"
>  #include "util/header.h"
> +#include "util/trace-event.h"
>  #include "util/session.h"
>  #include "util/tool.h"
>  
> @@ -314,7 +315,8 @@ static int perf_evlist__tty_browse_hists(struct 
> perf_evlist *evlist,
>  
>   list_for_each_entry(pos, &evlist->entries, node) {
>   struct hists *hists = &pos->hists;
> - const char *evname = event_name(pos);
> + struct event_format *event = trace_find_event(pos->attr.config);
> + const char *evname = event ? event->name : event_name(pos);
>  
>   hists__fprintf_nr_sample_events(hists, evname, stdout);
>   hists__fprintf(hists, NULL, false, true, 0, 0, stdout);
> -- 
> 1.7.7.6

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

Re: Git repo for kernel config fragments created

[Christian Robottom Reis]

On Mon, Jun 11, 2012 at 02:14:05PM +0100, Jon Medhurst (Tixy) wrote:
> I have created an git repo for the kernel config fragments we produced a
> while ago, this is at git://git.linaro.org/kernel/configs.git

This is very cool -- however, I think something's busted in the
Description:

http://git.linaro.org/gitweb?p=kernel/configs.git;a=summary

This page contains the following errors:

error on line 83 at column 7: Opening and ending tag mismatch: p
line 0 and div

Config frags are the future -- great to see them being actively used!
-- 
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: Git repo for kernel config fragments created

[Jon Medhurst (Tixy)]

On Mon, 2012-06-11 at 14:02 -0300, Christian Robottom Reis wrote:
> On Mon, Jun 11, 2012 at 02:14:05PM +0100, Jon Medhurst (Tixy) wrote:
> > I have created an git repo for the kernel config fragments we produced a
> > while ago, this is at git://git.linaro.org/kernel/configs.git
> 
> This is very cool -- however, I think something's busted in the
> Description:
> 
> http://git.linaro.org/gitweb?p=kernel/configs.git;a=summary
> 
> This page contains the following errors:
> 
> error on line 83 at column 7: Opening and ending tag mismatch: p
> line 0 and div

I fixed that, I never get used to this newfangled XHTML :-)

-- 
Tixy


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

linux-linaro-core-tracking updated to 3.5

[Andrey Konovalov]

Greetings,

The linux-linaro-core-tracking branch has finally been moved to 3.5.
Not all the topics listed in the previous message are here yet (the umm 
and the ubuntu-sauce are not there yet); the current list is (see also 
the attached pinned manifest):

* svenkatr/ufs-for-linux-linaro
* svenkatr/emmc-for-linux-linaro
* amitdanielk/thermal_exynos4_imx6_work
* android_jstultz/linaro-android-3.5-jstultz-rebase
* lt_arm/tracking-armlt-gator
* arm_soc/testing/multiplatform
* configs/config-core-tracking

Andy Green pointed out that

this patch

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html

is important for OMAP... thanks to Tushar for digging up the context of it for 
us.  We're carrying a replica of it in our tracking atm but since what was

tracking-thermal_exynos4_imx6-3.4-2012.05

had just one of the pair of patches in older llct, it should be improved to 
have both, if it doesn't already with this update.
The current answer is that thermal_exynos4_imx6_work doesn't have the 
2nd patch (and this topic has not been updated for 8 weeks). And the 
reason for having just the 1st patch is probably that the 1st patch is 
the ARM generic one, while the 2nd one is for OMAP. And AFAIK the topic 
doesn't support OMAPs yet. The 2nd patch worth including into llct, but 
I haven't decided how to do that yet - need to sync with the PMWG.


The thermal stuff is most probably doesn't quite work for imx6 in this 
version for the following reason:

After a new clk-imx6q.c driver had been introduced (commit 
2acd1b6f889c04f8f303a5a11993f60fda6a7885),
the previous clock-imx6q.c driver was deleted (commit 
c818f97bc3266f0fbf619f2348d951272f8ac335).
As a result, commit 3ecb31851f236df5099e21696325776b2e800fe4 "arm/imx6q: register 
arm_clk as cpu to clkdev"
from the thermal_exynos4_imx6_work topic can not be applied as is to the new 
driver.

So I had to drop the "arm/imx6q: register arm_clk as cpu to clkdev" commit.


Thanks,
Andrey

On 06/08/2012 04:25 PM, Andrey Konovalov wrote:

The current topics are:
* arm_soc/testing/multiplatform
* svenkatr/ufs-for-linux-linaro
* svenkatr/emmc-for-linux-linaro
* amitdanielk/thermal_exynos4_imx6_work
* android_jstultz/linaro-android-3.5-jstultz-rebase
* lt_arm/tracking-armlt-gator
* umm_sumitsemwal/umm-3.4-wip (needs updating to 3.5?)
* lt_samsung/llt/umm_fixes (should be better included into the topic
above?)
* android_jstultz/linaro-configs-3.5
* ll_quantal/linaro-ubuntu-sauce-packaging-topic (needs updating to 3.5?)
# Autogenerated PINNED manifest for linux-linaro-core-tracking
# Date: 12-Jun11-20:38:52
#
# topics
#
topic mainline upstream/master PIN 4e3c8a1b1c63482403e9d5e3148dee1a711e4b91 
merge
topic ufs svenkatr/ufs-for-linux-linaro PIN 
f66f320eab49d915d83ceede5c70b8187d0ce698 merge
topic emmc svenkatr/emmc-for-linux-linaro PIN 
75eded2545e162cbfba612b195cdd0b7e67beabb merge
topic thermal_exynos4_imx6 amitdanielk/thermal_exynos4_imx6_work PIN 
b286f1ce2b4a48ae25ee14b30c9da4da378fc5ad merge
topic linaro-android-3.5 android_jstultz/linaro-android-3.5-jstultz-rebase PIN 
0cecb1d499a005bffb0739e841a35625dc09790d merge
topic gator lt_arm/tracking-armlt-gator PIN 
4979ee6468edfc897c36ca59544b4ab15e58aa88 merge
topic multiplatform arm_soc/testing/multiplatform PIN 
d83c8bf090be900dd7a67f86c1eb13a4e111f2a1 merge
topic configs configs/config-core-tracking PIN 
743c9750b82c06f81df671849fbae6596881bc07 merge
#
# remotes
#
remote upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
remote configs git://git.linaro.org/kernel/configs.git
remote amitdanielk git://git.linaro.org/people/amitdanielk/linux.git
remote android_jstultz git://git.linaro.org/people/jstultz/android.git
remote ll_quantal git://git.linaro.org/ubuntu/linux-linaro-quantal.git
remote lt_arm git://git.linaro.org/landing-teams/working/arm/kernel.git
remote lt_samsung git://git.linaro.org/landing-teams/working/samsung/kernel.git
remote svenkatr git://github.com/svenkatr/linux.git
remote umm_sumitsemwal git://git.linaro.org/people/sumitsemwal/linux-3.x.git
remote arm_soc git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro recommended (tm) brand of SD card?

[David Brown]

On Fri, Jun 08, 2012 at 02:06:55AM +, Arnd Bergmann wrote:
> On Thursday 07 June 2012, David Brown wrote:
> > On Wed, Jun 06, 2012 at 07:11:37AM +, Arnd Bergmann wrote:
> > 
> > > If you don't need the data on your card, could you run these
> > > commands on yours:
> > > 
> > > for i in 2 3 30 31 ; do 
> > >   sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] 
> > > \
> > >   /dev/mmcblk0  --offset=$[24*1024*1024]
> > > done
> > 
> > Did you mean to use $i somewhere in that loop? 
> 
> oops, yes it should be "--open-au-nr=$i"

Results with the --open-au-nr at 2, 3, 30, and 31, for both the 512K
erase size and the 4MB erase size:

% time for i in 2 3 30 31 ; do echo '==' $i '=='; sudo ./flashbench --open-au 
--open-au-nr=$i --erasesize=$[512 * 1024] /dev/sdd --offset=$[24*1024*1024]; 
done
== 2 ==
512KiB  798K/s  
256KiB  536K/s  
128KiB  548K/s  
64KiB   545K/s  
32KiB   525K/s  
16KiB   1.27M/s 
== 3 ==
512KiB  1.86M/s 
256KiB  490K/s  
128KiB  273K/s  
64KiB   636K/s  
32KiB   592K/s  
16KiB   1.01M/s 
== 30 ==
512KiB  868K/s  
256KiB  405K/s  
128KiB  203K/s  
64KiB   104K/s  
32KiB   146K/s  
16KiB   816K/s  
== 31 ==
^C

4MB variant:
== 2 ==
4MiB4.05M/s 
2MiB6.13M/s 
1MiB6.19M/s 
512KiB  6.14M/s 
256KiB  5.27M/s 
128KiB  4.59M/s 
64KiB   6M/s
32KiB   5.04M/s 
16KiB   490K/s  
== 3 ==
4MiB5.06M/s 
2MiB3.93M/s 
1MiB1.72M/s 
512KiB  1.51M/s 
256KiB  449K/s  
128KiB  206K/s  
64KiB   1.2M/s  
32KiB   1.23M/s 
16KiB   1.66M/s 
== 30 ==
4MiB6.66M/s 
2MiB3.29M/s 
1MiB1.64M/s 
512KiB  821K/s  
256KiB  408K/s  
128KiB  204K/s  
64KiB   104K/s  
32KiB   149K/s  
16KiB   660K/s  
== 31 ==
4MiB6.3M/s  
2MiB3.27M/s 
1MiB1.64M/s 
512KiB  823K/s  
256KiB  409K/s  
^C

-- 
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: linux-linaro-core-tracking updated to 3.5

[Andy Green]

On 06/12/12 02:44, the mail apparently from Andrey Konovalov included:


Andy Green pointed out that

this patch

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html

is important for OMAP... thanks to Tushar for digging up the context
of it for us.  We're carrying a replica of it in our tracking atm but
since what was

tracking-thermal_exynos4_imx6-3.4-2012.05

had just one of the pair of patches in older llct, it should be
improved to have both, if it doesn't already with this update.

The current answer is that thermal_exynos4_imx6_work doesn't have the
2nd patch (and this topic has not been updated for 8 weeks). And the
reason for having just the 1st patch is probably that the 1st patch is
the ARM generic one, while the 2nd one is for OMAP. And AFAIK the topic
doesn't support OMAPs yet. The 2nd patch worth including into llct, but
I haven't decided how to do that yet - need to sync with the PMWG.


OK... we are carrying a rediscovered version of the second patch from 
Dave Long for now.  However although one is for OMAP, the patches belong 
together because they change the handling of something and then correct 
OMAP to comply with the New 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: Git repo for kernel config fragments created

[John Stultz]

On 06/11/2012 06:14 AM, Jon Medhurst (Tixy) wrote:

I have created an git repo for the kernel config fragments we produced a
while ago, this is at git://git.linaro.org/kernel/configs.git

The config-core-tracking branch in this repo is intended to be added to
the linux-linaro-core-tracking branch and so be available in all Linaro
kernels. This currently provides three config fragment files:


Thanks so much Tixy, for stepping up and getting this going!
-john


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

Re: Git repo for kernel config fragments created

[Andy Green]

On 06/11/12 21:14, the mail apparently from Jon Medhurst (Tixy) included:

I have created an git repo for the kernel config fragments we produced a
while ago, this is at git://git.linaro.org/kernel/configs.git

The config-core-tracking branch in this repo is intended to be added to
the linux-linaro-core-tracking branch and so be available in all Linaro
kernels. This currently provides three config fragment files:

linaro/configs/linaro-base.conf
Config options common to all Linaro kernels

linaro/configs/ubuntu.conf
Config options for all Ubuntu kernels

linaro/configs/android.conf
Config options for all Android kernels


Just a thought... while meddling with the OOT Androidization patches, it 
seemed to me we missed a trick just killing all the default y on the 
Android-related stuff.  If we additionally use select xxx on 
CONFIG_ANDROID for the config options we removed default for, we can 
express most or all of the config relationships there, reducing this to 
CONFIG_ANDROID=y


-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: android-3.4 ... / Audit of OOT android code

[John Stultz]

On 06/10/2012 02:53 AM, Andy Green wrote:

On 05/24/2012 11:06 PM, the mail apparently from Andy Green included:


Putting it another way if Linaro isn't going to take even a modest
amount of care about the OOT Android content making problems in vanilla
case, we probably aren't ready to add this lot to a vanilla basis.
Irritating as that is for me as much as anyone.


Here is an audit I did myself today of OOT Android content needed to 
understand what we're adding to Linaro kernels for vanilla case.  It's 
looking at the changes from POV of someone who does not want the 
additional Android content to build into their kernel or affect 
actions when deconfigured.


Things are "harmless" if they don't unconditionally change the source, 
the CONFIG_ they depend on is not "default y", or by looking at the 
code I determined that it's reasonable or even beneficial.


These are the suspicious things I found from the diff between 
linaro-android-3.4 (from 
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-android-3.4 
at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4.  Some are 
clear cut and others change code I don't really understand, but others 
on this list will.




Interesting log, I appreciate the effort you took here.   I don't really 
have too much to add here, but I'll comment on the few items below I 
have a bit of context on.


 1) drivers/input/evdev.c: adds wakelock code not dependent on 
ANDROID *** need discussion ***


I *believe* the evdev/wakelock changes has landed in modified form 
upstream in 3.5 as:

4d7e30d98939a0340022ccd49325a3d70f7e0238
epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll 
events are re


Although for now I'm still carrying the evdev wakelock change in my 
3.5-jstultz-rebase tree (since Android userland will need to be updated 
to use EPOLLWAKEUP).


22) arch/arm/kernel/etm.c: mass changes, no idea *** needs 
discussion ***


I've pinged the etm driver maintainer on the status of these patches as 
part of this blueprint:

https://blueprints.launchpad.net/linux-linaro/+spec/android-etm-upstreaming


And as you noticed we have some fixes pending in the linaro-android-3.4 
branch that I plan to send those up to AOSP when I get a chance.  Feel 
free to send me other changes and I'll queue them as well.


thanks
-john



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

Re: [PATCH] perf sched replay: fix event lookup

[Namhyung Kim]

Hi,

On Mon, 11 Jun 2012 11:08:52 -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 11, 2012 at 02:46:02PM +0900, Namhyung Kim escreveu:
>> On Sat,  9 Jun 2012 13:05:58 +0400, Dmitry Antipov wrote:
>> > Use new function trace_find_event_by_name to lookup events before
>> > looking through /sys files. This helps 'perf sched replay' to map
>> > event names to IDs correctly when processing perf.data recorded
>> > on another machine.
>> 
>> Basically the same approach with the previous reply, please put this
>> into trace_event__id(). And minor nits below..
>
> Well, trace_event__id() is private to evlist and evlist so far is a
> local thing, i.e. it doesn't know anything about perf.data files.
>

Really? I see that perf_session__open make up an evlist for the session
and a tracepoint event in the evlist should look up the perf.data
first. As this patch addressed, perf sched replay dealt with the
session->evlist already. Am I missing something?


> So I think we should have a per perf.data (perf_session) method that
> knows that it shouldn't look _at all_ to /sys, but just at what came in
> the perf.data file.
>

Fair enough. The method should be a simple wrapper to libtraceevent APIs
like this patch.


> As well when we want something that is on the running machine, even if
> we're dealing somehow with a perf.data file, we shouldn't use what is in
> it.
>

That's the current behavior of the trace_event__id(). Do you want to
make it public?

Thanks,
Namhyung

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

Re: [PATCH] perf report: fix event name reporting

[Namhyung Kim]

Hi,

On Mon, 11 Jun 2012 11:14:16 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 08, 2012 at 04:23:27PM +0400, Dmitry Antipov escreveu:
>> Use trace_find_event to find event name before looking through
>> /sys files. This helps 'perf report' to show real event names
>> instead of 'unknown:unknown' when processing perf.data recorded
>> on another machine.
>
> We have to somehow tell perf_evlist__tty_browse_hists that it should try
> to figure out the name of the event by looking at _either_ /sys (local
> events) or what came in the perf.data file.
>
> That is because 'perf top' and 'perf report' uses
> perf_evlist__tty_browse_hists. One is for local events (top) and the
> other for perf.data files, that may or not be for local (in the sense of
> running the same kernel for record + report) or for "remote" (running on
> the same machine but with a different kernel at record than the one used
> at report) or from a different machine altogether, perhaps even
> different arch.
>

I just thought that we should always consider the remote case first and
falls back to local case because if we looked for local events, the
remote events (perf.data) would not exist so that it can falls to the
local case safely.

Now I think that we need a session method to check whether the current
session is local or remote, and acts something based on that info.

Thanks,
Namhyung

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