summaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap/include/plat/clock.h
AgeCommit message (Collapse)AuthorFilesLines
2012-10-18ARM: OMAP: remove plat/clock.hPaul Walmsley1-309/+0
Remove arch/arm/plat-omap/include/plat/clock.h by merging it into arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h. The goal here is to facilitate ARM single image kernels by removing includes via the "plat/" symlink. Signed-off-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: fixed to remove duplicate clock.h includes] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-22ARM: OMAP2+: clock: Remove all direct dereferencing of struct clkRajendra Nayak1-0/+5
While we move to Common Clk Framework (CCF), direct deferencing of struct clk wouldn't be possible anymore. Hence get rid of all such instances in the current clock code and use macros/helpers similar to the ones that are provided by CCF. While here also concatenate some strings split across multiple lines which seem to be needed anyway. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: simplified some compound expressions; reformatted some messages] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Mike Turquette <mturquette@linaro.org>
2012-06-18ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_dataKevin Hilman1-2/+0
There are certain fields inside 'struct dpll_data' which are included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it difficult to use it for new devices like, am33xx, ti81xx, etc... So remove the ifdef completely, this will add few fields to the struct unused, but it improves readability and maintainability of the code. Signed-off-by: Kevin Hilman <khilman@ti.com> [hvaibhav@ti.com: wrote detailed changelog] Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: R Sricharan <r.sricharan@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-04-14ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errorsKevin Hilman1-10/+0
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no longer need/use the clock framework code for filling up CPUfreq tables. Remove it. Removing this code also eliminates build errors when CPU_FREQ_TABLE support is not enabled. Thanks to Russell King for pointing out the parts I missed under plat-omap in the original version and also pointing out the build errors when CPUFREQ_TABLE support was not enabled. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Kevin Hilman <khilman@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-12-13ARM: OMAP: TI814X: Add cpu type macros and detection supportHemant Pedanekar1-0/+1
This patch adds cpu type, macros for identification of TI814X device. Signed-off-by: Hemant Pedanekar <hemantp@ti.com> [tony@atomide.com: left out CK_TI814X for now] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-13ARM: OMAP: am33xx: Update common omap platform filesAfzal Mohammed1-1/+2
This patch updates the common platform files with AM335X device support (AM33XX family). The approach taken in this patch is, AM33XX device will be considered as OMAP3 variant, and a separate SoC class created for AM33XX family of devices with a subclass type for AM335X device, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks will return success on AM335X device. A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3 to include support for AM33XX build. Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: Afzal Mohammed <afzal@ti.com> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Hemant Pedanekar <hemantp@ti.com> [tony@atomide.com: left out CK_AM33XX for now] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-10ARM: OMAP: Fix dpll_data compile error when omap2 only is selectedTony Lindgren1-1/+1
Without this patch we get the following error: arch/arm/mach-omap2/clkt_dpll.c: In function '_dpll_test_fint': arch/arm/mach-omap2/clkt_dpll.c:98: error: 'struct dpll_data' has no member named 'flags' Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-14OMAP: id: remove OMAP_CHIP declarations, codePaul Walmsley1-2/+0
Now that all of the users of the OMAP_CHIP bitfield code have been converted to use lists, the OMAP_CHIP code, data, and declarations can be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-26Merge branch 'next/soc' of ↵Linus Torvalds1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc * 'next/soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc: MAINTAINERS: add maintainer of CSR SiRFprimaII machine ARM: CSR: initializing L2 cache ARM: CSR: mapping early DEBUG_LL uart ARM: CSR: Adding CSR SiRFprimaII board support OMAP4: clocks: Update the clock tree with 4460 clock nodes OMAP4: PRCM: OMAP4460 specific PRM and CM register bitshifts OMAP4: ID: add omap_has_feature for max freq supported OMAP: ID: introduce chip detection for OMAP4460 ARM: Xilinx: merge board file into main platform code ARM: Xilinx: Adding Xilinx board support Fix up conflicts in arch/arm/mach-omap2/cm-regbits-44xx.h
2011-07-09OMAP4: clock data: Fix max mult and div for USB DPLLBenoit Cousson1-1/+1
The DPLL USB can generate higher speed (x2) than the regular ones. The max multiplication value is then twice the previous value. Fix both max_mult and max_div with that correct values. Change the max_div variable type to u16 to allow storing up to 256. Replace as well the define with the value to avoid unneeded indirection and provide a better readability. Remove the defines that become useless. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-08OMAP4: clocks: Update the clock tree with 4460 clock nodesRajendra Nayak1-0/+2
Add the new clock nodes (bandgap_ts_fclk, div_ts_ck) for omap4460. Handle these nodes using the clock flags (CK_*). Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-07OMAP2+: clock: remove the DPLL rate tolerance codePaul Walmsley1-6/+1
Remove the DPLL rate tolerance code that is called during rate rounding. As far as I know, this code is never used, since it's been more important for callers of the DPLL round_rate()/set_rate() functions to obtain an exact rate than it is to save a relatively small amount of power. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-02-25OMAP4: DPLL: Add dpll api to control GATE_CTRLRajendra Nayak1-1/+13
On OMAP4, the dpll post divider outputs (MX outputs) along with clockout_x2 output provide a way to allow/deny hardware level autogating. Allowing autoidle would mean that the hw would autogate this clock when there is no dependency for it. Denying idle would mean that this clock output will be forced to stay enabled. Add dpll api's to read/allow/deny idle control for these dpll mx postdividers. NOTE: The gatectrl bit set to 0 allows gatectrl, and the bit set to 1 denies gatectrl. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: moved OMAP4-specific DPLL control code to mach-omap2/dpll44xx.c; added some documentation for CLOCK_CLKOUTX2] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-02-25OMAP: clock: Add allow_idle/deny_idle support in clkopsRajendra Nayak1-0/+6
On OMAP various clock nodes (dpll's, mx post dividers, interface clocks) support hardware level autogating which can be controlled from software. Support such functionality by adding two new function pointer allow_idle and deny_idle in the clkops structure. These function pointers can be populated for any clock node which supports hardware level autogating. Also add 2 new functions (omap_clk_enable_autoidle_all and omap_clk_disable_autoidle_all) which can be called from architecture specific PM core code, if hardware level autogating (for all supported clock nodes) is to be enabled or disabled. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use spinlock rather than mutex due to race; renamed functions; functions now return ints] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-02-16TI816X: Update common omap platform filesHemant Pedanekar1-0/+1
This patch updates the common platform files with TI816X support. The approach taken in this patch is to add TI816X as part of OMAP3 variant where the cpu class is considered as OMAP34XX and the type is TI816X. This means, both cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X. A kernel config option CONFIG_SOC_OMAPTI816X is added under OMAP3 to include support for TI816X build. Signed-off-by: Hemant Pedanekar <hemantp@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-21OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4Jon Hunter1-2/+3
J-Type DPLLs have additional configuration parameters that need to be programmed when setting the multipler and divider for the DPLL. These parameters being the sigma delta divider (SD_DIV) for the DPLL and the digital controlled oscillator (DCO) to be used by the DPLL. The current code is implemented specifically to configure the OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL and so this code needs to be updated to work for both OMAP3 and OMAP4 devices and any other future devices that have J-TYPE DPLLs. For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are used but for the OMAP4430 USB DPLL only the SD_DIV field is used. The current implementation will only program the SD_DIV and DCO fields if the DPLL has both and hence this does not work for OMAP4430. In order to make the code more generic add two new fields to the dpll_data structure for the SD_DIV field and DCO field bit-masks and only program these fields if the masks are defined for a specific DPLL. This simplifies the code and allows us to remove the flag DPLL_NO_DCO_SEL. Tested on OMAP36xx Zoom3 and OMAP4 Blaze. Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*() functions; added testing info to commit message; added 35xx comments back in] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpuPaul Walmsley1-3/+8
Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505, etc.). Superset flags, such as CK_3XXX or CK_AM35XX, are now defined as disjunctions of individual SoC variant flags. This simplifies the definition and use of these flags. struct omap_clk record definitions can now simply specify the bitmask of actual SoCs that the records are valid for. The clock init code can simply set a single CPU type mask bit for the SoC that is currently in use, and test against that, rather than needing to set some combination of flags. Similarly, clarify the use of struct clksel_rate.flags. The bit allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has been defined as a disjunction of the 34xx and 36xx rate flags. The advantages are the same as the above. Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only apply to the SoCs that they name, e.g., OMAP34xx chips. The previous practice caused significantly different SoCs, such as OMAP36xx, to be included in CK_34XX. In my opinion, this is much more intuitive. Similarly, clarify the use of struct clksel_rate.flags, such that RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2 - it does not apply to OMAP36xx. ... At some point, it probably makes sense to collapse the CK_* and RATE_IN_* flags together into a single bitfield, and possibly use the existing CHIP_IS_OMAP* flags for platform detection. ... This all seems to work fine on OMAP34xx and OMAP36xx Beagle. Not sure if it works on Sitara or the TI816X, unfortunately I don't have any here to test with. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: clock: add kerneldoc for structures; move flags closer to structsPaul Walmsley1-23/+107
Add kerneldoc for struct clk, struct clksel_rate, struct clksel. Move flag macros for struct clk.flags and struct clksel_rate.flags closer to the structures. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-05-20OMAP3 clock: rename RATE_IN_343X, RATE_IN_3430ES2 to match realityPaul Walmsley1-1/+2
Rename the RATE_IN_343X clksel_rate.rate flag to be RATE_IN_3XXX, to reflect that these rates are valid on all OMAP3 platforms, not just 343X. Also rename the RATE_IN_OMAP3430ES2 clksel_rate.rate flag to be RATE_IN_OMAP3430ES2PLUS, to reflect that these flags are valid on all OMAP3 platforms after 3430ES2. This patch should not result in any functional changes. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Ranjith Lohithakshan <ranjithl@ti.com>
2010-05-20OMAP2+ clock: remove DEFAULT_RATE clksel_rate flagPaul Walmsley1-7/+6
The DEFAULT_RATE clksel_rate flag is essentially useless. It was set on some of the lowest divisors, which, when switching to a much higher-rate parent, could have potentially resulted in rates that exceeded the hardware specifications for downstream clocks in the window between the clk_set_parent(), and a subsequent clk_set_rate(). It seems much safer to just remove the flag and always use the highest available divisor (resulting in the lowest possible rate) after the switch, and this patch does so. Ideally, it would be best to first attempt to switch to a divisor that matches the clock's rate with the previous parent, if at all possible. But that is a project for some other day or some other person. The parent changing code is rarely used. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24OMAP4: clock: Add dummy clock nodes for interface clocksSantosh Shilimkar1-0/+2
On OMAP4 platform the iclk control is completly under hardware control and no software control is available. This difference w.r.t previous OMAP's needs all the common driver accross OMAP's , cpu_is_xxxx() checks. To avoid poulluting the drivers dummy clock nodes are created (The autogeneration script has been updated accordingly). Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: made OMAP1 dummy_ck common and edited patch to reuse that] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core codePaul Walmsley1-0/+1
The OMAP hwmod core code is intended to use SoC IP block description structures that are autogenerated from TI's OMAP hardware database. Currently the hwmod code uses clkdev device + connection addressing to identify clocks. This causes problems in the hwmod autogeneration process, since the TI hardware database doesn't use platform_device or clkdev addressing; it uses a single clock signal name string, which tends to bear some resemblance to what is used in the OMAP TRMs. This patch adds a non-exported function to the OMAP clock code, omap_clk_get_by_name(). A subsequent patch will convert the hwmod code to use this function. This function is for use only by core code, and practically, no other code outside the hwmod code should need it. Device driver code in the kernel must not use this function, which is why it is not exported. Drivers should use the appropriate clock alias provided by the clkdev data structures, so driver code can be completely SoC-independent. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-24OMAP4 clock: drop the ALWAYS_ENABLED clock flagPaul Walmsley1-1/+0
Get rid of the ALWAYS_ENABLED clock flag - it doesn't actually do anything. (The OMAP4 clock autogeneration scripts have been updated accordingly.) Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Benoît Cousson <b-cousson@ti.com>
2010-02-24OMAP clock: drop RATE_FIXED clock flagPaul Walmsley1-7/+6
The RATE_FIXED clock flag is pointless. In the OMAP1 clock code, it simply causes the omap1_clk_round_rate() function to return the current rate of the clock. omap1_clk_round_rate(), however, should never be called for a fixed-rate clock, since none of these clocks have a .round_rate function pointer set in their struct clk records. Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes the clock code to emit a warning if the OMAP clock maintainer was foolish enough to add a .round_rate function pointer to a fixed-rate clock. "Doctor, it hurts when I pretend that a fixed-rate clock is rate-changeable." "Then don't pretend that a fixed-rate clock is rate-changeable." It has no functional value. This patch drops the RATE_FIXED clock flag, removing it from all clocks that are so marked. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-02-24OMAP2 clock: drop DELAYED_APP clock flagPaul Walmsley1-4/+3
All of the clocks that are marked with DELAYED_APP are changed as part of the virt_prcm_set OPP virtual clock. On 24xx, these clocks all need to be changed as part of a group to keep the clock tree functional - hence the need for the VALID_CONFIG bit, which is not present on later OMAPs. These clocks should not be rate-changed independently. So prevent these clocks from being changed independently by dropping their .round_rate and .set_rate function pointers. It then turns out that the DELAYED_APP clock flag is no longer useful, so drop it and the associated code and renumber the clock flags. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-02-24OMAP clock: drop .id field; ensure each clock has a unique namePaul Walmsley1-1/+0
After the clkdev conversion, the struct clk.id field became superfluous, so, drop it. Bring the clock names closer to the TRMs and ensure they are unique for debugfs. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24OMAP clock: compress clock flags down to a u8Paul Walmsley1-15/+9
There are now only eight OMAP clock flags, so renumber the flags to fit in a u8 and shrink the size of struct clk.flags from a u32 to a u8. The intention is to save memory. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24OMAP2 clock: drop CONFIG_PARTICIPANT clock flagPaul Walmsley1-1/+1
It turns out that the only purpose of the CONFIG_PARTICIPANT clock flag is to prevent omap2_clk_set_rate() and omap2_clk_set_parent() from being executed on clocks with that flag set. The rate-changing component can be more directly accomplished by dropping the .set_rate and .round_rate function pointers from those CONFIG_PARTICIPANT struct clks. As far as the parent-changing component is concerned, it turns out that none of the CONFIG_PARTICIPANT clocks have multiple parent choices, so all that is necessary is for omap2_clk_set_parent() to bail out early if the new parent is equal to the old parent. Implement this change and get rid of the flag, which has always had a confusing name (it appears to be a Kconfig option, falsely). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-02-24OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flagPaul Walmsley1-2/+2
The CLOCK_IN_OMAP4430 clock flag is not currently needed in the OMAP4 ES1 clock tree, and platform discrimination via clock flags is deprecated in favor of the clkdev mechanism, so, drop it. (The OMAP4 clock tree autogeneration script has been updated accordingly.) Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-02-24OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, ↵Paul Walmsley1-12/+52
includes, documentation The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are one increment higher than they should be. See for example the OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into the DPLL's M register bitfield is valid for OMAP2/3 and indicates that the DPLL should enter MN-bypass mode. Also, increase the minimum multiplier (M) value for the DPLL rate rounding code from 1 to 2, to ensure that it does not inadvertently put the DPLL into bypass. Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs does not make clear that the actual DPLL divider value (the "N") is the content of the appropriate register bitfield for the N value, _plus one_. (In other words, an N register bitfield of 0 indicates a DPLL divider value of 1.) This is only clearly documented in the OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167 "CM_CLKSEL_DPLL_USB". While here, update copyrights, add kerneldoc for struct dpll_data, drop the unused struct dpll_data.max_tolerance field, remove some unnecessary #includes in DPLL-related code, and replace the #include of <linux/module.h> with <linux/list.h>, which is what was really needed. The OMAP4 clock autogenerator script has been updated accordingly. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-02-24OMAP3 clock: Introduce 3630 DPLL4 HSDivider changesVishwanath BS1-2/+3
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit in 3630. This patch has changes to accommodate this in CM dynamically based on chip version. Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and M6 and value of these nodes are used if cpu type is 3630. Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> [paul@pwsan.com: updated to apply on 2.6.34 queue; comments added] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24OMAP3 clock: introduce DPLL4 JtypeRichard Woodruff1-0/+5
DPLL4 for 3630 introduces a changed block called j type dpll, requiring special divisor bits and additional reg fields. To allow for silicons to use this, this is introduced as a flag and is enabled for 3630 silicon. OMAP4 also has j type dpll for usb. Tested with 3630 ZOOM3 and OMAP3430 ZOOM2 Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vishwanath BS <Vishwanath.bs@ti.com> [paul@pwsan.com: added some comments; updated copyrights and credits; fixed some style issues] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24OMAP2/3 clock: Extend find_idlest() to pass back idle state valueRanjith Lohithakshan1-2/+4
Current implementation defines clock idle state indicators based on the cpu information (cpu_is_omap24xx() or cpu_is_omap34xx()) in a system wide manner. This patch extends the find_idlest() function in clkops to pass back the idle state indicator for that clock, thus allowing idle state indicators to be defined on a per clock basis if required. This is specifically needed on AM35xx devices as the new IPSS clocks indicates the idle status (0 is idle, 1 is ready) in a way just opposite to how its handled in OMAP3 (0 is ready, 1 is idle). Signed-off-by: Ranjith Lohithakshan <ranjithl@ti.com> [paul@pwsan.com: updated to apply after commit 98c45457 et seq.] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-15omap2/3/4: Replace orred CONFIG_ARCH_OMAP2/3/4 with CONFIG_ARCH_OMAP2PLUSTony Lindgren1-4/+2
omap: Replace orred CONFIG_ARCH_OMAP2/3/4 with CONFIG_ARCH_OMAP2PLUS Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-01-29OMAP clock: resolve all remaining sparse warningsPaul Walmsley1-1/+1
Resolve all remaining sparse warnings in the OMAP clock code. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-26OMAP clock: make the fixed divisor clock code available for all OMAPsPaul Walmsley1-1/+2
One of the OMAP1 clocks can use the fixed divisor recalculation code introduced in the OMAP2 clock code, so rename the omap2_fixed_divisor_recalc() function to omap_fixed_divisor_recalc() and make it available to all OMAPs. A followup patch converts the OMAP1 clock. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-08OMAP clock/CPUFreq: add clk_exit_cpufreq_table()Paul Walmsley1-0/+2
A subsequent patch adds code on OMAP2xxx to dynamically allocate the CPUFreq frequency table in clk_init_cpufreq_table(), so for it to avoid a leak, it will need a corresponding function to free the memory. This patch adds clk_exit_cpufreq_table() with generic code to call a chip-specific variant inside the clockfw_lock spinlock via struct clk_functions. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-12-11ARM: OMAP4: PM: OMAP4 clock tree and clkdev registrationRajendra Nayak1-0/+3
This patch defines all the clock nodes in OMAP4430 platform. All the clock node structs and the clkdev table is autogenerated using a python script (gen_clock_tree.py) developed by Paul Walmsley, Benoit Cousson and Rajendra Nayak. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com>
2009-12-11OMAP2 clock: convert clock24xx.h to clock2xxx_data.c, opp2xxx*Paul Walmsley1-0/+2
The OMAP2 clock code currently #includes a large .h file full of static data structures. Instead, define the data in a .c file. Russell King <linux@arm.linux.org.uk> proposed this new arrangement: http://marc.info/?l=linux-omap&m=125967425908895&w=2 This patch also deals with most of the flagrant checkpatch violations. While here, separate the prcm_config data structures out into their own files, opp2xxx.h and opp24{2,3}0_data.c, and only build in the OPP tables for the target device. This should save some memory. In the long run, these prcm_config tables should be replaced with OPP code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Nishanth Menon <nm@ti.com>
2009-10-20omap: headers: Move remaining headers from include/mach to include/platTony Lindgren1-0/+163
Move the remaining headers under plat-omap/include/mach to plat-omap/include/plat. Also search and replace the files using these headers to include using the right path. This was done with: #!/bin/bash mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" headers=$(cd $mach_dir_old && ls *.h) omap_dirs="arch/arm/*omap*/ \ drivers/video/omap \ sound/soc/omap" other_files="drivers/leds/leds-ams-delta.c \ drivers/mfd/menelaus.c \ drivers/mfd/twl4030-core.c \ drivers/mtd/nand/ams-delta.c" for header in $headers; do old="#include <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: Tony Lindgren <tony@atomide.com>