Date:	Sun, 06 Jun 2010 12:08:34 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Florian Mickler <florian@...kler.org>,
	Vitaly Wool <vitalywool@...il.com>,
	Brian Swetland <swetland@...gle.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Arjan van de Ven <arjan@...radead.org>, tytso@....edu,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration

On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
> On Sun, 6 Jun 2010, James Bottomley wrote:
> >
> >      3. We've lost sight of one of the original goals, which was to
> >         bring the android tree close enough to the kernel so that the
> >         android downstream driver and board producers don't have to
> >         choose between the android kernel and vanilla kernel.
> 
> There are two ways to do that w/o creating a dependcy on anything.
> 
> 1) merge the drivers w/o the suspend_blockers. It's not rocket science
>    to have a patch which brings them back for android.

Well, we sort of tried this when Greg pulled some of them into the
staging tree.  The problem is that without the annotations, the drivers
are still different, and patches won't apply, so, unsurprisingly, they
didn't get improved or even maintained.

> 2) merge the drivers with empty stub implementations for annotation.
>    android just has to patch in the real one.

That's also possible.  This time, we would have a cosmetically closer
tree ... however, what's in the kernel wouldn't be compilable for
android ... which is where all the downstream wants to test, so they'd
still be building for the android tree ... we just might have an easier
time of it picking up their fixes.

> While I'd prefer #1, I' not in the way of #2.

I think 1 is unviable ... I'm not opposed to 2 but I'd like to try to
get the kernel really closer to android before we go for the cosmetic
only option.

> Both ways can get the drivers into the kernel and it could/should have
> been done right from the beginning, but now we face a situation where
> drivers are held hostage.
> 
> Then we can sit down more relaxed and fix the stuff in a way which
> makes both sides happy. If we manage to replace them, we can deprecate
> the stub implementation and remove it after a grace period. If we
> rename them it's not an issue either. We can rename them right away to
> a qos interface, but that does not really make a difference.
> 
> What we really want to avoid is implementing an user space contract in
> a frenzy which binds us forever.

Well, that's why the QoS proposal ... it already has a userspace API ...
we'd just be extending it for statistics, which looks like a wothwhile
goal independent of android anyway.

> It's not the suspend_blockers which are the causing the nightmare,
> it's solely the drivers itself especially when there are different
> implementations in both trees. And frankly, the drivers in android are
> not in a shape which makes them flood in within 2 weeks. That's
> serious work to get them brushed up and polished. So that gives us
> quite a period of time to solve the suspend problem.

Right, so the sooner we make it easier for the drivers to use the kernel
as their main repository, the better.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists