On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
