On Wed, May 14, 2014 at 8:18 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote: >> On 14 May 2014 18:41, Heiko Stübner <heiko@xxxxxxxxx> wrote: >> > Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: >> >> On 14 May 2014 18:20, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> >> > Could we please come up with a way to probe this from DT in the >> >> > cpufreq-cpu0 driver itself, so we don't have to add a device in every >> >> > platform using it? >> >> >> Its followed that way because DT Maintainers had strong objections >> >> to creating virtual device nodes and haven't allowed creation of nodes >> >> for cpufreq drivers.. For which there is no physical device, as CPU already >> >> has a separate node.. >> > >> > as we already have the "enable-method" property for enabling/disabling cpus, >> > would something like a "scaling-method" be feasible? > > Good idea to put it as a property into the CPU node. We already have properties which indicate this driver can be used by a platform: opp table and a clock for the cpu. If this information is not sufficient to determine whether you can use this driver or not, then you simply need to match against the platform. Perhaps the match list should be a blacklist rather than a whitelist, so new platforms work without a kernel change. Alternatively, create a new OPP binding that addresses this and all the other limitations in the current OPP binding. >> Lets see what DT maintainers have to say on this, I would rather go for a >> more straight forward name: "scaling-driver" .. > > Both sound fine to me. The fact that linux needs a way to create a platform device to enable a certain driver is not a DT problem. I proposed a solution for how to get this out of the platform code [1], but evidently we want people to open code the exceptions and adding boilerplate helpers will just encourage the exceptions. Rob [1] https://lkml.org/lkml/2013/10/30/30 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |