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'. If clk_get(dev, alias) keys on "dev", then that could seem to be an alternate implementation strategy. Does it? I've not been tracking the evolution of the OMAP clock tree code, but the treatment of "dev" seems quite indirect. It doesn't seem possible, for example, to stick a programmable clock onto a non-platform device ... even when that's the relevant input to, for example, some external CODEC. > I think that the point here is how to __hide__ the real detail clock > information(names, numbers, functionalites and so on) from client > device drivers. That's one way to look at it. Hiding is not the requirement though; I have no problem if they can see that information. (Not that the clock interfaces support querying by any scheme more intelligent than looking up all possible names!) The requirement is instead to provide a portable "logical" view of the clock tree ... it doesn't matter if a "physical" view is available too, or even that both models exist. > 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. - Dave -- 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
