[RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
rnayak at ti.com
Thu Jun 21 02:28:42 EDT 2012
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
>> -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.
More information about the linux-arm-kernel