lkml.org 
[lkml]   [2010]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
    From
    Date
    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.



    \
     
     \ /
      Last update: 2010-05-17 04:49    [W:4.149 / U:1.396 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site