Hi Tony,
On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote:
* Rajendra Nayak<rnayak@xxxxxx> [120601 05:13]:
The data is autogenerated using the OMAP autogeneration scripts (python
scripts). Thanks to Mike Turquette for the initial efforts in updating
the script which was later updated by me.
All data is added into a new cclock44xx_data.c file, a later patch will get
rid of clock44xx_data.c file.
Signed-off-by: Rajendra Nayak<rnayak@xxxxxx>
---
arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++++++++++++++++++++++++++++++
arch/arm/mach-omap2/clock.h | 17 +
arch/arm/mach-omap2/clock_common_data.c | 14 +
arch/arm/mach-omap2/scrm44xx.h | 2 +
4 files changed, 2635 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c
If you are adding new data anyways, why not add it to drivers/clock/omap
to start with?
Sorry, I missed out on responding to this one.
We won't be able to move just the new data but will need
all clkops handling around clksel/dpll etc also to be moved,
and I was thinking we might end up with 2 issues doing that.
-1- We have low level PRM/CM headers and apis used across multiple
frameworks for clocks/clockdomains/powerdomains and also some low
level PM code. This might get duplicated in drivers/clk and mach-omap2/
-2- We still need to control clockdomains along with clocks atleast for
OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers
start using omap_device/runtime) and I am not sure how to do it with
the clockdomain framework residing in mach-omap2/
regards,
Rajendra
Regards,
Tony
--
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
