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

[Rajendra Nayak]

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

>
> Tony