Messages in this thread | | | From | "Turquette, Mike" <> | Date | Mon, 2 Apr 2012 10:30:29 -0700 | Subject | Re: [PATCH 2/2] clkdev: Implement managed clk_get() |
| |
On Mon, Apr 2, 2012 at 10:16 AM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Mon, Apr 02, 2012 at 09:48:31AM -0700, Stephen Boyd wrote: > >> I hope we get a better clk_get() implementation with the unified struct >> clk. Don't get me wrong, clkdev is a great improvement over open coding >> clock framework stuff in each platform. But clkdev is really just >> another platform specific implementation that most platforms decide to >> use. Each platform has to select the option and it breaks if two > >> Sticking devm_clk_get() into clkdev.c is simple, no new file, smaller >> diff. Great. But linking it to clkdev doesn't sound much better when >> we're trying to get rid of platform specific code and this code is >> entirely platform independent. > > Why wouldn't we want to continue to use clkdev with the generic clock > framework? There's nothing particularly wrong with clkdev and we need a > standard mechanism for doing this anyway. Frankly I was very surprised > when I looked just now and realised that the generic framework doesn't > use it automatically, I might just send a patch for that...
In the interest of getting merged I kept the common clk series as small as I could. It still came out much larger than the original patches, so you can see why non-critical bits like the above are missing.
I will take this opportunity to chime in and say that we can improve clk_get. I'd personally like to see clk_get return an opaque cookie that is per-device. This will really help out the clk_set_rate case where we want to start managing multiple different drivers which might invoke a set_rate on the same clock (which is increasingly more likely now that we can propagate rate change requests up to shared parents).
So essentially clk_get(dev, con_id) would return a random u32 (or maybe not random... maybe generated from a hashing function or whatever), and all further clk_* ops would use that id. Thus the common clk framework would know exactly which driver was calling any given function.
The above suggestion is not critical for single dimensional operations such as clk_(un)prepare and clk_enable/clk_disable. Use counting is adequate. Tracking driver requests is very useful for two-dimensional calls like clk_set_rate, where we might want to keep a plist of rates that drivers had requested so that clk_set_rate is no longer a He-Who-Writes-Last-Wins affair.
/me dons flame-retardant suit.
Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |