On Monday 24 January 2011 15:25:21 Vishwanath Sripathy wrote: > On Monday, January 24, 2011 11:49 AM Felipe Balbi wrote: > > On Mon, Jan 24, 2011 at 11:31:20AM +0530, Vishwanath Sripathy wrote: > > > I do not think DVFS layer can be made a generic layer outside OMAP > > > because of the fact that DVFS is closely coupled with OMAP device layer > > > (for getting hwmod related data and clock handling), OMAP voltage layer > > > (for voltage scaling and handling of dependency voltage domains) and > > > smart reflex layer. > > > > that an implementation detail. If you: > > a. make the DVFS layer so that you need a HW-glue layer which > > will use OMAP-specific APIs; or > > > > b. pass function pointers for the generic DVFS layer to use > > > > (note that I'd rather have option (a)), you solve the problem, no ? > > It is not just implementation. Even the underlying design of DVFS is > closely coupled with these layers. If we try to split this DVFS framework > into generic and OMAP specific part, then the flow will become too > cumbersome since there are will be too many interactions between common > and OMAP part. Also it will reduce the code readability aspect as well. > I do not think it's worth adding some much of complexity and effort just > to avoid a driver using platform specific function pointers to call these > APIs. The issue with callbacks to board code is that they prevent the use of the device tree which is getting introduced on ARM platforms. We should avoid them as much as possible. -- Regards, Laurent Pinchart -- 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
