[meta-ti] [PATCH v2 1/6] linux-omap4: update to ti-ubuntu-3.4-1487.6

[Denys Dmytriyenko]

On Fri, Oct 12, 2012 at 11:11:50PM +0200, Nicolas Dechesne wrote:
> On Fri, Oct 12, 2012 at 10:53 PM, Denys Dmytriyenko <denys at ti.com> wrote:
> >
> > https://github.com/rvfh/meta-ti/commit/6342c03a0dba7d906db09630e57e2372998428df
> >
> > The recipe itself is quite trivial (I even had my own version in the works)
> > and I only have couple minor fixes around SRCREV and its comment... But have
> > you compared the defconfigs between those two patches? I know the first
> > version of your patch used completely different unofficial defconfig... And
> > you didn't specify which one you have in v2. I'd prefer to use the defconfig
> > that was validated by the GLP team. Thanks.
> 
> i would still prefer that we create a somehow minimalist defconfig, i
> don't think using the 'monster' ubuntu defconfig (it has hundreds of
> drivers enabled....) makes too much sense for meta-ti. we used that
> because it was simpler for now, but I would hold on that patch until
> we have a simpler config. in fact we have already a config in the tree
> called omap4plus_defconfig, we will base on that one instead.

Ok, I'm fine with that - we can work out a minimal config.


> also we should wait until we have GST and GFX up and running before
> merging the kernel, to avoid a couple of iterations.

I would prefer to have the new kernel ASAP for many reasons. There were 
several reports about 3.1 not booting for some people. So, resolving that 
before Yocto Project 1.3 is released, is quite important. Plus, this gets us 
aligned better with your current Ubuntu-based release. And we are now starting 
to see patches against the old 3.1 kernel - by moving everyone to newer 3.4 we 
avoid waisting people's time fixing and enhancing the old 3.1...

So, I'd vote to get the new kernel first and worry about GST and GFX later. Do 
you feel there will be extensive changes to the kernel recipe associated with 
those? A little bit of churn on the defconfig would be acceptable...

-- 
Denys