Not that this is particularly related to DVFS, but: On Thu, 5 May 2011, Colin Cross wrote:
> On Thu, May 5, 2011 at 2:08 PM, Cousson, Benoit <b-cous...@ti.com> wrote: > > > Colin Cross wrote: > > >> omap_hwmod is entirely omap specific, and any generic solution cannot > >> be based on it. > > > > For the moment, because it is a fairly new design, but nothing should > > prevent us to make it generic if this abstraction is relevant for other SoC. > > That's not how you design abstractions. Oh really? > You can't abstract one case, without considering other SoCs, and then > make it generic if it fits other SoCs - it will never fit other SoCs. > You have to consider all the cases you want it to cover, and design an > abstraction that makes sense for the superset. In actual practice, one often does not know in advance the entire universe of cases that one needs to cover. Even just for one SoC. Consider that you mentioned earlier that you had to rewrite the Tegra clock code several times. Now, add several other families of SoCs to the requirements. If the documentation for these chips is even available at all, it is often misleading or wrong. Attempting to create an abstraction before one knows the underlying requirements of what one is actually trying to abstract is a plan for intense suffering. There's little glory in it. ... In the specific case of omap_hwmod, the core of the omap_hwmod data structures were designed such that they could apply to any SoC with a complex interconnect. The design was based on hardware principles common to any SoC: interconnects, IP blocks, reset lines, etc. There are OMAP-specific parts, but if others found omap_hwmod useful, they're trivial to abstract. We haven't sought to force it on others. - Paul -- 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
