Hi, > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley > between omap_clk_associate() and vclk, my preference is for the > omap_clk_associate() approach. > > The core problem is that the vclk patches create clocks with multiple > parents in a way that is hidden from the clock framework. This causes > both semantic and practical problems. > > Semantically, the patches cause the meaning of set_rate() and set_parent() > to be confused, and any driver that wants to call set_parent() or > set_rate() on those clocks will need to have their own custom functions > for those operations. I'd like to keep the amount of that custom code > minimized. I agree and these mirror my comments when it was first proposed. Having a virtual node does however have some benefits which may be worth exploiting for future. For these types of nodes it might be they just return an error if someone tries to use them. Or have some way to get its attributes. When you do allow a set rate on a virtual clock it will have to be custom. There may be a number of valid internal combinations. Providing a "clock-cluster" OPP table is probably enough. Regards, Richard W. -- 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
