On Thu, Aug 4, 2011 at 3:33 AM, Kevin Hilman <khilman@xxxxxx> wrote: > MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> writes: > >> On Wed, Aug 3, 2011 at 7:02 AM, Kevin Hilman <khilman@xxxxxx> wrote: > > [...] > >>> Maybe I'm not understanding the usage of it fully, but that seems like >>> hard-coding policy into the framework that might not be appropriate. >>> For example, what if there are other devices with constraints such that >>> they cannot currently scale frequency/voltage? >>> >>> Mabye MyungJoo can explain in more detail the usecases for tickle? >> >> Tickle is not for QoS between devices. It is for faster reaction to >> (human) user inputs at DVFS side where waiting for DVFS's reaction >> takes too much time and reducing polling interval costs too much. > > This is exactly what quality of service (QoS) is about. > > The user (whether it's a human user input or another device) has low > quality and expects higher quality. It wants to request better quality, > so it needs a way to request it. > > The proposed "tickle" approach proposed here is simply a "request max > frequency for duration X" QoS request. > > Kevin > Ok.. I see. Now, I can agree with you that tickle is subset of QoS request. As long as we have QoS request feature on devices with either OPP or DEVFREQ, tickling is not needed. I'll remove tickle in the next revision (along with some bugfixes for bugs found recently). Anyway, it appears that clock-rate-wise QoS request may be dealt at OPP so that the OPPs meeting the QoS requests w/ frequency or voltage specifications are enabled and returned with opp_find_* functions. Maybe we will need to separate enable/disable by opp_enable()/opp_disable() from enable/disable by QoS requests so that the two may have different semantics. Then, QoS requests cannot override opp_disable and opp_enable cannot override QoS requests. This way, any clock-setting code properly based on OPP (including any customized devfreq governors) cannot violate QoS requests. How about this concept of getting QoS requests associated with clock rates? Cheers! MyungJoo. -- MyungJoo Ham, Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
