On Wed, Aug 03, 2011 at 11:54:01AM -0500, Rob Herring wrote: > On 08/03/2011 11:41 AM, Jamie Iles wrote: > > On Wed, Aug 03, 2011 at 11:29:16AM -0500, Rob Herring wrote: > >> On 08/03/2011 04:50 AM, Jamie Iles wrote: > >>> I'm trying to work out how our cpufreq driver fits in with device tree > >>> bindings. We have a simple driver that just takes a struct clk and > >>> calls clk_set_rate() on it. Is a node in the device tree the right way > >>> to do this as it isn't really a physical device? I have the PLL in the > >>> clocks group of the DT: > >> > >> Sounds generically useful... > > > > Yes, once I've got it working internally I'll submit this as a generic > > thing for drivers/cpufreq. > > > >> The OF clock bindings are not really completely finalized and work on > >> the OF clk code is basically blocked waiting on the common struct clk > >> infrastructure. > > > > OK, so for the platform I'm working on mainlining at the moment does > > that mean I should leave the clock bindings for now or is that something > > that can be revised at a later date? > > > I'm separating it out for mine and just doing limited clk implementation > now based on the rate common struct clk is going. > > There's a 3rd option. Implement DT clk binding parsing and clk node > creation within your platform. Perhaps the struct clk details could be > abstracted out from the binding parsing code so some could still be common.
OK, that sounds like pretty much what I have at the moment. I have a struct clk and struct clk_ops then separate binding parsers so it should be fairly easy to port over. I'll post some patches after the merge window closes. Thanks, Jamie _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
