Hi, On Mon, Jan 24, 2011 at 07:55:21PM +0530, Vishwanath Sripathy wrote: > 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.
if what you're saying was really true then we wouldn't have generic clock API, pm_runtime, pm QoS, CPUFreq, CPUIdle, etc etc. Those are very much coupled with the underlying Hardware. In fact, every single thing is very much coupled with the underlying hardware. And even so we manage to have all of the above plus GPIOLIB, generic IRQ handling (even threaded), DMA API (which we don't use yet), etc etc etc. So, IMHO, being coupled to underlying HW is not excuse for not making a generic API, quite the opposite actually, it should be a motivation. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
