26 Jan, 2013
2 commits
-
Convert all DEFINE_OMAP_MUX_GATE() combinations that list MODULEMODE
registers in their gate arguments to DEFINE_OMAP_MUX(), dropping the
MODULEMODE data. This is possible because the MODULEMODE bits control
IP blocks, not clocks; and the hwmod code takes care of IP block
control. Rename these clocks to reflect the original multiplexer name
as specified in the comments. And convert the hwmod data to use the
multiplexer clock name.Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Mike Turquette -
Remove some leaf "clocks" that are actually IP block idle control
points, since these should now be handled by the hwmod code.There are still a few types of MODULEMODE clocks that need to be
cleaned up:- those still in use by driver or integration code
- those in DEFINE_CLK_OMAP_MUX_GATE() blocks; the gate portion of
these should be removedA similar process may also be possible on OMAP2/3.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Mike Turquette
19 Jan, 2013
1 commit
-
To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.Signed-off-by: Peter Ujfalusi
Acked-by: Jon Hunter
[paul@pwsan.com: cleaned up patch description]
Signed-off-by: Paul Walmsley
15 Dec, 2012
6 commits
-
Booting OMAP4460 Pandaboard ES with a recent u-boot results in this
warning:WARNING: at arch/arm/mach-omap2/dpll3xxx.c:427 omap3_noncore_dpll_enable+0xf4/0x110()
The OMAP4 DPLL parent clock names only listed the reference clocks,
not the bypass clocks. Fix by adding the bypass clocks to the DPLL
parent lists.Signed-off-by: Paul Walmsley
Cc: Mike Turquette -
The OMAP4 clock divider "div_iva_hs_clk" is listed in the clock data
as an OMAP HSDIVIDER, but it's actually a power-of-two divider. This
causes a warning during boot on an OMAP4460 Pandaboard-ES with a
recent u-boot:WARNING: at arch/arm/mach-omap2/clkt_clksel.c:143 omap2_clksel_recalc+0xf4/0x12c()
clock: div_iva_hs_clk: could not find fieldval 0 for parent dpll_core_m5x2_ckFix by converting the data for this clock to a power-of-two divider.
Signed-off-by: Paul Walmsley
Cc: Mike Turquette -
With the latest mainline u-boot bootloader (v2012.10), timers (5-8) in
the ABE power domain are failing to turn-on. The timers never come out
of the disabled state when setting the module-mode field to enable.The problem was exposed when u-boot was updated to NOT configure and
lock the ABE DPLL on start-up. If the ABE DPLL is configured and locked
by u-boot the problem does not occur. However, if the ABE DPLL is in the
idle low-power bypass state and we attempt to enable a timer in the ABE
power domain, it remains stuck in the disabled state. It appears to be a
problem the timer interface clock as this comes from the ABE DPLL.If we place the ABE DPLL in the MN-bypass state and not the idle
low-power state, then this problem is not seen.This problem only appears to occur on OMAP4460 and not OMAP4430.
Workaround this problem by locking the ABE DPLL for OMAP4460 in the
kernel on boot. By locking the ABE DPLL, when clocks from the ABE DPLL
are not being requested the DPLL will transition into a low-power stop
mode.Signed-off-by: Jon Hunter
Signed-off-by: Paul Walmsley -
On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
be enabled or disabled in addition to the standard configurable
multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
multiplier is accounted for by checking to see whether it is enabled or
not. However, when calculating a new rate we only check to see if the
rate can be achieved with the current setting for the 4X multiplier.
Enhance the round_rate() function for such DPLLs to see if the rate
can be achieved with the 4X multiplier if it cannot be achieved without
the 4X multiplier.This change is necessary, because when using the 32kHz clock as the
source clock for the ABE DPLL, the default DPLL frequency for the ABE
DPLL cannot be achieved without enabling the 4X multiplier.When using the 32kHz clock as the source clock for the ABE DPLL and
attempting to lock the DPLL to 98.304MHz (default frequency), it was
found that the DPLL would fail to lock if the low-power mode for the DPLL
was not enabled. From reviewing boot-loader settings that configure the
ABE DPLL it was found that the low-power mode is enabled when using the
32kHz clock source, however, the documentation for OMAP does not state
that this is a requirement. Therefore, introduce a new function for
OMAP4 devices to see if low-power mode can be enabled when calculating a
new rate to ensure the DPLL will lock.New variables for the last calculated 4X multiplier and low-power
setting have been added to the dpll data structure as well as variables
defining the bit mask for enabling these features via the DPLL's
control_reg. It is possible that we could eliminate these bit masks from
the dpll data structure as these bit masks are not unique to OMAP4, if
it is preferred.The function omap3_noncore_program_dpll() has been updated to avoid
passing the calculated values for the multiplier (M) and divider (N) as
these are stored in the clk structure.Signed-off-by: Jon Hunter
Signed-off-by: Paul Walmsley -
Currently all OMAP4 non-core DPLLs use the same function table for
configuring DPLLs. For these DPLLs, the function
omap4_dpll_regm4xen_recalc() is used to recalculate the DPLL rate and
the function omap4_dpll_regm4xen_round_rate() is used to calculate the
closest rate to that requested. However, these omap4_dpll_regm4xen_xxx()
functions are only applicable to the ABE DPLL and not the other non-core
DPLLs. Therefore, add a new function table for non-core DPLLs that do
not include the 4X-multiplier (M4X).Please note that using these omap4_dpll_regm4x_xxx() function works for
the non-M4X DPLLs today because we only check to see if the 4X
multiplier is enabled when calculating the rate. However, it is planned
that the dpll functions will be enhanced to enable the 4X multiplier as
necessary (in order to achieve the requested rate) and so calling these
functions for non-M4X dplls will no longer work.Signed-off-by: Jon Hunter
Signed-off-by: Paul Walmsley -
Commit "ARM: dts: OMAP4: Update timer addresses" updated the device-tree
names of the OMAP4 timers 5-7 because the default address for the timers
was changed from the L3 address to the MPU private address. When booting
with device-tree, this introduces a regression when attempting to set
the parent clock of timers 5-7 to the sys_clk_div_ck. Therefore, update
the clock aliases for timer 5-7 to reflect the updated device-tree name
for the timers.Signed-off-by: Jon Hunter
[paul@pwsan.com: updated to apply after the CCF conversion]
Signed-off-by: Paul Walmsley
13 Nov, 2012
1 commit
-
This patch is output from updated omap hw data autogeneration scripts
mostly contributed by Mike Turquette, with some later fixes from me.
All data is added into a new cclock44xx_data.c file which will be
switched with clock44xx_data.c file in a later patch.Signed-off-by: Rajendra Nayak
[paul@pwsan.com: replace omap2_init_clksel_parent() with
omap2_clksel_find_parent_index(); reflowed macros; updated
DEFINE_STRUCT_CLK_HW_OMAP macro to include clkdm_name;
use macros for clksel mux+gate clocks; many other fixes]
[mturquette@ti.com: converted DPLL outputs to HSDIVIDER macro; trace_clk_div_ck
has clkdm ops]
Signed-off-by: Mike Turquette
[paul@pwsan.com: fixed the omap-gpmc.fck alias per commit a2e5b90b; fixed
several checkpatch issues; moved the dpll3xxx.c clockdomain modifications to
another patch]
Signed-off-by: Paul Walmsley
