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

[Rafael J. Wysocki]

On Saturday 15 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@xxxxxxx> writes:
> 
> > On Friday 14 May 2010, Kevin Hilman wrote:
> >> Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes:
> >> 
> >> > "Rafael J. Wysocki" <rjw@xxxxxxx> writes:
> >> >
> >> >> On Thursday 13 May 2010, Tony Lindgren wrote:
> >> >>> * Rafael J. Wysocki <rjw@xxxxxxx> [100513 14:16]:
> >> >
> >> > [...]
> >> >
> >> >>>  
> >> >>> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved
> >> >>> > differently, while there's a growing number of out-of-tree drivers depending
> >> >>> > on this framework.  We need those drivers in and because we don't have any
> >> >>> > viable alternative at hand, we have no good reason to reject it.
> >> >>> 
> >> >>> Nothing is preventing merging the drivers can be merged without
> >> >>> these calls.
> >> >>
> >> >> And yet, there _is_ a growing nuber of drivers that don't get merge because
> >> >> of that.  That's _reality_.  Are you going to discuss with facts, or what?
> >> >
> >> > It may be reality, but IMO, "preventing other drivers" isn't a good
> >> > *technical* argument for merging a feature.  It feels like these "for
> >> > the 'good' of the community" arguments are being used to trump the
> >> > technical arguments.  Maybe we need to keep the separate.
> >> 
> >> To continue along the "for the good of the community" path...
> >> 
> >> 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.

> >> Then we would see how many drivers get submitted and merged.
> >>
> >> Personally, I suspect that lack of this feature is not the real
> >> obstacle to getting these out-of-tree drivers upstream.  Having this
> >> API upstream will not change the product schedules and corporate
> >> cultures that have prevented code from making its way upstream.
> >
> > But apparently it is considered as a suitable excuse.
> 
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.

I didn't mean that, actually.  What I wanted to say is that people use the
lack of "wakelocks" in the mainline as an excuse not to push their drivers
upstream (which is kind of understandable, because there's a zero benefit to
them from mainlining their code, as they will have to maintain a separate
"Android" version of it anyway).

Sorry for the confusion.

> 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.

So, let's not just easily generalize, please.

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

First, I think it is a legitimate approach to power management, whether you
like it or not.  I haven't seen anyone seriously arguing against that yet.

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).

Next, the only thing the Arve's patches do is to give people an _option_ to use
opportunistic suspend if they need it or want it.  It's not mandatory and not
even enabled by default, so I don't really see what the problem is.  Quite on
the contrary, I'd like people to be able to use the mainline on Android systems
without major modifications, because potentially that can increase our tester
base (and developer base too in consequence) and including opportunistic
suspend in the mainline would be a step in that direction.

Finally, it appears to address some issues that at the moment we don't
seriously know how to address in a different way.

Thanks,
Rafael

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