>>-----Original Message----- >>From: Nishanth Menon [mailto:menon.nishanth@xxxxxxxxx] >>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<eduardo.valentin@xxxxxxxxx> >>>>> Cc: Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> >>>>> Cc: Paul Walmsley<paul@xxxxxxxxx> >>>>> Cc: Rajendra Nayak<rnayak@xxxxxx> >>>>> Cc: Sanjeev Premi<premi@xxxxxx> >>>>> Cc: Thara Gopinath<thara@xxxxxx> >>>>> Cc: Tony Lindgren<tony@xxxxxxxxxxx> >>>>> >>>>> Signed-off-by: Nishanth Menon<nm@xxxxxx> >>>>> --- >>>>> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
