On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote:
* Rajendra Nayak<rnayak@xxxxxx> [120606 22:33]:
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.
We should sort out those issues, sounds like we're missing few
interfaces..
-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/
Well the PM code should be a loadable module using standard driver
interfaces.. Maybe all it takes is adding few functions that both
drivers/clk and mach-omap2 code can use without exposing all the registers?
Then we may have a better idea what infrastructure pieces are missing.
-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/
Maybe clockdomains could be also handled with some functions without
exposing all the registers in the headers?
Is moving some of the mach-omap2 headers into mach/include and
plat/include and using them in drivers/clk/omap an acceptable
first step? I see both the other architectures (imx and spear)
in drivers/clk already doing it.
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
