alistair23-linux/arch/arm/mach-omap2/clock3xxx.c

136 lines
3.8 KiB
C
Raw Normal View History

/*
* OMAP3-specific clock framework functions
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
* Copyright (C) 2007-2010 Nokia Corporation
*
* Paul Walmsley
* Jouni Högander
*
* Parts of this code are based on code written by
* Richard Woodruff, Tony Lindgren, Tuukka Tikkanen, Karthik Dasu
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#undef DEBUG
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/clk.h>
#include <linux/io.h>
ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-08-31 11:59:07 -06:00
#include "soc.h"
#include "clock.h"
#include "clock3xxx.h"
#include "prm2xxx_3xxx.h"
#include "prm-regbits-34xx.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
/*
* DPLL5_FREQ_FOR_USBHOST: USBHOST and USBTLL are the only clocks
* that are sourced by DPLL5, and both of these require this clock
* to be at 120 MHz for proper operation.
*/
#define DPLL5_FREQ_FOR_USBHOST 120000000
/* needed by omap3_core_dpll_m2_set_rate() */
struct clk *sdrc_ick_p, *arm_fck_p;
/**
* omap3_dpll4_set_rate - set rate for omap3 per-dpll
* @hw: clock to change
* @rate: target rate for clock
* @parent_rate: rate of the parent clock
*
* Check if the current SoC supports the per-dpll reprogram operation
* or not, and then do the rate change if supported. Returns -EINVAL
* if not supported, 0 for success, and potential error codes from the
* clock rate change.
*/
int omap3_dpll4_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
/*
* According to the 12-5 CDP code from TI, "Limitation 2.5"
* on 3430ES1 prevents us from changing DPLL multipliers or dividers
* on DPLL4.
*/
if (ti_clk_get_features()->flags & TI_CLK_DPLL4_DENY_REPROGRAM) {
pr_err("clock: DPLL4 cannot change rate due to silicon 'Limitation 2.5' on 3430ES1.\n");
return -EINVAL;
}
return omap3_noncore_dpll_set_rate(hw, rate, parent_rate);
}
/**
* omap3_dpll4_set_rate_and_parent - set rate and parent for omap3 per-dpll
* @hw: clock to change
* @rate: target rate for clock
* @parent_rate: rate of the parent clock
* @index: parent index, 0 - reference clock, 1 - bypass clock
*
* Check if the current SoC support the per-dpll reprogram operation
* or not, and then do the rate + parent change if supported. Returns
* -EINVAL if not supported, 0 for success, and potential error codes
* from the clock rate change.
*/
int omap3_dpll4_set_rate_and_parent(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate, u8 index)
{
if (ti_clk_get_features()->flags & TI_CLK_DPLL4_DENY_REPROGRAM) {
pr_err("clock: DPLL4 cannot change rate due to silicon 'Limitation 2.5' on 3430ES1.\n");
return -EINVAL;
}
return omap3_noncore_dpll_set_rate_and_parent(hw, rate, parent_rate,
index);
}
void __init omap3_clk_lock_dpll5(void)
{
struct clk *dpll5_clk;
struct clk *dpll5_m2_clk;
dpll5_clk = clk_get(NULL, "dpll5_ck");
clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST);
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-22 02:24:16 -06:00
clk_prepare_enable(dpll5_clk);
/* Program dpll5_m2_clk divider for no division */
dpll5_m2_clk = clk_get(NULL, "dpll5_m2_ck");
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-22 02:24:16 -06:00
clk_prepare_enable(dpll5_m2_clk);
clk_set_rate(dpll5_m2_clk, DPLL5_FREQ_FOR_USBHOST);
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-22 02:24:16 -06:00
clk_disable_unprepare(dpll5_m2_clk);
clk_disable_unprepare(dpll5_clk);
return;
}
/* Common clock code */
/*
* Switch the MPU rate if specified on cmdline. We cannot do this
* early until cmdline is parsed. XXX This should be removed from the
* clock code and handled by the OPP layer code in the near future.
*/
static int __init omap3xxx_clk_arch_init(void)
{
int ret;
if (!cpu_is_omap34xx())
return 0;
ret = omap2_clk_switch_mpurate_at_boot("dpll1_ck");
if (!ret)
omap2_clk_print_new_rates("osc_sys_ck", "core_ck", "arm_fck");
return ret;
}
omap_arch_initcall(omap3xxx_clk_arch_init);