Hi David, From: "ext David Brownell" <david-b@xxxxxxxxxxx> Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate Date: Thu, 2 Oct 2008 13:50:02 -0700 > On Wednesday 01 October 2008, Hiroshi DOYU wrote: > > Or, this feature itself can be covered by 'virtual clock(vclk)'? > > > > http://marc.info/?l=linux-omap&m=122066992729949&w=2 > > > > which means that, > > in this case, if 'vclk' just has a single child, not multiple, it can > > be used just as 'aliasing' of clock names, without touching the > > contents of 'struct clk', since 'vclk' is a inhritance of 'struct clk'. > <snip> > > > Some driver may need to control multiple clocks at > > once. Some may need a clock which has different names between omap1, > > omap2/3 or target boards. Or some may need to control multiple clock > > groups from the functional perspective. So I think that a *flexible* > > infrastructure would be better to afford such requiments, keeping > > 'struct clk' as simple as possible. > > That vclk stuff looked a bit less obvious than I like. > Maybe I just haven't seen the need for those particular > flavors of flexibility. I've looked around for some examples;). For this abstruction (or logical clock view), one of the case which clk_associate doesn't deal with is to handle multiple clocks together. There are some cases, where multiple clocks are handled(enable/disable) at once as below: drivers/usb/gadget/omap_udc.c: omap_udc_enable_clock() drivers/video/omap/rfbi.c: rfbi_enable_clocks() arch/arm/mach-omap2/mcbsp.c: omap_mcbsp_clk_enable()*1 arch/arm/mach-omap2/serial.c: omap_serial_enable_clocks() sound/arm/omap/eac.c: eac_enable_clocks() With vclk, all the above home-brewed functions, *_enable_clocks(), can be replaced by a normal clk_enable(), with grouping the logical set of clocks in advance. For some of the above drivers, omap's "functional clock" and "interface clock" doesn't make sense. For such device drivers, those clocks may look just a single necessary clock and there's no "one to one" correspondence from the omap clock functionality definitions ("ick"/"fck") perspective. I think that this is one of the examples, where the flexibily is required. Since required functionaliies for clocks depends on each device drivers, I think that it would give a wider solution to let device drivers to define their logical clocks(functionality) flexibly(not 1-to-1), rather than statically pre-defined standardized functional names, which is the 1-to-1 correspondence of ick and fck in the TRM with aliasing. But I agree on that 'vclk' is too flexible and I think that's why Paul hasn't taken it yet;) *1: http://marc.info/?l=linux-omap&m=122066992729951&w=2 Hiroshi DOYU -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
