On 4 February 2013 18:34, Borislav Petkov <bp@xxxxxxxxx> wrote: > On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote: >> What i believe is, the place where this directory was present earlier >> (cpu/cpufreq/) wasn't the right place. Everything else was in cpu/cpu*/cpufreq, >> then why this in cpu/cpufreq/ ? > > For the simple reason that the "cpu*" stuff is per-cpu - the > "cpu/cpufreq" is per system, i.e. one governor for the whole system. That's not completely true. There lies cpufreq directory in cpu/cpu*/ too, where we have per policy stuff in cpu/cpu*/, like policy tunables and stats. And the same is true for governor too. >> I don't know how much of a pain it would be to fix userspace for it, >> but i know it wouldn't be that small. > > I wouldn't fix userspace but simply not touch it. You can add your > per-policy stuff in "cpu/cpu*" as new sysfs nodes and no need to > change anything. That was slightly confusing to me :( The whole governor directory is per policy, i have to keep that in cpu/cpu*/cpufreq instead of cpu/cpufreq . > And, also, as I suggested earlier, you should make it > configurable since this code wouldn't make sense on x86, for example, > where one system-wide governor should suffice. Its not only for multicluster system, but a system where multiple cpus have separate clock control and hence multiple policy structures. >> I had another idea of doing this only for platforms where we have >> multiple struct policy alive at the same time. But didn't wanted to >> implement it before discussing this further. > > Simply put it behind a config option like > CONFIG_CPU_IDLE_MULTIPLE_DRIVERS, call the whole menu > "Multi-power-domain-policy" something and that should be modulary > enough. Problem with this is it would fail for single image solutions on which everybody is working on. So, with multiple platforms compiled into a single image, this wouldn't work. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html