aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/clock24xx.h
AgeCommit message (Collapse)Author
2009-04-23OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c filesPaul Walmsley
Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files to use in .init_irq functions to configure the system tick GPTIMER. Practical choices at this point are GPTIMER1 or GPTIMER12. Both of these timers are in the WKUP powerdomain, and so are unaffected by chip power management. GPTIMER1 can use sys_clk as a source, for applications where a high-resolution timer is more important than power management. GPTIMER12 has the special property that it has the secure 32kHz oscillator as its source clock, which may be less prone to glitches than the off-chip 32kHz oscillator. But on HS devices, it may not be available for Linux use. It appears that most boards are fine with GPTIMER1, but BeagleBoard should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs in revisions B4 and below. Modify board-omap3beagle.c to use GPTIMER12. This patch originally used a Kbuild config option to select the GPTIMER, but was changed to allow this to be specified in board-*.c files, per Tony's request. Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of this patch - thanks Kalle. Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and 3430SDP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Cc: Kalle Valo <kalle.valo@nokia.com>
2009-02-19[ARM] omap: add support for bypassing DPLLsRussell King
This roughly corresponds with OMAP commits: 7d06c48, 3241b19, 88b5d9b, 18a5500, 9c909ac, 5c6497b, 8b1f0bd, 2ac1da8. For both OMAP2 and OMAP3, we note the reference and bypass clocks in the DPLL data structure. Whenever we modify the DPLL rate, we first ensure that both the reference and bypass clocks are enabled. Then, we decide whether to use the reference and DPLL, or the bypass clock if the desired rate is identical to the bypass rate, and program the DPLL appropriately. Finally, we update the clock's parent, and then disable the unused clocks. This keeps the parents correctly balanced, and more importantly ensures that the bypass clock is running whenever we reprogram the DPLL. This is especially important because the procedure for reprogramming the DPLL involves switching to the bypass clock. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-14[ARM] omap: arrange for clock recalc methods to return the rateRussell King
linux-omap source commit 33d000c99ee393fe2042f93e8422f94976d276ce introduces a way to "dry run" clock changes before they're committed. However, this involves putting logic to handle this into each and every recalc function, and unfortunately due to the caching, led to some bugs. Solve both of issues by making the recalc methods always return the clock rate for the clock, which the caller decides what to do with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: create a proper tree of clocksRussell King
Traditionally, we've tracked the parent/child relationships between clk structures by setting the child's parent member to point at the upstream clock. As a result, when decending the tree, we have had to scan all clocks to find the children. Avoid this wasteful scanning by keeping a list of the clock's children. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] OMAP3 clock: avoid invalid FREQSEL values during DPLL rate roundingPaul Walmsley
The DPLL FREQSEL jitter correction bits are set based on a table in the 34xx TRM, Table 4-38, according to the DPLL's internal clock frequency "Fint." Several Fint frequency ranges are missing from this table. Previously, we allowed these Fint frequency ranges to be selected in the rate rounding code, but did not change the FREQSEL bits. Correspondence with the OMAP hardware team indicates that Fint values not in the table should not be used. So, prevent them from being selected during DPLL rate rounding. This removes warnings and also can prevent the chip from locking up. The first pass through the rate rounding code will update the DPLL max and min dividers appropriately, so later rate rounding passes will run faster than the first. Peter de Schrijver <peter.de-schrijver@nokia.com> put up with several test cycles of this patch - thanks Peter. linux-omap source commit is f9c1b82f55b60fc39eaa6e7aa1fbe380c0ffe2e9. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Peter de Schrijver <peter.de-schrijver@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] OMAP24xx clock: add missing SSI L4 interface clockPaul Walmsley
This patch adds a missing OMAP24xx clock, the SSI L4 interface clock, as "ssi_l4_ick". linux-omap source commit is ace129d39b3107d330d4cf6934385d13521f2fec. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: convert OMAP2 to use clkdevRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: move propagate_rate() calls into generic omap clock codeRussell King
propagate_rate() is recursive, so it makes sense to minimise the amount of stack which is used for each recursion. So, rather than recursing back into it from the ->recalc functions if RATE_PROPAGATES is set, do that test at the higher level. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: don't use clkops_omap2_dflt_wait for non-ICLK/FCLK clocksRussell King
The original code in omap2_clk_wait_ready() used to check the low 8 bits to determine whether they were within the FCLKEN or ICLKEN registers. Specifically, the test is satisfied when these offsets are used: CM_FCLKEN, CM_FCLKEN1, CM_CLKEN, OMAP24XX_CM_FCLKEN2, CM_ICLKEN, CM_ICLKEN1, CM_ICLKEN2, CM_ICLKEN3, OMAP24XX_CM_ICLKEN4 OMAP3430_CM_CLKEN_PLL, OMAP3430ES2_CM_CLKEN2 If one of these offsets isn't used, omap2_clk_wait_ready() merely returns without doing anything. So we should use the non-wait clkops version instead and eliminate that conditional. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: eliminate unnecessary conditionals in omap2_clk_wait_readyRussell King
Rather than employing run-time tests in omap2_clk_wait_ready() to decide whether we need to wait for the clock to become ready, we can set the .ops appropriately. This change deals with the OMAP24xx and OMAP34xx conditionals only. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: add default .ops to all remaining OMAP2 clocksRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: kill PARENT_CONTROLS_CLOCKRussell King
PARENT_CONTROLS_CLOCK just makes enable/disable no-op, and is functionally an alias for ALWAYS_ENABLED. This can be handled in the same way, using clkops_null. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-08[ARM] omap: provide a NULL clock operations structureRussell King
... and use it for clocks which are ALWAYS_ENABLED. These clocks use a non-NULL enable_reg pointer for other purposes (such as selecting clock rates.) Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-02[ARM] omap: introduce clock operations structureRussell King
Collect up all the common enable/disable clock operation functions into a separate operations structure. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-02[ARM] omap: remove VIRTUAL_CLOCKRussell King
Nothing tests the clock flags for this bit, so it serves no purpose. Remove it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-01-05Merge branch 'i2c-next' of git://aeryn.fluff.org.uk/bjdooks/linuxLinus Torvalds
* 'i2c-next' of git://aeryn.fluff.org.uk/bjdooks/linux: i2c-omap: fix type of irq handler function i2c-s3c2410: Change IRQ to be plain integer. i2c-s3c2410: Allow more than one i2c-s3c2410 adapter i2c-s3c2410: Remove default platform data. i2c-s3c2410: Use platform data for gpio configuration i2c-s3c2410: Fixup style problems from checkpatch.pl i2c-omap: Enable I2C wakeups for 34xx i2c-omap: reprogram OCP_SYSCONFIG register after reset i2c-omap: convert 'rev1' flag to generic 'rev' u8 i2c-omap: fix I2C timeouts due to recursive omap_i2c_{un,}idle() i2c-omap: Clean-up i2c-omap i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds i2c-omap: Mark init-only functions as __init i2c-omap: Add support for omap34xx i2c-omap: FIFO handling support and broken hw workaround for i2c-omap i2c-omap: Add high-speed support to omap-i2c i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr() i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg Fix up apparently-trivial conflict in drivers/i2c/busses/i2c-s3c2410.c
2008-12-10omap mmc: Add better MMC low-level initTony Lindgren
This will simplify the MMC low-level init, and make it more flexible to add support for a newer MMC controller in the following patches. The patch rearranges platform data and gets rid of slot vs controller confusion in the old data structures. Also fix device id numbering in the clock code. Some code snippets are based on an earlier patch by Russell King <linux@arm.linux.org.uk>. Cc: Pierre Ossman <drzeus-mmc@drzeus.cx> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-11-21i2c-omap: Add high-speed support to omap-i2cSyed Mohammed Khasim
Omap2430 has additional support for high-speed I2C. This patch moves I2C speed parameter (from module) to platform data. Also added basic High Speed support based on I2C bus speed. This patch is tested for high speed I2C (with TWL4030 Keypad) and works as expected. Also change the 2430 i2chs_fck names to use the standard naming. Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Syed Mohammed Khasim <x0khasim@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-08-19ARM: OMAP2: Clockdomain: Associate clocks with clockdomainsPaul Walmsley
Associate each OMAP24xx clock in arch/arm/mach-omap2/clock24xx.h with a clockdomain. Also move the L4 clock up higher in the file in preparation to define the SSI L4 iclk. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-07-03ARM: OMAP2: Clock: New OMAP2/3 DPLL rate rounding algorithmPaul Walmsley
This patch adds a new rate rounding algorithm for DPLL clocks on the OMAP2/3 architecture. For a desired DPLL target rate, there may be several multiplier/divider (M, N) values which will generate a sufficiently close rate. Lower N values result in greater power economy. However, lower N values can cause the difference between the rounded rate and the target rate ("rate error") to be larger than it would be with a higher N. This can cause downstream devices to run more slowly than they otherwise would. This DPLL rate rounding algorithm: - attempts to find the lowest possible N (DPLL divider) to reach the target_rate (since, according to Richard Woodruff <r-woodruff@ti.com>, lower N values save more power than higher N values). - allows developers to set an upper bound on the error between the rounded rate and the desired target rate ("rate tolerance"), so an appropriate balance between rate fidelity and power savings can be set. This maximum rate error tolerance is set via omap2_set_dpll_rate_tolerance(). - never returns a rounded rate higher than the target rate. The rate rounding algorithm caches the last rounded M, N, and rate computation to avoid rounding the rate twice for each clk_set_rate() call. (This patch does not yet implement set_rate for DPLLs; that follows in a future patch.) The algorithm trades execution speed for rate accuracy. It will find the (M, N) set that results in the least rate error, within a specified rate tolerance. It does this by evaluating each divider setting - on OMAP3, this involves 128 steps. Another approach to DPLL rate rounding would be to bail out as soon as a valid rate is found within the rate tolerance, which would trade rate accuracy for execution speed. Alternate implementations welcome. This code is not yet used by the OMAP24XX DPLL clock, since it is currently defined as a composite clock, fusing the DPLL M,N and the M2 output divider. This patch also renames the existing OMAP24xx DPLL programming functions to highlight that they program both the DPLL and the DPLL's output multiplier. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-07-03ARM: OMAP: McBSP: Add support for mcbsp on mach-omap1Eduardo Valentin
This patch adds support for mach-omap1 based on current mcbsp platform driver. Signed-off-by: Eduardo Valentin <eduardo.valentin@indt.org.br> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-04-14ARM: OMAP2: Clean up 24xx clock codeTony Lindgren
Clean up 24xx clock code to sync it with linux-omap tree. Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-04-14ARM: OMAP: Add rest of 24xx clocksPaul Walmsley
This patch adds the rest of clocks for 24xx. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-04-14ARM: OMAP2: Change 24xx to use shared clock code and new reg accessPaul Walmsley
This patch changes 24xx to use shared clock code and new register access. Note that patch adds some temporary OLD_CK defines to keep patch more readable. These temporary defines will be removed in the next patch. Also not all clocks are changed in this patch to limit the size. Also, the patch fixes few incorrect clock defines in clock24xx.h. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-04-14ARM: OMAP2: Move clock.h to clock24xx.hPaul Walmsley
This patch moves clock.h to clock24xx.h to make room for adding common clock code for 24xx and 34xx. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>