RFC Move OMAP2+ over to use COMMON clock
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 24 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 24 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC 00/24] Move OMAP2+ over to use COMMON clock
Hi Rajendra,
Quoted 52 lines · Rajendra Nayak
Hi,
This RFC series is based of Mikes' latest clk-next. I will rebase it once 3.5-rc1 is out and post with more testing thats in progress. Meanwhile, the RFC is for me to get some early feedback on the patches.
This series retains the static clock declarations and also all data and code in mach-omap folders and does not move it as yet to
drivers/clk. I know its desierable that we move away from static declaration of data and move over todrivers/clkbut thats not addressed by this series.
Also the series moves over only OMAP2+ (OMAP2/3/4)
to use COMMON clk and leaves OMAP1 still using OMAP clock framework.The series does not break git-bisect at any point and to do so adds new data in completely different files and uses some ifdefferry in code too, and switches over in one patch to move from OMAP clock to COMMON clock. Then deletes all old data files and all the ifdeferrey around.
All of the new data for OMAP2/3/4 in the new COMMON clock format is autogenerated, OMAP4 by hacking the existing python scripts, and OMAP2/3 by converting the existing C99 structs to JSON format (Thanks to Paul Walmsley for this) and then having python to read the JSON format and generate the C99 structs back in the form COMMON clk expects.
The patches also depend on 2 of my patches posted here
http://comments.gmane.org/gmane.linux.kernel/1298747
I have not reposted them becasue one of them is already picked up by Mike, and the other is already under discussion.The series with all dependent patches can be found here
git://github.com/rrnayak/linux.gitclk-next-omapregards,
RajendraMike Turquette (1):
ARM: omap4: cm: add bitfield width valuesRajendra Nayak (23):
clk: AddCLK_IS_BASICflag to identify basic clocks
ARM: omap: clk: convert allclk_enabletoclk_prepare_enable
ARM: omap: hwmod: get rid of allomap_clk_get_by_nameusage
ARM: omap: clk: Nuke platclock.c&clock.hifCONFIG_COMMON_CLK
ARM: omap: clk: Remove all direct dereferncing of struct clk
ARM: omap: hwmod: Fix up hwmod based clkdm accesses
ARM: omap4: clk: Convert to common clk
ARM: omap3: clk: Convert to common clk
Quoted 8 lines
ARM: omap2: clk: Convert to common clk
ARM: omap: clk: list allclk_hw_omapclks to enable/disable autoidle
ARM: omap: clk: Define a function to enable clocks at init
ARM: omap4: clk: Add 44xx data using common struct clk
ARM: omap3: clk: Add 3xxx data using common struct clk
ARM: omap2: clk: Add 24xx data using common struct clk
ARM: omap: clk: Switch to COMMON clk
ARM: omap: clk: Use platclock.c&clock.honly for OMAP1
With regard to the above patch, I am not sure why it is necessary to move the existing definitions out of plat-omap/clock.h to put in mach-omap2/clock.h. Eventually, if we move omap1 to the common clock framework, won't we need to move them back? It would seem to me that by keeping them in plat clock.h it will be easier to migrate omap1 to the common clock framework (assuming thats our goal). Also, by adding the common clock definitions to the plat clock.h it will be easier for migrating omap1 too.
Obviously, we would need to keep the #ifdef COMMON_CLK around this code so it can compile for both omap1 and omap2+ today.
Cheers
Jon