"Gopinath, Thara" <thara@xxxxxx> writes: [...] >>>>>> >>>>>>> No reason why we should have a different file for OMAP4. So a better name than opp3xxx_data.c? >>>>>> why do we need to have it in the same file? Remember, 3630,3430 are >>>>>> under OMAP3 family, but omap4 is considered a different arch. >>>> >>>> Code is more or less the same. Is that not a sufficient reason to reuse a file ? >>>I dont really care as long as opp layer is usable by mpurate without >>>depending on cpufreq and it is maintainable without going to if else >>>nightmare. But personally, I dont see really reusuable code in that file >>>(other than doing an opp addition in a loop) it could result eventually >>>in a large amount of code redundancy and maintenance nightmare with >>>OMAP4 variants coming in. > > Why do you say maintenance nightmare? It is going to be one opp table > per SoC. Anyways, Kevin what is your take on this? > I think we should keep separate files for each SoC listing the OPP data, and in those files should be *only* data. The init functions across these files will be basically the same, so maybe the common code should be pulled out into a separate file (pm.c?), and the data files have a very simple init function (device_initcall) that just registers their data. Kevin -- 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
