Re: [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday, April 28, 2011, MyungJoo Ham wrote:
> On Wed, Apr 27, 2011 at 10:46 PM, Rafael J. Wysocki <rjw@sisk.pl> 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