Shared publicly  - 
Well, imx-drm is going to have to wait another three months or so before it can be sorted out.  Along with armada-drm, and the rest of the madness.  Greg has closed his tree and so the componenised device support is stuck out of tree.

Meanwhile, the ASoC problems continue - after a month or so of pestering and reminders, Liam has finally cleaned up and submitted his DPCM patches, but never copied me with them.  So the kirkwood DPCM patches also aren't going to make 3.14.

And mainline folk wonder why people in the embedded world end up maintaining their own kernel branches outside of mainline - it's because getting stuff into mainline is ABSOLUTE HELL, and by the time they've jumped through all the hoops, the hardware for which the patches were relevant has become OBSOLETE.

Yes, the community folk supporting the Cubox platforms (now both Kirkwood and iMX6) have decided to setup a github account where they can merge this kind of work, beacuse they're soo sick to death of this stuff.  Yes, another tree where code can linger outside of mainline rather than being merged into mainline.  PRECISELY and DIRECTLY as a result of this lack of forward progress.
Greg Kroah-Hartman's profile photoRussell King's profile photoNanik T's profile photo
It's a few days before 3.13 is released, I sure hope you wouldn't take a huge patch set like this one this close to the opening of the merge window for your kernel trees.
It would be nice if you could take the one introducing the core componentised device support, since there's been interest for its use by other people.

That way, people can base their work on it from v3.14-rc1, rather than having to carry a patch adding it in their own tree, or delaying work until the following merge window.
+Greg Kroah-Hartman BTW, as for "a few days", that's incorrect unless Linus has changed his plans since the -rc7 announcement:

"But rather than do a real 3.13 next weekend, I'll be on the road and decidedly not opening the merge window, so I'll do an rc8 next week instead, needed or not."

Yes, I know the original posting on the 2nd January was rather late in the cycle (I couldn't have posted it earlier, but doing so would've taken out my resource crippled outgoing MTA, and over the Christmas vacation I've had an ongoing fight with my ISP to deal with - one which continues to date, and is the reason for my current signature to highlight what a joke fibre based Internet really is here.)
Ok, patch now applied to my tree, sorry, I thought 3.13 was this weekend, I forgot about the -rc8 stuff.

As for how to get stuff upstream quick enough, patches should be submitted before the hardware is public.  I have a whole talk about this thing, and how successful companies are already doing this really well.  If you wait until after the hardware is out, it's way too late, and you will run into the issues you are facing with new hardware being available before the patches are merged.

But this is just preaching to the choir, you all know this quite well :)
+Greg Kroah-Hartman Thanks for applying.

It would be nice if that were possible.  I had the imx6 hardware just before kernel summit, and that's when I started work on it.  I had the initial DT support in place, but it's taken until this coming merge window just for the basics to be queued up due to issues with the device tree, Kernel summit, and the timing of the following merge window.  In the time that its taken for one kernel cycle, the final product has now been released using... a 3.0.35 freescale kernel.

There's people running around desperately trying to get more recent kernels running (with full hardware support), most of those efforts are against a 3.10 kernel though.

I'm one of the very few (the only I think) who's putting any effort into pushing this stuff upstream.
Add a comment...