Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Sat, 2010-05-15 at 22:14 +0200, Rafael J. Wysocki wrote:
> On Saturday 15 May 2010, Kevin Hilman wrote:
> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> > > On Friday 14 May 2010, Kevin Hilman wrote:

> > >> If it truly is the lack of a suspend blocker API that is preventing
> > >> the merge of these out of tree drivers, I second Mark's proposal[1] to
> > >> merge a noop version of the API while the technical issues continue to
> > >> be discussed.

> > > I'm against that, sorry.

> > OK, I'll bite... Why?

> Because in that case the real feature will always be opposed as "unnecessary"
> and never merged.  I very much prefer to decide whether to merge it or reject
> it right now.

FWIW (as the person who made the suggestion) I do think that it is
something one might call expedient rather than actually good.

> > It was expressed because I find the arguments above for merging
> > because it prevents out-of-tree drivers from merging quite
> > unconvincing.  This is not just about opportunistic suspend + suspend
> > blockers specifically but comes from several years experience in the
> > embedded Linux world.

> In this particular case, the lack of the mainline's support for opportunistic
> suspend (in the form of "wakelocks" to be precise) has been given as a main
> obstacle against merging of several drivers at least.

Where are these objections coming from? The only example I've seen cited
is the G1 stuff, which is a fairly special case for a number of reasons
(including the underlying MSM BSP, which was pretty substantial itself).

> And this is not the only reason to push the opportunistic suspend feature
> upstream IMO.

Agreed, my purpose here is mostly to push back on what sound like
unrealistic expectations about what we're getting.

> Second, (as said above) there is a number of drivers _already_ depending
> on it and that number is only going to grow given the popularity of Android.
> They are not mainlined in part because their authors don't see a benefit from
> doing so (usually the benefit is that you don't have to maintain your code out
> of the tree, because the mainline does it for you to some extent, so if you
> need to maintain a separate version yourself, the benefit is zero).

Wakelocks are going to be a fairly minor part of any decision here -
it'd be pretty surprising if they take much effort to remove from a
driver. What's much more of an issue is that you've got essentially the
same situation as you have with the enterprise Linux distributions, a
fixed kernel version that vendors need to target. The differences that
implies are far more substantial than wakelocks for many areas of the
kernel, especially at the points in the cycle where the fixed kernel has
drifted furthest from the current mainline.

Things aren't quite the same as with the enterprise distributions,
though - the lifecycles for many parts in the consumer space are much,
much shorter than those in the enterprise markets. They can be
sufficiently short to mean that a mainline driver won't show up where
customers need it soon enough. For example, Google is currently
preparing an Android release based on 2.6.32 the merge window for which
was in September last year, over six months ago. This is an extremely
long latency if you're working on something in the region of a twelve
month cycle. The lack of standardisation for register interfaces in the
embedded space means that the generation to generation differences can
easily be sufficiently substantial to make a new driver the only
sensible option.

This isn't to say that the old parts just suddenly vanish, and clearly
there's an advantage from ongoing mainline inclusion, but the tradeoffs
are a bit different to those in other markets.

There's also a less pressure from end users towards mainline inclusion -
even on Linux people in the embedded space are used to having to get
code from multiple vendors working together so the lack of mainline
support isn't the sort of issue it would be with something like server
class hardware. This is changing over time as more and more vendors buy
into mainline but there's a way to go yet. If the part requires changes
outside the driver itself (a new or updated kernel interface, for
example) there's a pressure to just deal with it in the driver in a way
which is going to be unacceptable for mainline, possibly even involving
per-system code modifications in the driver. Sometimes ongoing mainline
development will mean that the driver needs updating anyway in ways that
are much more substantial than ripping out wakelocks would be.

Having wakelocks in does make things easier for drivers using them but
we need to recognise that all sorts of other things that are much harder
to deal with will also come up.