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

[Tony Lindgren <tony@atomide.com>]

* Rajendra Nayak <rnayak@ti.com> [120620 23:33]:
> On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote:
> >* 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?
> 
> 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.

Yes if it helps to get things going. But it would be best to split the
headers into common and private headers so only minimal amount of
shared registers are defined in plat/include and mach/include. Otherwise
those defines will get misused all over the place. Also note that names
for the headers in plat/include and mach/include need to be omap specific
for common zImage support.

Regards,

Tony