On Thursday, January 21, 2016 10:49:58 AM Juri Lelli wrote: > [+Punit, Javi] > > Hi Rafael, > > On 21/01/16 02:46, Rafael J. Wysocki wrote: > > On Wednesday, January 20, 2016 05:39:14 PM Steve Muckle wrote: > > > On 01/20/2016 05:22 PM, Rafael J. Wysocki wrote: > > > > One comment here (which may be a bit off in which case please ignore > > > > it). > > > > > > > > You seem to be thinking that sched-freq needs to be a cpufreq governor > > > > and thus be handled in the same way as ondemand, for example. > > > > > > That's true, I hadn't really given much thought to the alternative you > > > mention below. > > > > > > > > > > > However, this doesn't have to be the case in principle. For example, > > > > if we have a special driver callback specifically to work with > > > > sched-freq, > > > > it may just use that callback and bypass (almost) all of the usual > > > > cpufreq mechanics. This way you may avoid worrying about the governor > > > > locking and related ugliness entirely. > > > > > > That sounds good but I'm worried about other consequences of taking > > > cpufreq out of the loop. For example wouldn't we need a new way for > > > something like thermal to set frequency limits? > > > > I don't know from the top of my head, but that's at least worth > > investigating. > > > > Yes, that's an interesting alternative that we have to think through. > > > Maybe we can keep the interface for those things unchanged, but handle it > > differently under the hood? > > > > Let me see if I understand what you are proposing :). If we don't want > to duplicate too many things, maybe it is still feasible to just use > existing cpufreq mechanics to handle hotplug, sysfs, thermal, etc. (with > possibly minor modifications to be notified of events) and only create a > new method to ask the driver for frequency changes, since we will have > replicated policy and freq_table information inside sched-freq. Is that > what you were also thinking of by saying "bypass (almost) all the usual > cpufreq mechanics"? :)
Yes, it is. Thanks, Rafael
