Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
* Paul Walmsley p...@pwsan.com [120916 13:37]: On Tue, 11 Sep 2012, Paul Walmsley wrote: Then the branch was PM-tested to determine whether it can suspend and serial-resume properly, and whether dynamic idle works. These tests didn't go so well: - 3530ES3 Beagleboard here was able to enter retention-idle suspend, and leave it with serial wakeup, but the CORE powerdomain never entered a low-power state. Dynamic retention-idle with serial wakeup never resumed, and the test stopped there: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt - 37xx EVM and 3730 Beagle XM fared better; they made it through the whole test program, but the CORE powerdomain also never entered a low-power state: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt Thanks to debugging work by some TI LDC engineers, these two issues have been resolved. Some clockdomain associations had been removed that were necessary for the OMAP power management code to function correctly. The obvious ones have been restored to the clock data, and the branch updated. That's good news. Does that mean we should try to merge these patches for v3.7 then? Or do we still have issues remaining? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Mon, 17 Sep 2012, Tony Lindgren wrote: That's good news. Does that mean we should try to merge these patches for v3.7 then? Or do we still have issues remaining? There are still problems with the OMAP4 CCF implementation. Power management is broken on some bootloaders that the original data works fine with. It's still under debug. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Tue, 11 Sep 2012, Paul Walmsley wrote: Then the branch was PM-tested to determine whether it can suspend and serial-resume properly, and whether dynamic idle works. These tests didn't go so well: - 3530ES3 Beagleboard here was able to enter retention-idle suspend, and leave it with serial wakeup, but the CORE powerdomain never entered a low-power state. Dynamic retention-idle with serial wakeup never resumed, and the test stopped there: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt - 37xx EVM and 3730 Beagle XM fared better; they made it through the whole test program, but the CORE powerdomain also never entered a low-power state: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt Thanks to debugging work by some TI LDC engineers, these two issues have been resolved. Some clockdomain associations had been removed that were necessary for the OMAP power management code to function correctly. The obvious ones have been restored to the clock data, and the branch updated. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Tue, 11 Sep 2012, Paul Walmsley wrote: The kernel built with omap2plus_defconfig was then booted on several OMAP2+ boards. Here's what was found: [ ... ] - The 2420 N800 seems to have some kind of MMC-related problem that prevents it from booting. Still looking into this: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/2420n800/2420n800_log.txt This has been resolved. The APLL clocks have been missing rate recalculation functions for a long time. This wasn't a problem in the past because these were considered fixed rate clocks (at the locked frequency). But in the CCF conversion, the fixed rate was dropped. This caused the MMC functional clock to be set incorrectly to the sys_clk rate. This in turn caused the MMC driver's timing calculation code to return the wrong value, preventing meaningful MMC/SD access. The problem was resolved by creating recalc_rate function pointers for the APLLs that return sys_ck if the APLL is bypassed, or the APLL rate if it's locked, for both 2420 and 2430. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Sat, 15 Sep 2012, Paul Walmsley wrote: The problem was resolved by creating recalc_rate function pointers for the APLLs that return sys_ck if the APLL is bypassed, or the APLL rate if it's locked, for both 2420 and 2430. One correction - the APLL recalc functions return a zero rate if stopped, not the bypass rate. This appears to be the case, from a close reading of the TRM. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
Hi Rajendra, A CCF testing branch has been built here. The base is v3.6-rc5, plus the most recent version of the Common Clock Framework preparation patches that you posted to the list, [PATCH v4 0/3] Prepare for OMAP2+ movement to Common Clk, but updated to take RMK's feedback into account. Then the 'clk-next-omap-3.6-rc3' branch from your repo at 'git://github.com/rrnayak/linux.git' was added. Then some patches to drop the old arch/arm/mach-omap2/clock*_data.c files were added. This branch was then run through checkpatch.pl, and all of the parenthesis alignment warnings have been fixed. I don't know what to do about these crazy DECLARE_CLK_* macros; they have so many arguments that they are basically impossible to read. Mike and I discussed converting them into C99 structure initializers with named fields, but am not sure if it's a readability advantage; it's probably going to be write-only data either way. I've reflowed many of them to save diffstat but there are quite a few more to go. The branch was then built with a set of testing Kconfigs. Here's what was found: (these are still being investigated) - The OMAP4-only testconfig and rmk's OMAP4430-SDP Kconfigs failed: undefined reference to `omap2_clkt_iclk_allow_idle': http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/omap4_testconfig/ http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap4430_sdp_oldconfig/ - RMK's OMAP3430-LDP Kconfig failed with a whole set of warnings: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap3430_ldp_oldconfig/ The kernel built with omap2plus_defconfig was then booted on several OMAP2+ boards. Here's what was found: - The kernel wouldn't boot on either the 3517EVM nor CM-T3517 boards. This turned out to be due to some missing AM35XX clkdev aliases, the lack of which cause the CCF code to panic. The patch that adds the OMAP3 data has been updated to fix that bug and an HSOTGUSB clkdev alias bug that was found by visual inspection. - The 3730 Beagle XM issued a warning and stack trace upon boot. Debugging with Mike, this turned out to be due to a bug in the modified omap2_init_clksel_parent() function: it returned a register bitfield rather than an array index. The patch that modifies this function was then updated to fix the bug. - The 2420 N800 seems to have some kind of MMC-related problem that prevents it from booting. Still looking into this: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/2420n800/2420n800_log.txt Then the branch was PM-tested to determine whether it can suspend and serial-resume properly, and whether dynamic idle works. These tests didn't go so well: - 3530ES3 Beagleboard here was able to enter retention-idle suspend, and leave it with serial wakeup, but the CORE powerdomain never entered a low-power state. Dynamic retention-idle with serial wakeup never resumed, and the test stopped there: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt - 37xx EVM and 3730 Beagle XM fared better; they made it through the whole test program, but the CORE powerdomain also never entered a low-power state: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt - 4430ES2 Panda never made past the first retention-idle suspend: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/4430es2panda/4430es2panda_log.txt Could you please take a look and see if you can identify why the patches aren't passing the tests? I can't send these upstream until they pass the PM tests. This testing branch can be found at the branch named common_clk_testing_devel_3.7 of git://git.pwsan.com/linux-2.6 The testbed reports from this branch can be found here: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/ And the baseline test reports from v3.6-rc5 can be found here: http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/ - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On 9/11/2012 12:05 PM, Paul Walmsley wrote:
Hi Rajendra,
A CCF testing branch has been built here. The base is v3.6-rc5, plus the
most recent version of the Common Clock Framework preparation patches that
you posted to the list, [PATCH v4 0/3] Prepare for OMAP2+ movement to
Common Clk, but updated to take RMK's feedback into account. Then the
'clk-next-omap-3.6-rc3' branch from your repo at
'git://github.com/rrnayak/linux.git' was added. Then some patches to drop
the old arch/arm/mach-omap2/clock*_data.c files were added.
This branch was then run through checkpatch.pl, and all of the parenthesis
alignment warnings have been fixed. I don't know what to do about these
crazy DECLARE_CLK_* macros; they have so many arguments that they are
basically impossible to read. Mike and I discussed converting them
into C99 structure initializers with named fields, but am not sure if it's
a readability advantage; it's probably going to be write-only data
either way. I've reflowed many of them to save diffstat but there are
quite a few more to go.
The branch was then built with a set of testing Kconfigs. Here's what was
found: (these are still being investigated)
- The OMAP4-only testconfig and rmk's OMAP4430-SDP Kconfigs failed:
undefined reference to `omap2_clkt_iclk_allow_idle':
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/omap4_testconfig/
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap4430_sdp_oldconfig/
- RMK's OMAP3430-LDP Kconfig failed with a whole set of warnings:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap3430_ldp_oldconfig/
The kernel built with omap2plus_defconfig was then booted on several
OMAP2+ boards. Here's what was found:
- The kernel wouldn't boot on either the 3517EVM nor CM-T3517 boards.
This turned out to be due to some missing AM35XX clkdev aliases, the
lack of which cause the CCF code to panic. The patch that adds the
OMAP3 data has been updated to fix that bug and an HSOTGUSB clkdev
alias bug that was found by visual inspection.
- The 3730 Beagle XM issued a warning and stack trace upon boot.
Debugging with Mike, this turned out to be due to a bug in the
modified omap2_init_clksel_parent() function: it returned a register
bitfield rather than an array index. The patch that modifies this
function was then updated to fix the bug.
- The 2420 N800 seems to have some kind of MMC-related problem
that prevents it from booting. Still looking into this:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/2420n800/2420n800_log.txt
Then the branch was PM-tested to determine whether it can suspend and
serial-resume properly, and whether dynamic idle works. These tests
didn't go so well:
- 3530ES3 Beagleboard here was able to enter retention-idle
suspend, and leave it with serial wakeup, but the CORE powerdomain never
entered a low-power state. Dynamic retention-idle with serial wakeup
never resumed, and the test stopped there:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt
- 37xx EVM and 3730 Beagle XM fared better; they made it through the whole
test program, but the CORE powerdomain also never entered a low-power
state:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt
- 4430ES2 Panda never made past the first retention-idle suspend:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/4430es2panda/4430es2panda_log.txt
Could you please take a look and see if you can identify why the patches
aren't passing the tests? I can't send these upstream until they pass the
PM tests.
This testing branch can be found at the branch named
common_clk_testing_devel_3.7 of git://git.pwsan.com/linux-2.6
The testbed reports from this branch can be found here:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/
And the baseline test reports from v3.6-rc5 can be found here:
http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/
I tried this branch on BeagleBone platform and needs one small typo
correction in hwmod data patch (submitted earlier, which you are going
to queue it)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index de7a3ab..767a77d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1441,7 +1441,7 @@ static struct omap_hwmod am33xx_mmc2_hwmod = {
.clkdm_name = l3s_clkdm,
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Tue, 11 Sep 2012, Paul Walmsley wrote: The branch was then built with a set of testing Kconfigs. Here's what was found: (these are still being investigated) - The OMAP4-only testconfig and rmk's OMAP4430-SDP Kconfigs failed: undefined reference to `omap2_clkt_iclk_allow_idle': http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/omap4_testconfig/ http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap4430_sdp_oldconfig/ - RMK's OMAP3430-LDP Kconfig failed with a whole set of warnings: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap3430_ldp_oldconfig/ These build problems have been fixed and the branch updated. Current test logs at http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911134655/ - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Tue, 11 Sep 2012, Vaibhav Hiremath wrote:
I tried this branch on BeagleBone platform and needs one small typo
correction in hwmod data patch (submitted earlier, which you are going
to queue it)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index de7a3ab..767a77d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1441,7 +1441,7 @@ static struct omap_hwmod am33xx_mmc2_hwmod = {
.clkdm_name = l3s_clkdm,
.mpu_irqs = am33xx_mmc2_irqs,
.sdma_reqs = am33xx_mmc2_edma_reqs,
- .main_clk = mmc2_fck,
+ .main_clk = mmc_clk,
.prcm = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET,
With above change I boot tested it on BeagleBone platform and also
verified the clock rates getting printed in debugfs.
So does this mean we need to put together a patch to remove the existing
mmc2_fck first from the OMAP clock data file? Looks like that would be
the right thing to do, based on the AM33x PRCM data.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Wed, Sep 12, 2012 at 04:40:51, Paul Walmsley wrote:
On Tue, 11 Sep 2012, Vaibhav Hiremath wrote:
I tried this branch on BeagleBone platform and needs one small typo
correction in hwmod data patch (submitted earlier, which you are going
to queue it)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index de7a3ab..767a77d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1441,7 +1441,7 @@ static struct omap_hwmod am33xx_mmc2_hwmod = {
.clkdm_name = l3s_clkdm,
.mpu_irqs = am33xx_mmc2_irqs,
.sdma_reqs = am33xx_mmc2_edma_reqs,
- .main_clk = mmc2_fck,
+ .main_clk = mmc_clk,
.prcm = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET,
With above change I boot tested it on BeagleBone platform and also
verified the clock rates getting printed in debugfs.
So does this mean we need to put together a patch to remove the existing
mmc2_fck first from the OMAP clock data file? Looks like that would be
the right thing to do, based on the AM33x PRCM data.
Yes, that's correct and it has been already removed from clock data file
while migrating to common clock framework.
Thanks,
Vaibhav
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Monday 18 June 2012 09:57 AM, Paul Walmsley wrote: On Thu, 14 Jun 2012, Rajendra Nayak wrote: OMAP3 has suspend broken in mainline, so I tested it on an older kernel (3.4-rc4 using my RFC series) Idle and OFF mode however seem to be broken for a long time, I wasn;t able to get it working even on 3.4 major. See my logs '3630 Beagle-Xm broken idle/off on 3.4' if I am doing anything wrong. I have CPUidle enabled in the kernel config. http://www.spinics.net/lists/arm-kernel/msg173688.html Thanks Paul. I re-tested my branch [1] after applying the 32K sync timer fix [2] and using timer based wakeup [3] instead of UART. Both retention and off work fine on my 3630 Beagle-Xm on my CCF conversion branch. Updated logs can be found here http://pastebin.com/u/rnayak regards, Rajendra [1] git://github.com/rrnayak/linux.git clk-next-omap-3.5-rc2 [2] http://marc.info/?l=linux-omapm=13453229888w=2 [3] http://marc.info/?l=linux-omapm=134001387702336w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Thu, 14 Jun 2012, Rajendra Nayak wrote: OMAP3 has suspend broken in mainline, so I tested it on an older kernel (3.4-rc4 using my RFC series) Idle and OFF mode however seem to be broken for a long time, I wasn;t able to get it working even on 3.4 major. See my logs '3630 Beagle-Xm broken idle/off on 3.4' if I am doing anything wrong. I have CPUidle enabled in the kernel config. http://www.spinics.net/lists/arm-kernel/msg173688.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/29] Move OMAP2+ over to use COMMON clock
Hi, Series is based on latest clk-next(3.5-rc2) from Mike. Boot/Test logs for the series can be found here http://pastebin.com/u/rnayak Changes/Fixes/Updates since RFC series -1- Fixed issues with dpll abe rate on OMAP4 -2- Fixed boot crash on 2430SDP and 2420N800 -3- Fixed suspend on OMAP3, (unused clocks were not disabled) -4- clk_hw_omap and related defs now retained in plat/clock.h -5- Added missing 4460 clocks for OMAP4 -6- Fixed some drivers to use clk_prepare_enable and clk_disable_unprepare -7- Added .is_enabled hooks for all OMAP2/3/4 gate clocks -8- Got rid of the late_init call -9- Fixed the handling of omap_96m_alwon_fck_3630 clk for OMAP3 OMAP3 has suspend broken in mainline, so I tested it on an older kernel (3.4-rc4 using my RFC series) Idle and OFF mode however seem to be broken for a long time, I wasn;t able to get it working even on 3.4 major. See my logs '3630 Beagle-Xm broken idle/off on 3.4' if I am doing anything wrong. I have CPUidle enabled in the kernel config. 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. 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 complete series can be found here git://github.com/rrnayak/linux.git clk-next-omap-3.5-rc2 Special thanks to Jon Hunter for his help testing on the 2420-N800 device. regards, Rajendra Mike Turquette (1): ARM: omap4: cm: add bitfield width values Rajendra Nayak (28): clk: Add support for rate table based dividers clk: Add CLK_IS_BASIC flag to identify basic clocks ARM: omap: clk: convert all clk_enable to clk_prepare_enable mmc: omap_hsmmc: use clk_prepare_enable and clk_disable_unprepare hwrng: omap: use clk_prepare_enable and clk_disable_unprepare mfd: omap-usb: use clk_prepare_enable and clk_disable_unprepare ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage ARM: omap: clk: Nuke plat/clock.c reuse struct clk as clk_hw_omap 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 ARM: omap2: clk: Convert to common clk ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle ARM: omap: clk: Define a function to enable clocks at init ARM: omap: clock: Get rid of unwanted clkdm assocations within clks 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 plat/clock.c only for OMAP1 ARM: omap: hwmod: Cleanup !CONFIG_COMMON_CLK parts ARM: omap4: clk: Cleanup !CONFIG_COMMON_CLK parts ARM: omap3: clk: Cleanup !CONFIG_COMMON_CLK parts ARM: omap2: clk: Cleanup !CONFIG_COMMON_CLK parts ARM: omap4: clk: Delete old OMAP clock data ARM: omap3: clk: Delete old OMAP clock data ARM: omap2: clk: Delete old OMAP clock data arch/arm/mach-imx/clk.h |2 +- arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/Makefile |8 +- arch/arm/mach-omap2/board-apollon.c |4 +- arch/arm/mach-omap2/board-h4.c |6 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/cclock2420_data.c| 2306 +++ arch/arm/mach-omap2/cclock2430_data.c| 2434 arch/arm/mach-omap2/cclock3xxx_data.c| 3981 ++ arch/arm/mach-omap2/cclock44xx_data.c| 2628 + arch/arm/mach-omap2/clkt2xxx_apll.c | 35 +- arch/arm/mach-omap2/clkt2xxx_dpll.c |8 +- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 11 +- arch/arm/mach-omap2/clkt2xxx_osc.c | 12 +- arch/arm/mach-omap2/clkt2xxx_sys.c |6 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 14 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 24 +- arch/arm/mach-omap2/clkt_clksel.c| 198 +- arch/arm/mach-omap2/clkt_dpll.c | 48 +- arch/arm/mach-omap2/clkt_iclk.c | 35 +- arch/arm/mach-omap2/clock.c | 334 +-- arch/arm/mach-omap2/clock.h
