[RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk

[tony@atomide.com (Tony Lindgren)]

* Rajendra Nayak <rnayak@ti.com> [120606 22:33]:
> Hi Tony,
> 
> On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote:
> >* Rajendra Nayak<rnayak@ti.com>  [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@ti.com>
> >>---
> >>  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?

Tony