Hi Richard, From: "ext Woodruff, Richard" <r-woodruff2@xxxxxx> Subject: RE: [RFC][DRAFT] TODO list for TI DSP BRIDGE Date: Thu, 21 Aug 2008 14:43:34 -0500 > Hi Hiroshi, > > > -----Original Message----- > > From: Hiroshi DOYU [mailto:Hiroshi.DOYU@xxxxxxxxx] > > <snip> > > > 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. > > Ok. I 'think' I better understand your idea. Thanks for the description. > > To me it seems like it could be slightly confusing to maintain 2 > clock structures. One for v and one for p. In the end it is > probably not very hard to lean. > > It would reduce some amount of code in the more complex > subsystems/drivers resulting in a cleaner driver. > > The interface used in drivers with the clock frame work is pretty > simple so it might seem more about clean up then reducing complexity > in the driver. > > Do you feel a lot of drivers will benefit or it will expand to auto > handle resources better? If it is just 1 or 2 drivers then it might > be the new code in clock framework and platform will add some > complexity which is higher than what was removed from the driver. > If lots of drivers use it then it would be positive. I have no idea right now about how much drivers and the feature evolution. But basically I feel positive because for now this won't affect the existing clock tree(or framework) at all and this is just a helper function for driver's clock initialization and can be considered as a kind of independent add-on feature from the clock framework perspective. I agree that there is a possibility that some smart guy can extend this to handle all device driver related resources(platform dependent?) together. 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
