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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
