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(). [...] -- 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
