On 18 July 2014 06:32, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >> > only support the following cases: >> > >> > * One clock for all CPUs >> > * One clock for each CPU >> >> Yeah, so I also proposed this yesterday that we stick to only these >> two implementations for now. And was looking at how would the >> cpufreq-generic driver come to know about this. >> >> So, one way out now is to see if "clocks" property is defined in >> multiple cpu nodes, if yes don't compare them and consider separate >> clocks for each cpu. We don't have to try matching that to any other >> node, as that's a very bad idea. Mike was already very upset with that :) >> >> @Stephen/Rafael: Does that sound any better? Ofcourse the final thing >> is to get bindings to figure out relations between CPUs.. > > Before I apply anything in this area, I need a clear statement from the ARM > people as a group on what the approach is going to be. Thanks for your response Rafael. Mike/Rob/Stephen: I believe Atleast three of you should express your views now :) So, this is what I propose: - I will start another thread with a new DT binding, something like: "clocks-ganged" = <&cpu0> and then we can decide on naming/etc .. - I will drop the patch which matches clock nodes from DT and introduce another one that will just check if "clocks" is mentioned in more than one CPU. If yes, then we behave as if all CPUs have separate clock lines. That will work for Krait/mvebu and all existing users. Does that sound good? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
