Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Jassi Brar]

On Thu, Sep 8, 2011 at 11:04 PM, Mans Rullgard  wrote:
> This converts the per-board modules to platform drivers for a
> device created by in main platform setup.  These drivers call
> snd_soc_register_card() directly instead of going via a "soc-audio"
> device and the corresponding driver in soc-core.
>
> Signed-off-by: Mans Rullgard 
> ---
> Platform device names fixed.
> N8x0 changed to get clocks before registering card.
> ---
>  arch/arm/mach-omap2/board-3430sdp.c          |    6 ++
>  arch/arm/mach-omap2/board-4430sdp.c          |    6 ++
>  arch/arm/mach-omap2/board-am3517evm.c        |    7 +++
>  arch/arm/mach-omap2/board-devkit8000.c       |    6 ++
>  arch/arm/mach-omap2/board-igep0020.c         |    6 ++
>  arch/arm/mach-omap2/board-n8x0.c             |    6 ++
>  arch/arm/mach-omap2/board-omap3beagle.c      |    6 ++
>  arch/arm/mach-omap2/board-omap3evm.c         |    7 +++
>  arch/arm/mach-omap2/board-omap3pandora.c     |    6 ++
>  arch/arm/mach-omap2/board-overo.c            |   17 ++
>  arch/arm/mach-omap2/board-rx51.c             |    6 ++
>  arch/arm/mach-omap2/board-zoom-peripherals.c |    6 ++

Can't we do by having omap_init_audio() in arch/arm/mach-omap2/devices.c
generate a platform device of name depending upon machine_is_* ?

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

Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Jassi Brar]

On 9 September 2011 05:29, Mark Brown
 wrote:
> Jassi's suggestion was that we should have some magic to
> automatically generate defaults for the relevant device registrations to
> sidestep these issues.
Perhaps there is some misunderstanding no witchcraft is involved here.
To be clear, I suggested moving platform_device definition and registration
from 12 board files to some common platform file and use machine_is_xxx()
to assign names of those platform devices. Btw, omap_init_audio() is already
called from an arch_initcall.
Also please note that currently there's no platform_data needed to be passed.
If that requirement arise in future, an optional set_asoc_platdata(void *pdata)
could be defined beside platform_device creation.
While the idea is not absolutely good, imho, it's certainly an improvement
over this patch. Or am I overlooking something ?

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

Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Russell King - ARM Linux]

On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 12:01:02AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
> 
> > > What will happen for device tree is that there will be a device in the
> > > device tree for the ASoC board.
> 
> > Sounds like you just solved the machine_is_xxx() problem in ASoC land too
> > there.  If you're _already_ going for separate devices to describe the
> > ASoC stuff on the board, then there's no reason that couldn't have already
> > been done to eliminate the machine_is_xxx() usage in ASoC - rather than
> > complaining about machine_is_xxx() not being a very good solution.
> 
> The problem is that someone has to manually go and add the device to
> every board that needs one and people find that tedious and slightly
> inelegant

Sheesh.  So now you're arguing against your statement above?  Please
stop wasting my time.

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

How to tell which version of Snowball you have

[anmar.ou...@linaro.org]

Hello:

If you have a snowball, you can use this page
http://www.igloocommunity.org/support/Board_versions_and_markings to
tell which version the board is.

anmar

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

[PATCH v3] ASoC: omap: convert per-board modules to platform drivers

[Mans Rullgard]

This converts the per-board modules to platform drivers for a
device created by in main platform setup.  These drivers call
snd_soc_register_card() directly instead of going via a "soc-audio"
device and the corresponding driver in soc-core.

Signed-off-by: Mans Rullgard 
---
This version uses a table to assign the device name in omap_init_audio().
It is certainly less ugly than the previous patch.

Again, tested only on Beagle.
---
 arch/arm/mach-omap2/devices.c |   34 +++
 sound/soc/omap/am3517evm.c|   55 +++---
 sound/soc/omap/igep0020.c |   52 +++--
 sound/soc/omap/n810.c |   73 ++---
 sound/soc/omap/omap3beagle.c  |   55 +++---
 sound/soc/omap/omap3evm.c |   56 ---
 sound/soc/omap/omap3pandora.c |   70 ---
 sound/soc/omap/overo.c|   56 +++
 sound/soc/omap/rx51.c |   55 +--
 sound/soc/omap/sdp3430.c  |   65 ++--
 sound/soc/omap/sdp4430.c  |   60 +
 sound/soc/omap/zoom2.c|   68 +-
 12 files changed, 458 insertions(+), 241 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5b8ca68..cfec01b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -299,6 +299,10 @@ static struct platform_device omap_pcm = {
.id = -1,
 };
 
+static struct platform_device omap_soc_audio = {
+   .id = -1,
+};
+
 /*
  * OMAP2420 has 2 McBSP ports
  * OMAP2430 has 5 McBSP ports
@@ -311,8 +315,30 @@ OMAP_MCBSP_PLATFORM_DEVICE(3);
 OMAP_MCBSP_PLATFORM_DEVICE(4);
 OMAP_MCBSP_PLATFORM_DEVICE(5);
 
+static struct {
+   int machine;
+   const char *name;
+} soc_device_names[] = {
+   { MACH_TYPE_OMAP3517EVM,"am3517evm-soc-audio"   },
+   { MACH_TYPE_IGEP0020,   "igep2-soc-audio"   },
+   { MACH_TYPE_NOKIA_N810, "n8x1-soc-audio"},
+   { MACH_TYPE_NOKIA_N810_WIMAX,   "n8x1-soc-audio"},
+   { MACH_TYPE_OMAP3_BEAGLE,   "omap3beagle-soc-audio" },
+   { MACH_TYPE_DEVKIT8000, "omap3beagle-soc-audio" },
+   { MACH_TYPE_OMAP3EVM,   "omap3evm-soc-audio"},
+   { MACH_TYPE_OMAP3_PANDORA,  "pandora-soc-audio" },
+   { MACH_TYPE_OVERO,  "overo-soc-audio",  },
+   { MACH_TYPE_CM_T35, "overo-soc-audio",  },
+   { MACH_TYPE_NOKIA_RX51, "rx51-soc-audio",   },
+   { MACH_TYPE_OMAP_3430SDP,   "sdp3430-soc-audio",},
+   { MACH_TYPE_OMAP_4430SDP,   "sdp4430-soc-audio",},
+   { MACH_TYPE_OMAP_ZOOM2, "zoom2-soc-audio",  },
+};
+
 static void omap_init_audio(void)
 {
+   int i;
+
platform_device_register(&omap_mcbsp1);
platform_device_register(&omap_mcbsp2);
if (cpu_is_omap243x() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
@@ -323,6 +349,14 @@ static void omap_init_audio(void)
platform_device_register(&omap_mcbsp5);
 
platform_device_register(&omap_pcm);
+
+   for (i = 0; i < ARRAY_SIZE(soc_device_names); i++) {
+   if (machine_arch_type == soc_device_names[i].machine) {
+   omap_soc_audio.name = soc_device_names[i].name;
+   platform_device_register(&omap_soc_audio);
+   break;
+   }
+   }
 }
 
 #else
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index 73dde4a..75c8766 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -151,45 +151,60 @@ static struct snd_soc_card snd_soc_am3517evm = {
.num_links = 1,
 };
 
-static struct platform_device *am3517evm_snd_device;
-
-static int __init am3517evm_soc_init(void)
+static int __devinit am3517evm_soc_probe(struct platform_device *pdev)
 {
+   struct snd_soc_card *card = &snd_soc_am3517evm;
int ret;
 
-   if (!machine_is_omap3517evm())
-   return -ENODEV;
pr_info("OMAP3517 / AM3517 EVM SoC init\n");
 
-   am3517evm_snd_device = platform_device_alloc("soc-audio", -1);
-   if (!am3517evm_snd_device) {
-   printk(KERN_ERR "Platform device allocation failed\n");
-   return -ENOMEM;
+   card->dev = &pdev->dev;
+
+   ret = snd_soc_register_card(card);
+   if (ret) {
+   dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n",
+   ret);
+   return ret;
}
 
-   platform_set_drvdata(am3517evm_snd_device, &snd_soc_am3517evm);
+   return 0;
+}
 
-   ret = platform_device_add(am3517evm_snd_device);
-   if (ret)
-   goto err1;
+static int __devexit am3517evm_soc_remove(struct platform_device

Re: repo and other mirroring

[Paul Sokolovsky]

Hello Loic,

(cc:ing list)

On Thu, 8 Sep 2011 13:26:57 +0200
Loïc Minier  wrote:

> On Thu, Sep 08, 2011, Paul Sokolovsky wrote:
> > Repo is bad tool for mirroring. We came to that conclusion, as other
> > folks before us. So, android-build repo mirror waits for it rewrite,
> > left in peace for now that it "mostly works". But for upstream
> > mirror for Gerrit, I implemented it via previously queued ideas of
> > "proper" git mirror. It's not deployed in production mode yet -
> > kernel.org downtime stroke right in the middle of it.
> > 
> > Gerrit upstream mirror is essentially loop over existing working
> > repository tree in FS, anf git pull/push each with suitable ref
> > params (I tried --mirror first, but that doesn't work well with
> > Gerrit). The devel codxe is here:
> > https://code.launchpad.net/~linaro-infrastructure/linaro-android-gerrit-support/gerrit-support
> 
>  It seems there is an important new problem with the use case of
>  mirroring for Gerrit: detecting new projects and removed projects as
> to provision/unprovision in Gerrit (gerrit create-project).  I guess
> we're not too strict about removing projects/cleaning up git repos
> removed from manifests right now.

Yes. Actually there're 2 problems: 1) detecting new upstream projects
(there's script for that, but not expected to be run automatically so
far); 2) properly migrating our own components to Gerrit, - so far we
just leave old repos in place to keep old releases fetchable, but I
expect this to lead to a mess. Btw, projects in Gerrit are not
deletable in normal way ;-). (One could hack on DB level, yeah.)

> 
>  Do I understand correctly that we have a mirror AND the Gerrit copy
> of the repos? (/srv/git.linaro.org/git/android + /mnt/gerrit-mirror
>  respectively)

Yes, we have Gerrit-served master repositories, plus we have workcopy
checkout to perform merges with upstream. Well, those merges are not
merges, but fast-forwards of upstream branch subset, it would be cool
if git could do fast-forward from a repository to repository w/o
working copy, but of course that wouldn't work in general case of
merges and conflicts.


>  Also, a general choice with a generic mirroring service is whether we
>  try sharing the mirrored data effectively.  Say we want to mirror
>  Cyanogenmod manifests, or if someone wanted to mirror Android
> upstream
>  + Linaro manigests, could we do so in a way which avoids duplicating
>  the contents of repos.  
> This can quickly jump to
> github/gitorious-level complexity though, but some of it needs to be
> considered now (like the fact that Linaro has plenty of manifests and
> they point at 99% of the same data, so a mirror of Linaro with
> separate storage per-manifest would be unacceptably costly).

I'm not sure I follow exactly. Are you talking about sharing git pack
data across repositories, knowing they're close forks of each other? I
never heard about that, nor I think its worth being pursued, because
there's enough complexity already. It can be handled on specific
project level somehow, for example Linaro codebase is a proper superset
of AOSP, with fetching Linaro tree, one would have (easily separatable)
access to both AOSP and Linaro code (technically, not politically).

>  Another problem I see with our current usage is that the branch names
>  keep changing, for instance linaro_android_2.3.5, and because this is
>  where we get manifests from, it might be tricky hardcoding this into
>  the mirroring service.

Good mirroring service wouldn't be tight to specific branch, I guess.

> > >  I've solved c) by forking repo for myself, packaging it as
> > > a .deb and nuking the repo updating pieces, but a) and b) remain
> > > issues with the result.  I have other concerns with repo:
> > >  * quite complex and hairy for what it does in practice
> > 
> > Yeah, just faced it that with latest "repo patched to fetch all
> > tags" campaign - seeminingly small changes broke mirroring and
> > suspectedly adversely affected performance.
> 
>  I didn't pull your patch yet, but my intent was to pull exactly that
>  feature; it's the top three commits at:
>  
> http://android.git.linaro.org/gitweb?p=tools/repo.git;a=shortlog;h=refs/heads/linaro-stable
>  right?

Yes. Please note that I personally consider it flawed experiment. It
would have its limited usage, but to claim it's generally-suitable
solution, it would need lot of testing. (With all these experiments, I
got feeling that magic that repo does is very well thought, and keeps
acceptable performance when dealing with truly enormous Android codebase
at shaky equilibrium, so changing seemingly small thing can drop
checkout speed twice for example).

> > Yes, that's for sure a way to go. Except that after the patched repo
> > experiments I have suspicion that running repo against complete git
> > mirror vs repo's partial mirror may increase sync time and
> > I/O complexity (the latter hits in full in case of parallel
> > fetches).
> 
>  You're saying we s

[NOTES] Linaro Release Meeting 2011-09-08

[Fathi Boudra]

Enclosed, please find a link to the agenda, notes and actions from the Linaro
Release Weekly meeting held on September 8th in #linaro-meeting on
irc.freenode.net at 16:00 UTC.

== Meeting Minutes ==

 http://wiki.linaro.org/Cycles/WeeklyReleaseMeeting/2011-09-08

== Meeting Log ==

 
http://irclogs.linaro.org/meeting-logs/linaro-meeting/2011/linaro-meeting.2011-09-08-16.05.log.html

== Previous actions items ==

 * Mounir to open the discussion with Michael Hope about Toolchain WG release
   date. - DONE
   Michael Hope agreed to change the Toolchain WG release scheme to two weeks
   before Linaro release. It will give Developer Platform and Android Teams a
   fixed two weeks between the toolchain and the platform release.

 REMINDER: next Toolchain WG release is next Thursday (September 15th)

 * james_w/pfalcon/fabo to follow-up closely on disk space issues, quote of
   hardrive. - INPROGRESS
   The drives have been ordered. They should be with us tomorrow
(September 9th).

== Agenda ==

 * Current focus:
  - the list of components delivered for this cycle is up-to-date - DONE
  - the milestone pages for this cycle are created - DONE
  - the blueprints are targeted to this cycle - DONE
  - the blueprints have a headline and an acceptance criteria - INPROGRESS
See http://wiki.linaro.org/Cycles/1109/Release/Blueprints

 * Weekly call for testing
   It was sent to board owners this week. We're working on another approach,
   trying to make it more efficient/useful.
   lava-qatracker work is ongoing. An initial version is planned for this cycle.

 * Release response team setup started
   See https://wiki.linaro.org/Cycles/1109/Release/PointOfContacts
   We don't have a full boards coverage yet. Android PoC are missing. Zach will
   send his list soon.

 * Reminder on the release dates
   See http://wiki.linaro.org/Cycles/1109/Release/Status
   It's available from the release dashboard:
http://wiki.linaro.org/Cycles/1109/Release/Dashboard.
   In addition, the Release calendar is shared with everyone.

== Image status ==

 * Ubuntu-build - no issues to report.
 * LT Snowball hwpack is disabled in favor of V2 and V3 hpwacks.
 * Linaro patched repo is dropped
 * Android-build is stable now.

== Bugs ==

 * http://bugs.launchpad.net/bugs/709245 High
  ARM SMP scheduler performance bug
  => Tracked by jcrigby, we have a fix

 * http://bugs.launchpad.net/bugs/732912 High
  omapdss DISPC error: GFX_FIFO_UNDERFLOW
  => Tracked by mounir/doanac; fixed according to doanac

 * http://bugs.launchpad.net/bugs/753878 High
  Ubuntu image - icons and parts of screen disappear with Origen
  => Assigned to rsalveti, important to get fixed but no progress

 * http://bugs.launchpad.net/bugs/754254 High
  imx51 randomly truncates serial input at 31 characters
  => Spring can't verify because of 2 other bugs (see below)

 * http://bugs.launchpad.net/bugs/788746 High
  Ethernet is not enabled be default
  => Assigned to mpoirier, being worked on

 * http://bugs.launchpad.net/bugs/789095
  Bluetooth does not work on PandaBoard
  => Assigned to rsalveti

 * http://bugs.launchpad.net/bugs/807230 High
  ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07
  => Assigned to vishal, being worked on

 * http://bugs.launchpad.net/bugs/816491 High
  System crashes when display attempts to sleep
  => Waiting for Andy Green, we need LT support on that

 * http://bugs.launchpad.net/bugs/816638 High
  Pulseaudio consumes 100% of the cpu when trying to play a sound with
natty's linaro LEB and 3.0.0-1402-linaro-lt-omap
  => Assigned to rsalveti, kan_hu is helping; in progress

 * http://bugs.launchpad.net/bugs/823313 High
  Android LEB fails to mount system and user partition interminttently
  => Assigned to philang, no progress, Anmar/Tony to get information on the bug

 * http://bugs.launchpad.net/bugs/824506
  Graphics driver on i.MX53 Android issues
  => Fix commited on Android userland, FSL may want to fix the driver

 * http://bugs.launchpad.net/bugs/829220 Critical
  linaro-media-create fails for snowball_emmc
  => Fixed but trigger another issue, mpoirier to comment

 * http://bugs.launchpad.net/bugs/832356 High
  LT-Panda 11.07/08 lacks device tree support
  => Assigned to rsalveti

 * http://bugs.launchpad.net/bugs/832680 High
  Make available source and debug packages corresponding to Linaro binary images
  => Assigned to rsalveti

 * http://bugs.launchpad.net/bugs/839539
  mx51evk can't load uImage and dtd from mmc card
  => Eric M. waiting for Spring response

 * http://bugs.launchpad.net/bugs/839541
  mx51evk can't find rootfs by UUID, LABEL or device node, then drop
to initramfs
  => Eric M. waiting for Spring response

 * http://bugs.launchpad.net/bugs/841778
  leb-origen failed to build for a couple days in a row
  => Assigned to Botao/Angus, Trigger bug 844380 and bug 844041, in progress

 * http://bugs.launchpad.net/bugs/841781
  no release builds for 11.09 have been set up yet
  => Zach will release build

Android tip built with gcc 4.6 tip

[Chao Yang]

Hi,

To minimise the impact of the switch to Linaro toolchain 1109, I am tracking
gcc tip code and building Android tip code against it, which, with the aim
of finding and fixing problems as early as possible, is part of BP
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-integrate-11.09-toolchain.
 These activities will keep going until gcc 1109 is released on 15th
September.

The current revno of gcc 4.6 is 106800, whose code can be downloaded by
running "bzr branch lp:gcc-linaro/4.6" and whose build can be found at
https://android-build.linaro.org/builds/~chaoyang/android-gcc-4.6-code-tip-with-generic-target/
.
The gcc build has already been patched with
http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50116.patch
http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50266.patch

The various Android builds against gcc 4.6 tip build can be found below. The
builds for panda and leb-panda have been tested and both of them work fine.

[beagle]
https://android-build.linaro.org/builds/~chaoyang/beagle/

[leb-snowball]
https://android-build.linaro.org/builds/~chaoyang/leb-snowball/

[leb-imx53]
https://android-build.linaro.org/builds/~chaoyang/leb-imx53/

[leb-origen]
https://android-build.linaro.org/builds/~chaoyang/leb-origen/

[leb-panda] -- verified working fine
https://android-build.linaro.org/builds/~chaoyang/leb-panda/

[panda] -- verified working fine
https://android-build.linaro.org/builds/~chaoyang/panda/

Should you have any problems, please feel free to let me know. Thanks.

Regards
-- 

Chao Yang
Android Platform Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro:
http://www.facebook.com/pages/Linaro/155974581091106
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: repo and other mirroring

[Loïc Minier]

On Fri, Sep 09, 2011, Paul Sokolovsky wrote:
> >  Also, a general choice with a generic mirroring service is whether we
> >  try sharing the mirrored data effectively.  Say we want to mirror
> >  Cyanogenmod manifests, or if someone wanted to mirror Android
> > upstream
> >  + Linaro manigests, could we do so in a way which avoids duplicating
> >  the contents of repos.  
> > This can quickly jump to
> > github/gitorious-level complexity though, but some of it needs to be
> > considered now (like the fact that Linaro has plenty of manifests and
> > they point at 99% of the same data, so a mirror of Linaro with
> > separate storage per-manifest would be unacceptably costly).
> 
> I'm not sure I follow exactly. Are you talking about sharing git pack
> data across repositories, knowing they're close forks of each other? I
> never heard about that, nor I think its worth being pursued, because
> there's enough complexity already. It can be handled on specific
> project level somehow, for example Linaro codebase is a proper superset
> of AOSP, with fetching Linaro tree, one would have (easily separatable)
> access to both AOSP and Linaro code (technically, not politically).

 Good example of what I meant: I don't think we want to go as far as
 sharing git pack data across repositories which are close, that's
 clearly on the too complex side of things.  However we also don't want
 to keep it too simple, like one mirror data set for each manifest.xml
 that we mirror.  Instead, it's likely going to be something like
 parsing all manifests that we want to mirror, building a map from them
 of which git repos and branches and tags and shas we want to mirror,
 then mirroring that in a flat hierarchy, then finding a way to consume
 the resulting super-mirror.

> >  Another problem I see with our current usage is that the branch names
> >  keep changing, for instance linaro_android_2.3.5, and because this is
> >  where we get manifests from, it might be tricky hardcoding this into
> >  the mirroring service.
> Good mirroring service wouldn't be tight to specific branch, I guess.

 Yup; just wanted to point out that this is a bit specific to our choice
 of workflow, and not generic.  If we try to create a *reusable* tool to
 mirror manifests, we want to be careful not too put too many smarts
 which are only relevant to Linaro.  I didn't really think about that,
 maybe it's just a matter of giving an easy way to Linaro to provision
 new branch names to the mirroring service, or maybe it should be done
 with a manifest_branch_name_regexp="^linaro_android_.*" kind of
 approach.

> Yes. Please note that I personally consider it flawed experiment.

 Ok, understood, also thanks to the detailed list of issues you passed;
 I'll wait and see a bit more on that one.

> would have its limited usage, but to claim it's generally-suitable
> solution, it would need lot of testing. (With all these experiments, I
> got feeling that magic that repo does is very well thought, and keeps
> acceptable performance when dealing with truly enormous Android codebase
> at shaky equilibrium, so changing seemingly small thing can drop
> checkout speed twice for example).
[...]
> No, I'm saying that I have intuitive suspicions that it may affect
> performance, so we'd rather take necessity of performance and load
> tests for this work seriously. And if performance degradation against
> reference design (repo) will be proven, think what to do about it.

 Noted

> Well, I don't know. We for sure would want to (try to) improve build
> checkout time, and all ways should be considered. At repo is after just
> a tool which checks out a list of git repositories at specified
> revisions, so if we'd find more optimal way to do that (though likely
> more limited in other aspects), why not?

 Yup; replacing repo with a compatible interface for our limited cases
 is fine, but it seems important to preserve the possibility of using
 repo in the workflow.

> >  Ah, so you've played with python-git and it sucks?  
> No, I didn't mean that. I meant that before moving to using more
> intricate API level which would be allowed by using language binding,
> it would makes sent to try to implement it in terms of git pull/push,
> if that's not enough - git fetch, and only if still not enough - to
> employ even more complex solutions.

 Oh just seemed a better idea to me to use python-git instead of
 wrapping git pull, git clone, git fetch etc.; this wasn't to do
 specifically advanced things.  I was simply hoping this would draw a
 nice line in the sand in terms of responsibilities and give us a
 cleaner interface to do git-ish stuff.

-- 
Loïc Minier

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

[ACTIVITY] Kernel WG Weekly Status report for week ending 2011-09-09

[Mounir Bsaibes]

Enclosed  please find the link to the Weekly Status report
for the kernel  working group for the week ending 2011-09-09.


== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-08

== Summary, for details see the Status Report ==

  * Many Working Group members at Linux Plumbers Conference

  * Rewrote the Freescale internal i.mx6q clock codes.  With the common
pattern applied as much as possible, the LOC gets reduced to ~2K from the
original ~5K.
  * submitted dt migrated patches(v2) for i2c controller along with generic
board files for omap3 and omap4
  * Submitted second version of pl330 dma controller device tree support
patches.
  * Submitted gpio and pinctrl device tree support patches for exynos4.
  * Submitted gic and interrupt combiner controller device tree support
patches for exynos4.
  * Submitted rtc device tree support patch for samsung's rtc driver.
  * Started working on device tree support for exynos4 keypad controller
driver.
  * Pushed out v6 of the pinctrl/pinmux subsystem.
  * i.MX6Q (4 Cortex-A9 cores SMP) u-boot upstream preparation.

Best regards,
Mounir


-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
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

[ACTIVITY] Power Management WG Weekly Status report week ending 2011-09-09

[Mounir Bsaibes]

Enclosed  please find the link to the Meeting Minutes & Weekly Status report

for the Power Management working group for the week ending 2011-09-09.

== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-09-07

== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-09-08


== Summary ==

   * Updated sched_mc wiki, but page still under construction -
https://wiki.linaro.org/WorkingGroups/PowerManagement/Specs/sched_mc
   * Testing sched_mc configuration, outlook for results in 1-2 weeks
   * Implemented exynos4 sleep code with SR common platform code and
published it
   * Worked on fixing exynos4 thermal sensor with the steve's generic
thermal framework code. Did some testing and was able to use all components,
cooling device, thermal governor, thermal sensor 
   * There might be a chance to have a common code for suspend, cpuidle and
hotplug, will post after more testing is done
   * Started taking measurements to determine if cpuidle menu governor uses
signifcant power


Best regards,
Mounir



-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
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: Android tip built with gcc 4.6 tip

[Christian Robottom Reis]

On Fri, Sep 09, 2011 at 02:17:29PM +0100, Chao Yang wrote:
> To minimise the impact of the switch to Linaro toolchain 1109, I am tracking
> gcc tip code and building Android tip code against it, which, with the aim

Good job on proactively looking for bustage. I assume you guys worked
out a plan with Michael on how to provide feedback on the issues we
find -- let me know if that needs work.

When you say "gcc tip code" above, I think you actually mean "gcc-linaro
tip code". Is that right?

> The gcc build has already been patched with
> http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50116.patch
> http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50266.patch

For the sake of sanity, it may help to name those patches using "PR"
instead of bug as they actually refer to GCC PRs.

Are those patches not going to make it into the 11.09 gcc-linaro spin?
-- 
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: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Mark Brown]

On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:

> > The problem is that someone has to manually go and add the device to
> > every board that needs one and people find that tedious and slightly
> > inelegant

> Sheesh.  So now you're arguing against your statement above?  Please
> stop wasting my time.

There's two things going on here - what we are doing and what people
would like to be able to do.  What we are doing is explicitly adding
devices, what people would like to do is infer the devices from the
board type.  Personally I'm totally happy with explicitly adding an
audio device, but not everyone is and I do understand where they're
coming from.

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

Re: [PATCH v3] ASoC: omap: convert per-board modules to platform drivers

[Mark Brown]

On Fri, Sep 09, 2011 at 12:38:51PM +0100, Mans Rullgard wrote:
> This converts the per-board modules to platform drivers for a
> device created by in main platform setup.  These drivers call
> snd_soc_register_card() directly instead of going via a "soc-audio"
> device and the corresponding driver in soc-core.
> 
> Signed-off-by: Mans Rullgard 

Acked-by: Mark Brown 

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

First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Zach Pfeffer]

Linaro has been hard at work getting the first 11.09 candidate builds
out. All instructions, test results and tips are listed at each link.

Of note:

Replaced jpeg lib with libjpeg-turbo
Linux version 3.0.3
gcc version 4.6.2 20110813 (prerelease)
Compiled with -O3

Panda
https://android-build.linaro.org/builds/~linaro-android/panda-11.09-release/#build=2

Stage Panda
https://android-build.linaro.org/builds/~linaro-android/stage-panda-11.09-release/#build=1

Beagle, Beagle xM
https://android-build.linaro.org/builds/~linaro-android/beagle-11.09-release/#build=2

Stage iMX53
https://android-build.linaro.org/builds/~linaro-android/stage-imx53-11.09-release/#build=2

Stage Origen
https://android-build.linaro.org/builds/~linaro-android/stage-origen-11.09-release/#build=2

Snowball
https://android-build.linaro.org/builds/~linaro-android/stage-snowball-11.09-release/#build=4

The term "Stage" is used to indicate builds that contain patches that
haven't been upstreamed.

The only build with graphics acceleration is Stage Panda.

Enjoy the builds. As always, please file lots of bugs
(https://bugs.launchpad.net/linaro-android/+filebug)!

(Google Plus: https://plus.google.com/104422661029399872488/posts/Yvg3iv34E9s)

-Zach

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

Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Christian Robottom Reis]

On Fri, Sep 09, 2011 at 12:09:55PM -0500, Zach Pfeffer wrote:
> The term "Stage" is used to indicate builds that contain patches that
> haven't been upstreamed.

That a pretty confusing term. Are we sure we want to call it that?
-- 
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: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Russell King - ARM Linux]

On Fri, Sep 09, 2011 at 09:11:52AM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
> 
> > > The problem is that someone has to manually go and add the device to
> > > every board that needs one and people find that tedious and slightly
> > > inelegant
> 
> > Sheesh.  So now you're arguing against your statement above?  Please
> > stop wasting my time.
> 
> There's two things going on here - what we are doing and what people
> would like to be able to do.  What we are doing is explicitly adding
> devices, what people would like to do is infer the devices from the
> board type.  Personally I'm totally happy with explicitly adding an
> audio device, but not everyone is and I do understand where they're
> coming from.

Well, with DT, there won't be any 'board type' anymore.  There won't be
any 'machine_is_xxx()' to sort it out anymore.  Using DT, all that will
be history - it's all got to be sorted out by either devices or device
properties.

So, given that, I don't see the logic of having two methods - it might
as well be dealt with by devices and [platform data for non-DT | DT
properties], and which then means we have everything working the same
way irrespective of what the backing data for the platform actually is.

Therefore, as we are heading for DT, I'd definitely say that having
machine_is_xxx() outside of arch/arm is a bug, no less and no more.

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

Re: [PATCH v3] ASoC: omap: convert per-board modules to platform drivers

[Russell King - ARM Linux]

On Fri, Sep 09, 2011 at 12:38:51PM +0100, Mans Rullgard wrote:
> This converts the per-board modules to platform drivers for a
> device created by in main platform setup.  These drivers call
> snd_soc_register_card() directly instead of going via a "soc-audio"
> device and the corresponding driver in soc-core.
> 
> Signed-off-by: Mans Rullgard 
> ---
> This version uses a table to assign the device name in omap_init_audio().
> It is certainly less ugly than the previous patch.
> 
> Again, tested only on Beagle.
> ---
>  arch/arm/mach-omap2/devices.c |   34 +++
>  sound/soc/omap/am3517evm.c|   55 +++---
>  sound/soc/omap/igep0020.c |   52 +++--
>  sound/soc/omap/n810.c |   73 
> ++---
>  sound/soc/omap/omap3beagle.c  |   55 +++---
>  sound/soc/omap/omap3evm.c |   56 ---
>  sound/soc/omap/omap3pandora.c |   70 ---
>  sound/soc/omap/overo.c|   56 +++
>  sound/soc/omap/rx51.c |   55 +--
>  sound/soc/omap/sdp3430.c  |   65 ++--
>  sound/soc/omap/sdp4430.c  |   60 +
>  sound/soc/omap/zoom2.c|   68 +-
>  12 files changed, 458 insertions(+), 241 deletions(-)

I don't think this is an improvement.  Just look at the diffstat - it almost
doubles the number of lines of code.

One thing here which is utterly silly is:

> +static struct {
> + int machine;
> + const char *name;
> +} soc_device_names[] = {
> + { MACH_TYPE_OMAP3517EVM,"am3517evm-soc-audio"   },
> + { MACH_TYPE_IGEP0020,   "igep2-soc-audio"   },
> + { MACH_TYPE_NOKIA_N810, "n8x1-soc-audio"},
> + { MACH_TYPE_NOKIA_N810_WIMAX,   "n8x1-soc-audio"},
> + { MACH_TYPE_OMAP3_BEAGLE,   "omap3beagle-soc-audio" },
> + { MACH_TYPE_DEVKIT8000, "omap3beagle-soc-audio" },
> + { MACH_TYPE_OMAP3EVM,   "omap3evm-soc-audio"},
> + { MACH_TYPE_OMAP3_PANDORA,  "pandora-soc-audio" },
> + { MACH_TYPE_OVERO,  "overo-soc-audio",  },
> + { MACH_TYPE_CM_T35, "overo-soc-audio",  },
> + { MACH_TYPE_NOKIA_RX51, "rx51-soc-audio",   },
> + { MACH_TYPE_OMAP_3430SDP,   "sdp3430-soc-audio",},
> + { MACH_TYPE_OMAP_4430SDP,   "sdp4430-soc-audio",},
> + { MACH_TYPE_OMAP_ZOOM2, "zoom2-soc-audio",  },
> +};

So you're using the machine ID to select the name of the device.
(That's not really DT compatible.)

> +static int __init am3517evm_soc_init(void)
> +{
> + if (!machine_is_omap3517evm())
> + return -ENODEV;

But then you conditionalize the registration of the drivers on the
platform as well.  Why?  It's pointless.  If you don't have the core
code register the struct device for this platform then this driver
won't be bound to a device, and therefore the probe function won't be
called.

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

Re: Android tip built with gcc 4.6 tip

[Bernhard Rosenkranzer]

On 9 September 2011 08:35, Christian Robottom Reis  wrote:
> Good job on proactively looking for bustage. I assume you guys worked
> out a plan with Michael on how to provide feedback on the issues we
> find -- let me know if that needs work.

I presume normal bug reports will do the trick...

> When you say "gcc tip code" above, I think you actually mean "gcc-linaro
> tip code". Is that right?

yes

>> The gcc build has already been patched with
>> http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50116.patch
>> http://people.linaro.org/~bernhardrosenkranzer/gcc-4.6-11.08-bug50266.patch
>
> For the sake of sanity, it may help to name those patches using "PR"
> instead of bug as they actually refer to GCC PRs.

OK with me -- I've symlinked them so new builds may use pr while old
ones keep working.

> Are those patches not going to make it into the 11.09 gcc-linaro spin?

Not sure - the bug is tracked in
https://bugs.launchpad.net/gcc-linaro/+bug/827990
so the toolchain guys are aware of it.

Since the bug breaks our build, we need the fix in right now - so
until it does get in, we're using the GCC_PATCH_URL mechanism to
inject the patches.

ttyl
bero

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

Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Mark Brown]

On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote:

> Well, with DT, there won't be any 'board type' anymore.  There won't be
> any 'machine_is_xxx()' to sort it out anymore.  Using DT, all that will
> be history - it's all got to be sorted out by either devices or device
> properties.

There is a board type - there's a root compatible property for the board
which fulfils this purpose - so the situation with and without device
tree is essentially the same.

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

Re: [Patch v2 08/11] Touch: DA9052 touchscreen driver

[Dmitry Torokhov]

Hi Ashish,

On Fri, Aug 12, 2011 at 07:20:26PM +0530, ashishj3 wrote:
> This driver add support for DA9052 4-wire resistive ADC interfaced touchscreen
> controller.
> 
> DA9052 is a MFD therefore this driver depends on DA9052 core driver for core
> functionalities.
> 
> Signed-off-by: David Dajun Chen 
> Signed-off-by: Ashish Jangam 
> ---
> Changes since v2:
> - Replace kthreads with workqueue
> - Remove kfifos
> - Remove extra struct memebers
> - Taken care for bus type
> - Replace da9052_set/clear function with da9052_reg_update ( as DA9052 MFD 
> got modified)
> - Add open and close functionality
> ---
>  drivers/input/touchscreen/Kconfig  |7 +
>  drivers/input/touchscreen/Makefile |1 +
>  drivers/input/touchscreen/da9052_tsi.c |  400 
> 
>  3 files changed, 408 insertions(+), 0 deletions(-)
>  create mode 100755 drivers/input/touchscreen/da9052_tsi.c
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index cabd9e5..a5d2e7b 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -144,6 +144,13 @@ config TOUCHSCREEN_DA9034
> Say Y here to enable the support for the touchscreen found
> on Dialog Semiconductor DA9034 PMIC.
>  
> +config TOUCHSCREEN_DA9052
> + tristate "Dialog DA9052 TSI"
> + depends on PMIC_DA9052
> + help
> +   Say y here to support the touchscreen found on
> +   Dialog Semiconductor DA9052 PMIC
> +
>  config TOUCHSCREEN_DYNAPRO
>   tristate "Dynapro serial touchscreen"
>   select SERIO
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index 282d6f7..a4aeb25 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_TOUCHSCREEN_BITSY) += 
> h3600_ts_input.o
>  obj-$(CONFIG_TOUCHSCREEN_BU21013)   += bu21013_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_DA9034) += da9034-ts.o
> +obj-$(CONFIG_TOUCHSCREEN_DA9052) += da9052_tsi.o
>  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)+= dynapro.o
>  obj-$(CONFIG_TOUCHSCREEN_HAMPSHIRE)  += hampshire.o
>  obj-$(CONFIG_TOUCHSCREEN_GUNZE)  += gunze.o
> diff --git a/drivers/input/touchscreen/da9052_tsi.c 
> b/drivers/input/touchscreen/da9052_tsi.c
> new file mode 100755
> index 000..1b31dd1
> --- /dev/null
> +++ b/drivers/input/touchscreen/da9052_tsi.c
> @@ -0,0 +1,400 @@
> +/*
> + * TSI driver for Dialog DA9052
> + *
> + * Copyright(c) 2011 Dialog Semiconductor Ltd.
> + *
> + * Author: David Dajun Chen 
> + *
> + *  This program is free software; you can redistribute  it and/or modify it
> + *  under  the terms of  the GNU General  Public License as published by the
> + *  Free Software Foundation;  either version 2 of the  License, or (at your
> + *  option) any later version.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +struct da9052_tsi_reg {
> + u16 x;
> + u16 y;
> + u16 z;
> +};
> +
> +struct da9052_tsi {
> + struct da9052   *da9052;
> + struct input_dev *dev;
> + struct workqueue_struct *ts_workq;
> + struct work_struct ts_report_penup;
> + int irq_pendwn;
> + int irq_datardy;
> + int pendown;

Bool maybe?

> + int workschd;
> + uint8_t lsb;
> +};
> +
> +static int da9052_ts_start(struct da9052_tsi *tsi)
> +{
> + return da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG,
> +  1 << 0, 1 << 0);
> +}
> +
> +static int da9052_ts_stop(struct da9052_tsi *tsi)
> +{
> + return da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, 1 << 0, 0);
> +}
> +
> +static irqreturn_t da9052_ts_pendwn_irq(int irq, void *data)
> +{
> + struct da9052_tsi *tsi = (struct da9052_tsi *)data;

No need to cast.

> + struct da9052 *da9052 = tsi->da9052;
> + int ret;
> +
> + /* Mask PEN_DOWN event and unmask TSI_READY event */
> + da9052->events_mask |= DA9052_E_PEN_DOWN;
> + da9052->events_mask &= ~DA9052_E_TSI_READY;
> + ret = da9052_reg_update(da9052, DA9052_IRQ_MASK_B_REG, 0x80, 0x40);
> + if (ret < 0)
> + return IRQ_NONE;
> +
> + da9052_ts_start(tsi);
> + tsi->pendown = 1;
> +
> + input_report_key(tsi->dev, BTN_TOUCH, 1);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int da9052_ts_read(struct da9052_tsi *tsi)
> +{
> + struct da9052_tsi_reg co_ord = {0, 0, 0};
> + int ret;
> + uint8_t _x, _y, _z, _v;
> +
> + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_X_MSB_REG);
> + if (ret < 0)
> + return ret;
> +
> + _x = (uint8_t) ret;
> +
> + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_Y_MSB_REG);
> + if (ret < 0)
> + return ret;
> +
> + _y = (uint8_t) ret;
> +
> + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_Z_MSB_REG);
> + if (ret < 0)
> +  

Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

[Russell King - ARM Linux]

On Fri, Sep 09, 2011 at 12:30:11PM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote:
> 
> > Well, with DT, there won't be any 'board type' anymore.  There won't be
> > any 'machine_is_xxx()' to sort it out anymore.  Using DT, all that will
> > be history - it's all got to be sorted out by either devices or device
> > properties.
> 
> There is a board type - there's a root compatible property for the board
> which fulfils this purpose - so the situation with and without device
> tree is essentially the same.

So instead of a table of machine id numbers and soc device strings, you're
going to have a table of board 'compatible' strings and soc device strings,
and you're going to have to manually create the struct device with that
name.

That's just twisted and utterly insane - adding more code for precisely
zero benefit what so ever.  Think about it - the device tree is *already*
creating platform devices for entries in the device tree file.  What's
the point of having this special ASoC code look up the platform compatible
property in a table of strings to find a different string to manually
create a device with.  Why not just _add_ the bloody device to the DT
file in the first place?  That's partly what DT is there for - to create
platform specific struct devices.

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

[PATCH] ORIGEN : use absolute paths for tools directory

[Angus Ainslie]

On some hosts using relative paths will cause the build to fail. This 
patch sets absolute paths for the tools directory

Signed-off-by: Angus Ainslie 
---
 board/samsung/origen/Makefile |6 +++---
 spl/Makefile  |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/samsung/origen/Makefile b/board/samsung/origen/Makefile
index f5c6507..b8a495f 100644
--- a/board/samsung/origen/Makefile
+++ b/board/samsung/origen/Makefile
@@ -41,7 +41,7 @@ OBJS  := $(addprefix $(obj),$(COBJS) $(SOBJS))
 ALL+=$(obj).depend $(LIB)
 
 ifdef CONFIG_SPL_BUILD
-ALL+= tools/mk$(BOARD)spl.exe
+ALL+= $(OBJTREE)/tools/mk$(BOARD)spl.exe
 endif
 
 all:   $(ALL)
@@ -50,8 +50,8 @@ $(LIB):   $(OBJS)
$(AR) $(ARFLAGS) $@ $(OBJS)
 
 ifdef CONFIG_SPL_BUILD
-tools/mk$(BOARD)spl.exe:   tools/mkv310_image.c
-   $(HOSTCC) tools/mkv310_image.c -o tools/mk$(BOARD)spl.exe
+$(OBJTREE)/tools/mk$(BOARD)spl.exe:tools/mkv310_image.c
+   $(HOSTCC) tools/mkv310_image.c -o $(OBJTREE)/tools/mk$(BOARD)spl.exe
 endif
 
 #
diff --git a/spl/Makefile b/spl/Makefile
index 95ecce1..8613a7c 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -101,7 +101,7 @@ all:$(ALL-y)
 
 ifdef CONFIG_SAMSUNG
 $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin
-   $(TOPDIR)/board/$(BOARDDIR)/tools/mk$(BOARD)spl.exe \
+   $(OBJTREE)/tools/mk$(BOARD)spl.exe \
$(obj)u-boot-spl.bin $(obj)$(BOARD)-spl.bin
 endif
 
-- 
1.7.4.1

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

[PATCH] ORIGEN : enable device tree support

[angus . ainslie]

From: Angus Ainslie 

Enable passing a flattened device tree to the kernel.

Signed-off-by: Angus Ainslie 
---
 include/configs/origen.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/configs/origen.h b/include/configs/origen.h
index 889d5fc..380ef4f 100644
--- a/include/configs/origen.h
+++ b/include/configs/origen.h
@@ -165,4 +165,7 @@
 #define COPY_BL2_SIZE  0x8
 #define BL2_START_OFFSET   ((CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)/512)
 #define BL2_SIZE_BLOC_COUNT(COPY_BL2_SIZE/512)
+
+/* Enable devicetree support */
+#define CONFIG_OF_LIBFDT
 #endif /* __CONFIG_H */
-- 
1.7.4.1


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