On 08/07/2013 11:54 AM, Viresh Kumar wrote: > On 7 August 2013 23:18, Stephen Warren <swar...@wwwdotorg.org> wrote: >> On 08/07/2013 11:45 AM, Viresh Kumar wrote: >>> On 7 August 2013 23:08, Stephen Warren <swar...@wwwdotorg.org> wrote: >>>> On 08/07/2013 08:46 AM, Viresh Kumar wrote: >>>>> This patch adds CPU0's clk driver for Tegra. It will be used by the >>>>> generic >>>>> cpufreq-cpu0 driver to get/set cpu clk. >>>>> >>>>> Most of the platform specific bits are picked from tegra-cpufreq.c. >>>> >>>> Hmmm. I'm not sure if it makes sense to represent this as a clock >>>> object; isn't this more of a virtual construct that manages the rate of >>>> the clock, rather than an actual clock? The actual clock already exists >>>> as "cpu". >>> >>> I see it as this: There is a clock in system for cpu, call it "cpu". Now we >>> must be able to provide get/set routines for it. A set should set the >>> frequency to whatever is asked for and should really worry about how >>> that is being set. This part is internal to "cpu" clk. >> >> Sure. >> >>> This is what cpufreq-cpu0 driver should expect and does. Current "cpu" >>> clock implemented doesn't provide this facility ? And so this wrapper >>> made sense to me. >> >> But the additional management logic on top of the raw clock is exactly >> what the cpufreq driver is for. This patch series is basically moving >> the cpufreq driver code inside the clock code instead. > > Above "sure" didn't go very well with what you wrote here :) > > The additional management that we are required to do isn't cpufreq > driver specific but cpu or platform specific.
Right, and that's *exactly* what having a cpufreq driver is for; to implement the details of CPU clock management. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
