Commit Graph

233986 Commits

Author SHA1 Message Date
Shweta Gulati
273032f782 OMAP4: Enable 800 MHz and 1 GHz MPU-OPP
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-11 07:21:44 -08:00
Vishwanath BS
15f13e23e8 OMAP3+: OPP: Replace voltage values with Macros
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-11 07:21:44 -08:00
Paul Walmsley
a08572ae52 Merge remote branch 'remotes/origin/voltage_split_2.6.39' into tmp-integration-2.6.39-20110310-024
Conflicts:
	arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
2011-03-10 22:43:32 -07:00
Paul Walmsley
2d403fe030 Merge remote branch 'remotes/origin/hwmod_a_2.6.39' into 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-10 22:43:05 -07:00
Paul Walmsley
21ace5452c Merge remote branches 'remotes/origin/pwrdm_clkdm_b_2.6.39', '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-10 22:41:28 -07:00
Paul Walmsley
2f4dd595f6 OMAP3: wdtimer: Fix CORE idle transition
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-10 22:40:06 -07:00
Paul Walmsley
0503add9d2 Watchdog: omap_wdt: add fine grain runtime-pm
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-10 22:40:05 -07:00
Paul Walmsley
c0718df4d6 OMAP2+: voltage: reorganize, split code from data
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-10 22:17:45 -07:00
Tero Kristo
4ce1e5e14c omap2/3: dmtimer: Enable autoidle
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-10 03:50:54 -07:00
Paul Walmsley
570b54c7fa OMAP2+: clockdomain: add flag that will block autodeps from being added for 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-10 03:50:09 -07:00
Kishon Vijay Abraham I
9599217a06 OMAP2+: hwmod: add API to handle autoidle mode
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-10 03:50:08 -07:00
Paul Walmsley
43b0164335 OMAP2+: hwmod: allow board files to prevent devices from being reset upon init
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-10 03:50:07 -07:00
omar ramirez
cc1226e763 OMAP2+: hwmod: use status bit info for reset line
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-10 03:23:56 -07:00
Paul Walmsley
4d2274c543 OMAP2+: hwmod: fix a documentation bug with HWMOD_NO_OCP_AUTOIDLE
The documented name of the HWMOD_NO_OCP_AUTOIDLE flag was incorrect; fix it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-10 03:23:56 -07:00
Rajendra Nayak
09c35f2fee OMAP2+: hwmod: Fix what _init_clock returns
_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-10 03:23:55 -07:00
Avinash.H.M
d73d65fab1 omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
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-10 03:23:55 -07:00
Tarun Kanti DebBarma
8985b63d07 OMAP2+: hwmod: fix incorrect computation of autoidle_mask
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-10 03:23:55 -07:00
Benoit Cousson
478f478bc1 OMAP3: hwmod data: Remove masters port links for interconnects.
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-10 11:18:50 +01:00
Benoit Cousson
b9ccf8afe2 OMAP3: hwmod data: Fix incorrect SmartReflex -> L4 CORE interconnect links
Commit d344272671 ("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-10 11:04:00 +01:00
Paul Walmsley
692ab1f36b MAINTAINERS: add entry for OMAP powerdomain/clockdomain per-SoC layer support
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-09 18:44:28 -07:00
Felipe Balbi
b481cea34b OMAP: clock: fix compile warning
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-09 18:44:28 -07:00
Tony Lindgren
0dde52a9f5 Merge branch 'omap-l3-for-next' of git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base into omap-for-linus 2011-03-09 13:15:49 -08:00
Paul Walmsley
c39bee8ac4 OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interface
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-09 13:03:15 -08:00
Santosh Shilimkar
2722e56de6 OMAP4: l3: Introduce l3-interconnect error handling driver
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-09 17:23:58 +05:30
sricharan
a4dc616ae3 OMAP4: Initialise the l3 device with the hwmod data.
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-09 17:23:57 +05:30
sricharan
c464523488 OMAP4: hwmod_data: Add address space and irq in L3 hwmod.
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-09 17:23:57 +05:30
Felipe Balbi
e2fa61d409 OMAP3: l3: Introduce l3-interconnect error handling driver
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-09 17:23:57 +05:30
sricharan
0abcf6185e OMAP3: devices: Initialise the l3 device with the hwmod data.
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-09 17:23:56 +05:30
sricharan
4bb194dc94 OMAP3: hwmod_data: Add address space and irq in L3 hwmod.
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-09 17:23:56 +05:30
Abhilash Vadakkepat Koyamangalath
0640b436e4 audio : AM3517 : Adding i2c info for AIC23 codec
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-08 15:20:41 -08:00
Paul Walmsley
e7916740bb OMAP1: McBSP: fix build break for non-multi-OMAP1 configs
Commit 3cf32bba8c ("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-08 15:10:17 -08:00
Paul Walmsley
8c810e7e14 OMAP2xxx: clock data: clean up some comments
Minor cleanup of some clock data comments.  No functional changes.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-07 20:21:17 -07:00
Paul Walmsley
a4fc92748e OMAP2xxx: clock: fix clockdomains on gpt7_ick, 2430 mmchs2_fck clocks
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-07 20:21:17 -07:00
Sanjeev Premi
691abf525d omap2/3: clockdomains: fix compile-time warnings
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-07 20:21:17 -07:00
Paul Walmsley
224113969d OMAP2xxx: clock: remove dsp_irate_ick
After commit 81b34fbecb ("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-07 20:21:17 -07:00
Paul Walmsley
241d3a8dca OMAP2+: clock: remove the DPLL rate tolerance code
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-07 20:19:40 -07:00
Paul Walmsley
e07f469d28 OMAP: clock: bail out early if arch_clock functions not implemented
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-07 20:19:39 -07:00
Paul Walmsley
19c1c0ce9d OMAP2xxx: clock: fix interface clocks and clockdomains for modules in the 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-07 20:19:39 -07:00
Paul Walmsley
3f9cfd3a47 OMAP2xxx: clock: fix low-frequency oscillator clock rate
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-07 20:19:39 -07:00
Paul Walmsley
a1fed577dd OMAP2xxx: clock: fix parents for L3-derived clocks
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-07 20:19:39 -07:00
Paul Walmsley
e1d6f4729e OMAP: voltage: move plat/voltage.h to mach-omap2/voltage.h
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-07 20:05:08 -07:00
Paul Walmsley
7328ff4d72 OMAP: smartreflex: move plat/smartreflex.h to mach-omap2/smartreflex.h
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-07 20:05:08 -07:00
Paul Walmsley
4ef70c0694 OMAP2/3: PM: remove manual CM_AUTOIDLE bit setting in mach-omap2/pm*xx.c
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-07 20:04:15 -07:00
Paul Walmsley
ec538e30f7 OMAP3: clock: use autoidle clkops for all autoidle-controllable interface 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-07 20:04:03 -07:00
Paul Walmsley
a1d5562315 OMAP2430: clock: use autoidle clkops for all autoidle-controllable interface 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-07 20:03:44 -07:00
Paul Walmsley
e892b2528b OMAP2430/3xxx: clock: add modem clock autoidle support
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-07 20:03:12 -07:00
Paul Walmsley
6ae690da1b OMAP2420: clock: use autoidle clkops for all autoidle-controllable interface 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-07 20:02:57 -07:00
Paul Walmsley
a56d9ea865 OMAP2420: clock: add sdrc_ick
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>
2011-03-07 20:02:38 -07:00
Paul Walmsley
530e544fda OMAP2+: clock: add interface clock type code with autoidle support
Add interface clock type code with autoidle enable/disable support.
The clkops structures created in this file will be used for all
OMAP2/3 interface clocks with autoidle support.  They will enable the
clock framework to control interface clock autoidle directly.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07 20:02:30 -07:00
Paul Walmsley
cc1d230cfb OMAP2+: clock: comment that osc_ck/osc_sys_ck should use clockfw autoidle control
Place some comments in the OMAP oscillator clock control code to note that
its autoidle mode should eventually be controlled via the new OMAP clockfw
autoidle control interface.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-03-07 20:02:21 -07:00