> Prepare devfreq core framework to support devices which > can idle. When device idleness is detected perhaps through > runtime-pm, need some mechanism to suspend devfreq load > monitoring and resume when device is back online. Present > code continues monitoring unless device is removed from > devfreq core. > > This patch introduces following updates, > > - move device load monitoring logic to ondemand governor as > it is specific to ondemand.
We have this ondemand governor in the mainline devfreq. However, we have (not upstreamed yet) governors with specific purpose (for GPU or for a specific chip) with load monitoring logic. Although we don't have them upstreamed yet, why don't you keep the monitoring logic sharable by other governors. (From today, I'm not objecting to have individual workqueue, but I still don't want to let each active governor reimplement the same things.) > - devfreq core interacts with governors via events to perform > specific actions. These events include start/stop devfreq, > and frequency limit changes outside devfreq. This sets ground > for adding suspend/resume events. event_handler with START/STOP/UPDATE seem fine. However, init() and exit() should be different from START/STOP. We do not need to do init and exit every time when we do runtime suspend/resume. > - use per device work instead of global work to monitor device > load. This enables suspend/resume of device devfreq and > reduces monitoring code complexity. It's fine to have a delayed work struct per device. However, please try to keep as many things/features in devfreq.c as possible; i.e., reduce features and code size of governors. Because, we will be supporting various types of devices with devfreq, there will be various governors and I don't want them to have shared things reimplemented. Dealing with the delayed work at devfreq.c and let governors choose to use it (at its struct) or not should be fine. In this patchset, the size of ondemand governor has been enlarged too much for that purpose. > - Force devfreq users to set min/max supported frequencies in > device profile to help governors to predict target frequecy > with in limits. Is this really necessary? > > The devfreq apis are not modified and are kept intact. The ABIs are not. You can no longer do "# echo 0 > ABI_path" in order to deactivate. Cheers! MyungJoo > > Signed-off-by: Rajagopal Venkat <rajagopal.ven...@linaro.org> > --- ps. please make the patch a bit more readable. (please don't shuffle the location of pre-existed functions) _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
