On 09/02/16 15:54, Dietmar Eggemann wrote: > On 05/02/16 09:30, Juri Lelli wrote: > > On 04/02/16 16:46, Vincent Guittot wrote: > >> On 4 February 2016 at 16:44, Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote: > >>> On 4 February 2016 at 15:13, Juri Lelli <juri.lelli@xxxxxxx> wrote: > >>>> On 04/02/16 13:35, Vincent Guittot wrote: > >>>>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli@xxxxxxx> wrote: > >>>>>> Hi Vincent, > >>>>>> > >>>>>> On 04/02/16 13:03, Vincent Guittot wrote: > >>>>>>> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen@xxxxxxx> wrote: > >>>>>>>> On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote: > >>>>>>>>> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli@xxxxxxx> wrote: > > [...] > > >>> > >>> AFAICT, They don't have a dedicated cpufreq driver. > >>> > >>> More generally speaking, it can take time before having > >> > >> email sent before the ne d of the sentence ... > >> > >> More generally speaking, it can take time before having a cpufreq > >> driver whereas we want to run and test scheduler behavior of these > >> heterogenous platform > >> > > > > I'm not familiar with this platform, but from what you are saying and > > what I could find online, it looks like full Linux support is not > > finished yet. Can we consider that as still in development? And if we > > can do that, maybe is fair enough that we use the sysfs interface to > > play with that platform until support is complete. > > > > Do others have any opinion on this point? > > IMHO, the solution should work for all of heterogeneous systems, (a) w/ > cpufreq and driver, (b) w/ cpufreq and no driver loaded (yet) or (c) w/o > cpufreq. > > That means that you can't put the benchmarking only into > cpufreq_register_driver() and rely on cpufreq policy topology. > > Maybe you could do this for (b) and (c) inside an initcall and use > topology_core_cpumask() to figure out which cpu to profile? > > This would then happen w/ the cpu frequency set by the fw. > > But this then has to be synchronized somehow with the benchmarking > approach in cpufreq_register_driver(). > Yes, I guess the tricky situation is the mixed one, when we might have the benchmarking executing in a late_initcall when cpufreq kicks in. Or we can also end up doing the benchmarking twice if cpufreq finishes initialization after the late_initcall has been executed. I'm not sure how this can be solved in a clean way. Ideally we would start benchmarking in the late_initcall (at the frequency set by fw) and then bailout if cpufreq kicks in. That should work also for the cpufreq driver as a module case. But, we could do the same thing twice if the late_initcall is faster or gets executed before cpufreq starts to be initialized. Any suggestion anyone? :) Best, - Juri -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
