On 21 July 2014 22:30, Rob Herring <rob.herring@xxxxxxxxxx> wrote: > To me, but every time I suggest adding things to the topology the ARM > folks object... I really think we should have built the topology into > the /cpus hierarchy. Then we could add properties at the correct place > in the hierarchy where they are common. > > I don't really like the proposal here. It just doesn't look like a > clean description of the h/w. I knew it wouldn't be easy to get these bindings correctly in the first attempt atleast, but I still went for it so that this thread can progress: https://lkml.org/lkml/2014/7/18/3 There are changes waiting to get some kind of intermediate solution in, so that other platforms can reuse cpufreq-cpu0 driver. Also, so that cpufreq-cpu0 can be converted to cpufreq-generic, so that it can support almost any platform. Can you please reply to that thread to suggest some intermediate solution that we can get fixed in 3.17? Mvebu and Krait are waiting for these patches to get in.. The solution can be simple enough as right now we have only two kinds of platforms: - All CPUs share clock - All CPUs have separate clocks The most simple solution of that could have been a Kconfig entry, but that would be a problem for multi-arch builds if these platforms do want to get build with multi-arch config. Otherwise we have to get some binding in place for 3.17.. Please see if you can get that thread going :) > Ignoring compatibility, I would like to see something like > operating-points and/or the clock properties be moved up to /cpus if > they are shared and be per cpu node when they are not. This of course > does not work if you have independent OPPs for each cluster with a > shared clock within cluster. Yeah, that had always been the issue. People probably tried to get a cluster {} block as well to simplify that but there were some objections to it as well, though not sure what happened to that stuff.. -- 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
