>>-----Original Message----- >>From: Nishanth Menon [mailto:[email protected]] >>Sent: Wednesday, August 11, 2010 4:14 PM >>To: Gopinath, Thara >>Cc: Menon, Nishanth; linux-omap; Eduardo Valentin; Kevin Hilman; Paul >>Walmsley; Nayak, Rajendra; >>Premi, Sanjeev; Tony Lindgren >>Subject: Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq >> >>On 08/11/2010 04:12 AM, Gopinath, Thara wrote: >>> >>> >>>>> -----Original Message----- >>>>> From: Menon, Nishanth >>>>> Sent: Wednesday, August 11, 2010 7:47 AM >>>>> To: linux-omap >>>>> Cc: Menon, Nishanth; Eduardo Valentin; Kevin Hilman; Paul Walmsley; >>>>> Nayak, Rajendra; Premi, >>Sanjeev; >>>>> Gopinath, Thara; Tony Lindgren >>>>> Subject: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq >>>>> >>>>> Make opp3xx data which is registered with the opp layer >>>>> dependent purely on CONFIG_PM as opp layer and pm.c users >>>>> are CONFIG_PM dependent not cpufreq dependent. >>>>> so we rename the data definition to opp3xxx_data.c (inline with what >>>>> we have for omap2), also move the build definition to be under >>>>> the existing CONFIG_PM build instead of CPUFREQ. >>>>> >>>>> Cc: Eduardo Valentin<[email protected]> >>>>> Cc: Kevin Hilman<[email protected]> >>>>> Cc: Paul Walmsley<[email protected]> >>>>> Cc: Rajendra Nayak<[email protected]> >>>>> Cc: Sanjeev Premi<[email protected]> >>>>> Cc: Thara Gopinath<[email protected]> >>>>> Cc: Tony Lindgren<[email protected]> >>>>> >>>>> Signed-off-by: Nishanth Menon<[email protected]> >>>>> --- >>>>> Note: >>>>> This takes care of the discussion on opp file renaming and making >>>>> it independent of cpufreq, unless I missed something else >>>>> >>>>> arch/arm/mach-omap2/Makefile | 5 +---- >>>>> .../mach-omap2/{cpufreq34xx.c => opp3xxx_data.c} | 0 >>>>> 2 files changed, 1 insertions(+), 4 deletions(-) >>>>> rename arch/arm/mach-omap2/{cpufreq34xx.c => opp3xxx_data.c} (100%) >>> >>> Is this part of PM-OPP branch? Also I was thinking of reusing the same file >>> for OMAP4. >>this defines the opp data base and would be part of pm-opp branch. the >>idea of rename was this: >>a) be clear that this is not dependent on cpufreq alone.
I do not understand this. This files is not present in PM-OPP branch. But you have a patch modifying it against PM-OPP branch. Am I looking at a wrong version of PM-OPP branch? >>b) use the same convention in arch/arm/mach-omap2/ like omap2's opp data >>files which could be converted to use the opp layer now instead of >>having it's own opp layer. and maybe hopefully omap1 as well.. >>c) when we do specific product build, it makes sense to have arch >>specific files as it makes not much reason to carry the omap4/2 >>definitions(even if init_data). >> >>> 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 ? >> >>Regards, >>Nishanth Menon >>[...] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
