Hi Richard, From: "ext Woodruff, Richard" <r-woodruff2@xxxxxx> Subject: RE: [RFC][DRAFT] TODO list for TI DSP BRIDGE Date: Thu, 21 Aug 2008 07:34:56 -0500 > > > From: Hiroshi DOYU [mailto:Hiroshi.DOYU@xxxxxxxxx] > ... > > > A few quick comments: > > > > > > - First off, I do like the idea of virtual clocks for grouping. I > > > did do this for OMAP2 for completely internal and dependent root > > > clocks. I also thought it might be nice to extend clock frame work > > > to allow external clock registration (say for a codec chip). In our > > > local tree I did even add it. One main issue was the internal clock > > > structure is supposed to be opaque and you need to set internals to > > > add a clock node. > > > > Can I find your OMAP2 implementation in omapzoom for virtual clock? > > Guess not. The flag for OMAP2 is still there in linux-omap clock.h > for virt_prcm_set but the implementation of it evolved to just using > custom recalc/rate/round functions. Today the flag just would tell > a user something is funny about the clock but no rules are enforced. > > Actually in looking at this does bring up another very relevant > question. > > For a combined clock especially like the IVA-system, how do you do > set_rate/round_rate/get_rate/set_parent so it is meaningful? > > For virt_prcm_set the MPU clock rate is used as in index. For OMAP2 > for most cases there are very strict rules about speed ratio's. As > such if you know the speed for 1 clock you can set the group. > mpu_rate isn't perfect but it is good enough. > > You need operations for more than enable/disable. > > How do you set parent to your timer in your example? How do you > query individual other clocks rate? I think that, in this virtual clock, frequency changing will be done in the totally different path(just in a normal clock tree). This virtual clock resides in an independent clock tree and supposed to be used aggressively just to turn on/off clocks(enable/disable), which drivers use, for saving power consumption. So the relationship between "clk" and "vclk" may be similar to "struct device" and "struct class" in the linux driver-model, which means that, the former is based on H/W connection and the latter is based on functionality. Of course there is a possibility that other clk methods can be overwritten, but it's has to be used for different purpose than a normal clock does, not to break the H/W clock tree consistency. Also, making a connection among virtual clocks(parenting) can be done by overwriting "set_parent" for vclk, which is original set NULL, if necessary. A virtual clock is composed of clocks which are called "child", but they are not children actually, from the clock framework point of view. These clocks reside in a H/W clock tree and a virtual clock just provide operation to handle them at once, from completely independent (virtual)clock (tree), for device driver. In the previous example, > dsp_clocks(v) > | > |-- peripheral_clocks(v) > | | > | |-- gpt5(v) > | | |- gpt5_ick(r) > | | `- gpt5_fck(r) > | > |-- .... > .. Virtually we can make the connection between "dsp_clocks", "peripheral_clocks" and "gpt5", if we overwrite set_parent for vclk. but there's no connection between gpt5(virt) and gpt5_*(real) from the clock framework point of view. (v) -> (v) OK (r) -> (r) OK (v) -> (r) NG : cause inconsistency on h/w clock tree. v: virtual clock r: real clock some flags can be used to prevent the above inconsistency. Probably original "virt_prcm_set" might have a wider solution, though.... 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
