[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Rafael J. Wysocki on 14 May 2010 17:30 On Friday 14 May 2010, Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > > > On Thursday 13 May 2010, Tony Lindgren wrote: > >> * Rafael J. Wysocki <rjw(a)sisk.pl> [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. > > Distros (especially embedded ones) have long had out of tree features > that create barriers to getting other drivers upstream. While it > might be nice to see all those features upstream, no one has argued > that they should get merged simply because they create a barrier. Each > feature should be merged on its own technical merit. Well, this is very much like the selinux vs apparmour (& friends) issue. One can argue we need only one of them, but in fact we're not worse off having both in. The feature is not technically unacceptable to me and since having it in would potentially make it easier to merge quite a few drivers, I regard that as a good enough argument for. YMMV. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 14 May 2010 17:50 On Friday 14 May 2010, Kevin Hilman wrote: > Kevin Hilman <khilman(a)deeprootsystems.com> writes: > > > "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > > > >> On Thursday 13 May 2010, Tony Lindgren wrote: > >>> * Rafael J. Wysocki <rjw(a)sisk.pl> [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. > 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. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kevin Hilman on 14 May 2010 17:50 Kevin Hilman <khilman(a)deeprootsystems.com> writes: > "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > >> On Thursday 13 May 2010, Tony Lindgren wrote: >>> * Rafael J. Wysocki <rjw(a)sisk.pl> [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. 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. Kevin [1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025501.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kevin Hilman on 14 May 2010 18:50 "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > On Friday 14 May 2010, Kevin Hilman wrote: >> Kevin Hilman <khilman(a)deeprootsystems.com> writes: >> >> > "Rafael J. Wysocki" <rjw(a)sisk.pl> writes: >> > >> >> On Thursday 13 May 2010, Tony Lindgren wrote: >> >>> * Rafael J. Wysocki <rjw(a)sisk.pl> [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? >> 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. 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. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 14 May 2010 19:00
On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman <khilman(a)deeprootsystems.com> wrote: >>> 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. > > 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. It provides useful functionality -- you apparently disagree, but the wakelock/suspendblock model is in use, shipping, and solving problems for quite a lot of android devices that have been shipping for a while now. We actively go to lowest power state in idle (on omap, msm, etc), and use drivers that aggressively declock and depower modules (similar to runtime pm), but we have found that using the opportunistic suspend model combined with wakelocks allows us to attain even lower average power consumption in always-connected, actively-syncing devices. It has been claimed that because Android userspace makes use of this functionality a number of silicon vendors who want to submit code upstream are inconvenienced by having to maintain "android" and "mainline" versions of their drivers. I can't speak for them, since nobody has identified the particular inconvenienced vendors to me, nor have they spoken with me directly, but personally I do find that having to maintain two different versions of drivers (one version for upstream, one for shipping products) is inconvenient. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |