On Thursday, April 28, 2011, MyungJoo Ham wrote: > On Wed, Apr 27, 2011 at 10:46 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > > On Wednesday, April 27, 2011, MyungJoo Ham wrote: > >> Hello, ... > >> Anyway, this happens with drivers/cpufreq also. We have been testing > >> "tickling" associated with drivers/cpufreq/cpufreq.c. This has been > >> reduced user response time significantly removing the need for tuning > >> the threshold values. > > > > I think I understand the problem, but I'm not sure if there's a clean way > > to trigger the "tickle" from the kernel level. > > I'm considering the followings (and they are not mutually exclusive). > How about them? > 1. (the way that we've been using) Add a tickle call to input events > at board file. Well, first, the input events may not be the only user of that feature and the GPU may not be the only target. So, there should be a way to specify multiple targets for each user and vice versa while keeping the drivers portable between platforms. That seems to be challenging. :-) Second, even if the input events were the only user and the GPU were the only possible target, it probably won't be necessary to "tickle" the GPU every time the touchscreen is used, only when the user is "scrolling", which input events really can't tell. The only entity having an idea about what the _user_ is doing is the application being used at the moment. > 2. provide sysfs interface that triggers tickling along with devfreq sysfs. That may be a better approach IMO, but making applications use it also will be challenging. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
