On Thu, Oct 02, 2008 at 01:50:02PM -0700, David Brownell wrote: > 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? in that case, clk_associate (or clk_add_alias like in pxa) would be needed to associate the device with the struct clk, right ? > 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. in this case I think clk_associate would fail. Same for anything else that "hides" the device pointer from board-files. > 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 problem with names for omap is that it's useful to name the clock with the same name we see in TRM to ease the search (it's +3k pages manual, anything to make searching easier is valid :-) but then again, clk names changes among omap versions. So an alias (or function) name would help us keeping the correct clk name in the header files and yet have a standard/simpler name for drivers to use, like "mmc interface clock" (mmc_ick) and "mmc functional clock" (mmc_fck). No matter if it's omap1/2/3/... we could keep the function name the same while clk name refers to TRM. > 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. that's true. We need a logical and rather stable (I'm referring to clk names here) view of the clk tree so drivers don't have to care anymore about different clk names. Having to add cpu conditional code in the driver just because of a different clk name doesn't sound doable anymore neither passing an extra char * to the driver via pdata. -- balbi -- 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
