Hi Mike, On Thursday 11 April 2013 16:19:23 Mike Turquette wrote: > Quoting Laurent Pinchart (2013-04-11 15:35:38) > > On Thursday 11 April 2013 11:52:58 Mike Turquette wrote: [snip] > > > I came into this thread late and don't have the actual patches in my > > > inbox for review. That said, I don't understand why V4L2 cares about > > > the clk framework *implementation*? The clk.h api is the same for > > > platforms using the common struct clk and those still using the legacy > > > method of defining their own struct clk. If drivers are only consumers > > > of the clk.h api then the implementation underneath should not matter. > > > > The issue on non-CCF systems is that devices usually can't register clocks > > dynamically. (Most of) those systems provide system clocks only through > > their clock API, without a way for the camera IP core to hook up the > > clock(s) it can provide to the camera sensor. On the consumer side we > > don't care much about the clock framework implementation, but on the > > provider side we need a framework that allows registering non-system > > clocks at runtime. > > Yes, you do care about the clock framework implementation if you are a clock > provider. I still haven't gone through the archives to find these patches > but I hope that any dependency on CONFIG_COMMON_CLK is conditionalized to > have the smallest impact possible. Making v4l2 as a whole depend on > COMMON_CLK might be a bit overkill compared to just making individual camera > drivers depend on it. The basic idea is to push the dependency on CONFIG_COMMON_CLK to individual drivers, and provide a V4L2-specific clock framework (that looks like a stripped-down version of CCF) for platforms that don't implement CCF yet. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
