> From: Hiroshi DOYU [mailto:[EMAIL PROTECTED] ... > > 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? If you need to do actions on individuals in the group you still need to grab handles for all of them. This puts you back where you started before exploring the idea. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
