Kevin Hilman had written, on 08/12/2010 09:34 AM, the following:
"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.
yep, this sounds like a good idea, let me try something on this line and
post a new rev..
--
Regards,
Nishanth Menon
--
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
