On 04/24/2012 08:24 PM, Andy Green wrote:
On 04/25/2012 11:12 AM, Somebody in the thread at some point said:
We're still undergoing uplevel on tilt-tracking and didn't get back to
tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we
have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board
support redundant? If LTs base on this, they will add in their own
golden initial defconfig for their board(s) at that point; when they're
combined they'll all be in the combined tree. It seems like I shouldn't
be seeing a defconfig about Panda coming in with this base tree, but
create it (perhaps after mixing in config fragments that did come in
with the base tree) in my tree.
We could just have the fragments per topic, and then the LT can decide
either to add another fragment, or simply creating an entire different
config to be used by default.
Having everything in config fragments may help automating the builds,
but I understand that having one defconfig might also help people that
are consuming the tree directly.
Yes I'm not really referring to fragment process here, I understand the
idea and as I wrote expect the common one(s) to come in with this base tree.
What I'm talking about is ./configs/panda.conf brought in by this
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commitdiff;h=36f22ea6ac55d44026d374669cb55c60bb366d4e
actually, now we don't maintain anything directly equivalent, we only
have omap4plus_defconfig that builds a single kernel that runs with
everything we support, including OMAP543x.
I guess panda.conf is trying to be mainline compatible OMAP44x0 Panda
config. But what we're going to provide, and what's meaningful and
tested with our tree, will be this omap4plus_defconfig that appears in
our topics. panda.conf that we are inheriting from this basis branch
may not even build with our tree, it's at least confusing to have it
there and at worst it'll mislead end users, rot as we go on etc.
Yea, it was added mainly for demonstration purposes for how the config
fragments might work.
(It also is something I use for my panda on android testing, but that
doesn't warrant it being included).
There may be some need for a config that the (oh the names have changed
so much I don't know what its called)
vanilla-upstream-android-builds-for-panda uses. But I'm happy to locate
that somewhere else or with a more clear name.
Even so, if you and Andrey have a system that works for the omap config
fragment, I'm fine dropping the configs/panda.conf
thanks
-john
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
