2010/8/5 Rafael J. Wysocki <rjw@xxxxxxx>: >> >> Our wakelock stats currently have >> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time >> and last_change. Not all of these are equally important (total_time is >> most important followed by active_since), but you only have count. >> Also as discussed before, many wakelocks/suspendblockers are not >> associated with a struct device. > > OK > > How much of that is used in practice and what for exactly? > > Do you _really_ have to debug the wakelocks in drivers that much? Debugging power related issues is pretty critical to building competitive mobile devices. Throughout the several months of this discussion I have been continually scratching my head at this "debugability considered harmful" attitude that I see in reaction to our interest in having the ability (gated behind a config option even -- really, that'd be fine, not everyone need enable it) to gather useful stats and examine the state of the system. At this point it sounds like there's no interest in the solution we have, which works and has worked for a few years, and has been revised 10+ times based on feedback here, and no interest in providing a solution that accomplishes similar functionality, so perhaps it's time for us to cut our losses and just go back to maintaining our patches instead of having the same arguments over and over again. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
