On 10 September 2014 11:59, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: > A compile time conditional does not work, as it isn't compatible with > multiplatform: what if in the same kernel you want to support two > platforms that use cpufreq-dt, one having a single clock for all CPUs, > and one having one clock per CPU. Yeah, that's a known problem. Should have mentioned this in logs. > I'm still confused as to what is the problem with the DT binding > surrounding this driver. Isn't it simply a matter of adding a clocks = > <...> property to all CPUs, and that's it? > > Viresh told me there was an issue related to comparing the clocks in > the driver to find out which CPUs share which clocks. But that is not a > DT binding issue, it's an implementation detail. Since the driver is > purely for DT platforms (as its name suggest), comparing phandles could > work as a temporary solution. And since it's just an implementation > detail that doesn't affect the DT binding, we could change the > implementation later to use a proper clock API like clk_is_same(clk1, > clk2) that would tell us if the clocks are the same. > > But I have probably missed some of the complexity of this. (Couldn't give you these links yesterday as I was done for the day and was replying from my phone (In our private chat)) https://lkml.org/lkml/2014/6/26/577 https://lkml.org/lkml/2014/7/1/565 https://lkml.org/lkml/2014/7/3/813 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275520.html So these are few mails I could pick, specially from Mike, where he pointed out why getting a clk-API for this is a bad idea. -- 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
