summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-03-11OMAP4: Add IVA OPP enteries.Shweta Gulati
This Patch adds OPP enteries for IVA in OMAP4 OPP Table Tested on OMAP4430 SDP Board. Signed-off-by: Shweta Gulati <shweta.gulati@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-11OMAP4: Update Voltage Rail Values for MPU, IVA and COREShweta Gulati
Update MPU, IVA and CORE voltage Rail values obtained from OMAP4430 Data Manual Operating Condition Addendum_v0.4. Tested on OMAP4430 SDP Board. Signed-off-by: Shweta Gulati <shweta.gulati@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-11OMAP4: Enable 800 MHz and 1 GHz MPU-OPPShweta Gulati
Almost all OMAP4 boards support OPP 800 MHz and OPP 1 GHz. Enable them in OPP Table. For small minority of boards which use OMAP4430-800 MHz device OPP 1GHz is not supported, OPP 1GHz should be disabled from board file. Signed-off-by: Shweta Gulati <shweta.gulati@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-11OMAP3+: OPP: Replace voltage values with MacrosVishwanath BS
Since all voltage data is now centralized in oppxxx_data.c, we can replace the values in the opp table with the macros used for voltage values. This will avoid opp table and voltage layer having conflicting values. Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-10Merge remote branch 'remotes/origin/voltage_split_2.6.39' into ↵Paul Walmsley
tmp-integration-2.6.39-20110310-024 Conflicts: arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
2011-03-10Merge remote branch 'remotes/origin/hwmod_a_2.6.39' into ↵Paul Walmsley
tmp-integration-2.6.39-20110310-024 Conflicts: arch/arm/mach-omap2/omap_hwmod_2430_data.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c arch/arm/plat-omap/include/plat/omap_hwmod.h
2011-03-10Merge remote branches 'remotes/origin/pwrdm_clkdm_b_2.6.39', ↵Paul Walmsley
'remotes/origin/pwrdm_add_can_lose_context_fns_2.6.39', 'remotes/origin/omap_device_a_2.6.39', 'remotes/origin/mmc_a_2.6.39', 'remotes/origin/hwmod_b_2.6.39', 'remotes/origin/dmtimer_a_2.6.39', 'remotes/origin/pwrdm_clkdm_a_2.6.39', 'remotes/origin/clkdm_statdep_omap4_2.6.39', 'remotes/origin/clk_a_2.6.39', 'remotes/origin/clk_autoidle_a_2.6.39', 'remotes/origin/clk_autoidle_b_2.6.39', 'remotes/origin/clk_b_2.6.39', 'remotes/origin/clk_clkdm_a_2.6.39', 'remotes/origin/misc_a_2.6.39', 'remotes/origin/for_2.6.39/omap3_hwmod_data' and 'remotes/origin/wdtimer_a_2.6.39' into tmp-integration-2.6.39-20110310-024
2011-03-10OMAP3: wdtimer: Fix CORE idle transitionPaul Walmsley
The HW superwised smart idle for wdtimer in OMAP3 prevents CORE power domain idle transitions. Disable it by swithing to SW supervised transitions. This could be a hardware bug in the OMAP3 wdtimer2 block. Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@ti.com>
2011-03-10Watchdog: omap_wdt: add fine grain runtime-pmPaul Walmsley
The omap_wdt should only be in full active state when the registers are being accessed. Otherwise the device can be on lower power mode. This patch is based on a patch created by Kalle Jokiniemi: https://patchwork.kernel.org/patch/618231/ which is itself based on a patch created by Atal Shargorodsky: http://lkml.org/lkml/2009/3/10/266. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com> Tested-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com> Cc: Wim Van Sebroeck <wim@iguana.be> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Kevin Hilman <khilman@ti.com>
2011-03-10OMAP2+: voltage: reorganize, split code from dataPaul Walmsley
This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-10omap2/3: dmtimer: Enable autoidleTero Kristo
This saves some power. OMAP4 version should check for GPT module ID, as autoidle is only supported on a subset of these. Signed-off-by: Tero Kristo <tero.kristo@nokia.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10OMAP2+: clockdomain: add flag that will block autodeps from being added for ↵Paul Walmsley
a clockdomain Add a new clockdomain flag, CLKDM_NO_AUTODEPS, which, when marked on a clockdomain, will prevent "autodeps" from being associated with the clockdomain. ("Autodeps" are sleep dependencies and wakeup dependencies from/to processor modules that are automatically added to a clockdomain when it is in hardware-supervised idle mode. They are deprecated -- a relic from the old CDP trees -- but are still in use for OMAP3.) Also, prevent the hwmod code from adding or removing initiator dependencies for clockdomains with this flag set. This patch should allow others to test which clockdomains actually still need autodeps. Thanks to Kevin Hilman <khilman@ti.com> for noting that the original version should also modify the hwmod code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-10OMAP2+: hwmod: add API to handle autoidle modeKishon Vijay Abraham I
Create a new API that forms a wrapper to _set_module_autoidle() to modify the AUTOIDLE bit. This API is intended to be used by drivers that requires direct manipulation of the AUTOIDLE bits in SYSCONFIG register. McBSP driver requires autoidle bit to be enabled/disabled while using sidetone feature. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: restrict the hwmod states that the autoidle bit can be changed in; changed function name; dropped "int" from "unsigned int long"] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10OMAP2+: hwmod: allow board files to prevent devices from being reset upon initPaul Walmsley
Some boards can't tolerate IP blocks being reset when they are initialized. Michael Büsch cites a case with the Nokia N810: http://www.spinics.net/lists/linux-omap/msg47277.html To allow such boards to continue working normally, allow board file maintainers to mark IP blocks to prevent them from being reset upon init. This is done via a hwmod function, omap_hwmod_no_setup_reset(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Michael Buesch <mb@bu3sch.de>
2011-03-10OMAP2+: hwmod: use status bit info for reset lineomar ramirez
On OMAP2 and OMAP3 the reset ctrl shift doesn't match the status bit, as it does on OMAP4, when handling the reset lines. This patch adds a new member in the reset info structure, so now it can be added as part of hwmod data, and checked accordingly for OMAP2 or 3; otherwise, there could be cases when the shift masks doesn't match both of the registers, and a successful reset might throw an error message or vice versa. Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com> [paul@pwsan.com: added a warning if st_shift used on OMAP4; renamed 'r' variable; improved some documentation] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10OMAP2+: hwmod: fix a documentation bug with HWMOD_NO_OCP_AUTOIDLEPaul Walmsley
The documented name of the HWMOD_NO_OCP_AUTOIDLE flag was incorrect; fix it. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10OMAP2+: hwmod: Fix what _init_clock returnsRajendra Nayak
_init_clock always returns 0 and does not propogate the error (in case of failure) back to the caller, causing _init_clocks to fail silently. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10omap: hwmod: add syss reset done flags to omap2, omap3 hwmodsAvinash.H.M
Some of the omap2, omap3 peripherals support software reset. This can be done through the softreset bit in sysconfig register. The reset status can be checked through resetdone bit of sysstatus register. syss_has_reset_status is added to the hwmod database of peripherals which have resetdone bit in sysstatus register. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Reviewed-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Avinash.H.M <avinashhm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10OMAP2+: hwmod: fix incorrect computation of autoidle_maskTarun Kanti DebBarma
Autoidle is a single bit, TIOCP_CFG[0], setting on OMAP1/2/3/4 platforms. In _set_module_autoidle() I am seeing 0x3 value where the mask is computed. This should be 0x1. v2: (1) Modified the subject. (2) Modified the description with further specific information. Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tested Info: Boot tested on OMAP 1/2/3/4. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10OMAP3: hwmod data: Remove masters port links for interconnects.Benoit Cousson
Master ports from interconnect are generating some annoying circular references that become tricky to handle if we have to dynamically remove some IP on some variant platforms. Since they are not used for the moment, and since we can still build that relation using the reverse relation (slave port from the IP toward master port of the interconnect), let remove them for the moment like it is done on OMAP4. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com>
2011-03-10OMAP3: hwmod data: Fix incorrect SmartReflex -> L4 CORE interconnect linksBenoit Cousson
Commit d34427267186827dfd62bd8cf726601fffb22534 ("OMAP3: PM: Adding smartreflex hwmod data") added data that claims that the L4 CORE has two slave interfaces that originate from the SmartReflex modules, omap3_l4_core__sr1 and omap3_l4_core__sr2. But as those two data structure records show, it's L4 CORE that has a master port towards SR1 and SR2. Move the incorrect data from slaves list to master list. Based on a path by Paul Walmsley <paul@pwsan.com> https://patchwork.kernel.org/patch/623171/ That is based on a patch by Benoît Cousson <b-cousson@ti.com>: https://patchwork.kernel.org/patch/590561/ Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Cc: Sanjeev Premi <premi@ti.com> Cc: Thara Gopinath <thara@ti.com>
2011-03-09MAINTAINERS: add entry for OMAP powerdomain/clockdomain per-SoC layer supportPaul Walmsley
Add Rajendra Nayak and myself as maintainers for the OMAP powerdomain/clockdomain per-SoC layer code. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-09OMAP: clock: fix compile warningFelipe Balbi
if building kernels without OMAP2 support, we will see a warning such as: arch/arm/mach-omap2/io.c: In function 'omap2_init_common_infrastructure': arch/arm/mach-omap2/io.c:389:3: warning: statement with no effect arch/arm/mach-omap2/io.c:391:3: warning: statement with no effect Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-09Merge branch 'omap-l3-for-next' of ↵Tony Lindgren
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base into omap-for-linus
2011-03-09OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interfacePaul Walmsley
According to the hwmod interface data, the DSS submodule "VENC" uses a clock, "dss_54m_fck"/"dss_tv_fck", which the PRCM cannot autoidle. By default, the hwmod code assumes that interface clocks can be autoidled by the PRCM. When the interface clock can't be autoidled by the PRCM, those interfaces must be marked with the OCPIF_SWSUP_IDLE flag. Otherwise, the "interface clock" will always have a non-zero use count, and the device won't enter idle. This problem was observed on N8x0. Fix the immediate problem by marking the VENC interface with the OCPIF_SWSUP_IDLE flag. But it's not clear that "dss_54m_fck"/"dss_tv_fck" is really the correct interface clock for VENC. It may be that the VENC interface should use a hardware-autoidling interface clock. This is the situation on OMAP4, which uses "l3_div_ck" as the VENC interface clock, which can be autoidled by the PRCM. Clarification from TI is needed. Problem found and patch tested on N8x0 by Tony Lindgren <tony@atomide.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Senthilvadivu Guruswamy <svadivu@ti.com> Cc: Sumit Semwal <sumit.semwal@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-09OMAP4: l3: Introduce l3-interconnect error handling driverSantosh Shilimkar
The driver provides the information regarding the ocp errors that gets logged in the interconnect. The error information gives the detail regarding the target that was attempted to be accessed and its corresponding address. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-03-09OMAP4: Initialise the l3 device with the hwmod data.sricharan
The l3 interconnect device is build with all the data required to handle the error logging. The data is extracted from the hwmod data base. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: sricharan <r.sricharan@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-03-09OMAP4: hwmod_data: Add address space and irq in L3 hwmod.sricharan
Add the address spaces, irqs of the l3 interconnect to the hwmod data. The hwmod change is aligned with Benoit Cousson. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: sricharan <r.sricharan@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-03-09OMAP3: l3: Introduce l3-interconnect error handling driverFelipe Balbi
The driver provides the information regarding the ocp errors that gets logged in the interconnect.The error info provides the details regarding the master or the target that generated the error, type of error and the corresponding address. The stack dump is also provided. Signed-off-by: sricharan <r.sricharan@ti.com> [r.sricharan@ti.com: Enhacements, major cleanup and made it functional] Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [santosh.shilimkar@ti.com: Driver design changes as per OMAP4 version] Signed-off-by: Felipe Balbi <balbi@ti.com> [balbi@ti.com: Initial version of the driver] Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-03-09OMAP3: devices: Initialise the l3 device with the hwmod data.sricharan
The l3 interconnect device is build with all the data required to handle the error logging. The data is extracted from the hwmod database. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-03-09OMAP3: hwmod_data: Add address space and irq in L3 hwmod.sricharan
Add the address spaces, irqs of the l3 interconnect to the hwmod data. The hwmod changes are aligned with Benoit Cousson. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-03-08audio : AM3517 : Adding i2c info for AIC23 codecAbhilash Vadakkepat Koyamangalath
The i2c_board_info entry supporting AIC23 codec was added into the i2c2 bus. Signed-off-by: Abhilash K V <abhilash.kv@ti.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-08OMAP1: McBSP: fix build break for non-multi-OMAP1 configsPaul Walmsley
Commit 3cf32bba8ca0e0052ca41d74d455a5805b7fea85 ("OMAP: McBSP: Convert McBSP to platform device model") breaks compilation with non-multi-OMAP1 configs: CC arch/arm/mach-omap1/mcbsp.o arch/arm/mach-omap1/mcbsp.c: In function 'omap1_mcbsp_init': arch/arm/mach-omap1/mcbsp.c:384: warning: dereferencing 'void *' pointer arch/arm/mach-omap1/mcbsp.c:387: error: invalid use of void expression arch/arm/mach-omap1/mcbsp.c:390: warning: dereferencing 'void *' pointer arch/arm/mach-omap1/mcbsp.c:393: error: invalid use of void expression Fix by avoiding NULL dereferences. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> [tony@atomide.com: updated description not to remove unnecessary branch name] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-07OMAP2xxx: clock data: clean up some commentsPaul Walmsley
Minor cleanup of some clock data comments. No functional changes. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP2xxx: clock: fix clockdomains on gpt7_ick, 2430 mmchs2_fck clocksPaul Walmsley
Add a clockdomain to the GPTIMER7 interface and 2430 HSMMC2 functional clocks - both were previously missing them. Also, the 2430 mmchs1_fck is in core_l3_clkdm, but should be in core_l4_clkdm; fix this. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07omap2/3: clockdomains: fix compile-time warningsSanjeev Premi
This patch fixes these warnings when building kernel for OMAP3EVM only. CC arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.o arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:95: warning: 'dsp_24xx_wkdeps' defined but not used arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:119: warning: 'mpu_24xx_wkdeps' defined but not used arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:147: warning: 'core_24xx_wkdeps' defined but not used The problem should be noticed when building for other OMAP3 platforms (only) as well. Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP2xxx: clock: remove dsp_irate_ickPaul Walmsley
After commit 81b34fbecbfbf24ed95c2d80d5cb14149652408f ("OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files"), it's possible to remove dsp_irate_ick from the OMAP2420 and OMAP2430 clock files. It was originally only needed due to a 2420/2430 clock tree difference, and now that the data is in separate files, it's superfluous. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP2+: clock: remove the DPLL rate tolerance codePaul Walmsley
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-03-07OMAP: clock: bail out early if arch_clock functions not implementedPaul Walmsley
Bail out before we take the clockfw_lock spinlock if the corresponding OMAP1 or OMAP2+ clock function is not defined. The intention is to reduce and simplify the work that is done inside the spinlock. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP2xxx: clock: fix interface clocks and clockdomains for modules in the ↵Paul Walmsley
WKUP domain The parent of the interface clocks for GPTIMER1, MPU_WDT, SYNCTIMER_32K, SCM, WDT1, and the ICR (2430 only) were all listed as being l4_ck. This isn't accurate; these modules exist inside the WKUP domain, and the interface clock to these modules runs at the SYS_CLK rate rather than the CORE L4 rate. So, create a new clock "wu_l4_ick", similar to the OMAP3 "wkup_l4_ick", that serves as the parent for these clocks. Also, these clocks were listed as existing inside core_l4_clkdm; wkup_clkdm is probably more accurate. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP2xxx: clock: fix low-frequency oscillator clock ratePaul Walmsley
The OMAP2420/2430 external 32-kHz low-frequency oscillator is a 32768 Hz oscillator, not a 32,000 Hz oscillator[1][2]. Fix this in the clock tree. Signed-off-by: Paul Walmsley <paul@pwsan.com> 1. OMAP2420/22 Multimedia Processor Data Manual, Version P [SWPS019P], section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to a "32.768-kHz" clock; this presumably should be "32.768-KHz") 2. OMAP2430 Multimedia Processor ES2.1 Data Manual, Version V [SWPS023V], section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to a "32.768-kHz" clock; this presumably should be "32.768-KHz")
2011-03-07OMAP2xxx: clock: fix parents for L3-derived clocksPaul Walmsley
Several clocks are listed as having the core L4 clock as their parent, when they are actually derived from the L3 clock. Fix these. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP: voltage: move plat/voltage.h to mach-omap2/voltage.hPaul Walmsley
At this point in time, there's no reason for this header file to be in plat-omap/include/plat/voltage.h. It should not be included by device drivers, and the code that uses it is currently all under mach-omap2/. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07OMAP: smartreflex: move plat/smartreflex.h to mach-omap2/smartreflex.hPaul Walmsley
There's no reason for this header file to be in plat-omap/include/plat/smartreflex.h. The hardware devices are in OMAP2+ SoCs only. Leaving this header file in plat-omap causes problems due to cross-dependencies with other header files that should live in mach-omap2/. Thanks to Benoît Cousson <b-cousson@ti.com> for suggesting the removal of the smartreflex.h include from the OMAP3xxx hwmod data. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2011-03-07OMAP2/3: PM: remove manual CM_AUTOIDLE bit setting in mach-omap2/pm*xx.cPaul Walmsley
These CM_AUTOIDLE bits are now set by the clock code via the common PM code in mach-omap2/pm.c. N.B.: The pm24xx.c code that this patch removes didn't ensure that the CM_AUTOIDLE bits were set for several 2430-only modules, such as GPIO5, MDM_INTC, MMCHS1/2, the modem oscillator clock, and USBHS. Similarly, the pm34xx.c code that this patch removes didn't ensure that the CM_AUTOIDLE bits were set for USIM and the AM3517 UART4. Those cases should now be handled. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07OMAP3: clock: use autoidle clkops for all autoidle-controllable interface clocksPaul Walmsley
Mark each interface clock with a corresponding CM_AUTOIDLE bit with a clkops that has the allow_idle/deny_idle function pointers populated. This allows the OMAP clock framework to enable and disable autoidle for these clocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07OMAP2430: clock: use autoidle clkops for all autoidle-controllable interface ↵Paul Walmsley
clocks Mark each interface clock with a corresponding CM_AUTOIDLE bit with a clkops that has the allow_idle/deny_idle function pointers populated. This allows the OMAP clock framework to enable and disable autoidle for these clocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07OMAP2430/3xxx: clock: add modem clock autoidle supportPaul Walmsley
OMAP2430 and OMAP3xxx have modem autoidle bits that are actually attached to clocks with CM_FCLKEN bits; add the code and data to handle these. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07OMAP2420: clock: use autoidle clkops for all autoidle-controllable interface ↵Paul Walmsley
clocks Mark each interface clock with a corresponding CM_AUTOIDLE bit with a clkops that has the allow_idle/deny_idle function pointers populated. This allows the OMAP clock framework to enable and disable autoidle for these clocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07OMAP2420: clock: add sdrc_ickPaul Walmsley
Add sdrc_ick to the OMAP2420 clock data so the clock code can control the CM_AUTOIDLE bit associated with this clock. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
generated by cgit (git 2.34.1) at 2025-05-05 19:47:58 +0000