Hi, 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. In practical terms, the vclk code will cause spinlock recursion bugs like the ones that currently exist with the McBSP driver: http://marc.info/?l=linux-omap&m=122310205615940&w=2 since vclks will call clk_enable()/disable()/set_rate()/etc. inside the clockfw_lock spinlock. Using the vclk patches also means that the number of custom clocks will explode, as each driver is likely to define at least one custom clock. [ eventually, we'll need to deal with the multiple parent issue, if for no other reason than to fix usecounting for clocks like dss_ick. But it will need to be handled by the clock framework code itself. And this problem is pretty low on the priority list... ] So between the two, I'd like to see omap_clk_associate() integrated. I have some comments to post on Felipe's code; once those are addressed, hopefully we can merge it. - Paul -- 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
