Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
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.

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux