Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The driver for the TFP410 DPI-to-DVI chip was named quite badly as "DVI
panel driver". This patch renames the code to use tfp410 name for the
driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The current serial UART code, while fidling with ocp idlemode bits,
forget about the smart idle wakeup bit even if it is supported by
UART IP block. This will lead to missing the module wakeup on OMAP's
where the smart idle wakeup is supported.

This was the root cause of the console sluggishness issue, I have been
observing on OMAP4 devices and also can be potential reason for some
other UART wakeup issues.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit (7496ba30  ARM: OMAP2+: UART: Add default mux for all uarts)
wrongly added muxing of default pads for all uarts. This causes
breakage on multiple boards using uart pins for alternate functions.

For example, on zoom3 random oopses can be seen with nfsroot as
the smsc911x ethernet FIFO timings on GPMC bus are controlled
by gpmc_wait2 and gpmc_wait3 pins. This means we can't mux these
pads to uart4 functionality as commit 7496ba30 was doing.

Not all boards tend to use all uarts and most of unused uart pins
are muxed for other purpose. This commit breaks the modules which
where trying to use unused uart pins on their boards.

So remove the default pad muxing. Note that this is not a complete
fix, as we now rely on bootloader set muxing for the uart wake-up
events. Further patching is needed to enable wake-up events for
uarts that are already muxed to uart mode.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: NRuss Dill <russ.dill@gmail.com>
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
[tony@atomide.com: updated comments to describe oops on zoom3]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Complete the separation of the twl6040 from the twl core since
it is a separate chip, not part of the twl6030 PMIC.

Make the needed Kconfig changes for the depending drivers at the
same time to avoid breaking the kernel build (vibra, ASoC components).
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonicro.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

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: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The clocks for all DSS slave interfaces were recently changed to "dss_ick" on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and
hence the OCPIF_SWSUP_IDLE flag was needed.

Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is
now "dss_ick".  This allows the PRCM hardware to autoidle the VENC
interface clocks when they are not active, rather than relying on the
software to do it, which can keep the interface clocks active
unnecessarily.
Signed-off-by: NArchit Taneja <archit@ti.com>
[paul@pwsan.com: add a short description of the fix to the commit log]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This reverts commit f9a2f9c3.  This
commit caused a regression in the I2C hwmod reset on OMAP2/3/4,
logging messages similar to these during boot:

[    0.200378] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
[    0.222076] omap_hwmod: i2c2: softreset failed (waited 10000 usec)

While the original patch was intended to fix some reset-related timing
issues, it's believed that these problems were actually fixed by
commit 2800852a ("ARM: OMAP2+: hwmod:
Restore sysc after a reset"):

    http://marc.info/?l=linux-arm-kernel&m=133410322617245&w=2

Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Due to HW limitation, some IPs should not be accessed just after a
softreset. Since the current hwmod sequence is accessing the sysconfig
register just after the reset, it might lead to OCP bus error in
that case.

Add a new field in the sysconfig structure to specify a delay in usecs
needed after doing a softreset.

In the case of the ISS and FDIF modules, the L3 OCP port will be
disconnected upon a SW reset. That issue was confirmed with HW simulation
and an errata should be available soon. The HW recommendation to avoid
that is to wait for 100 OCP clk cycles, before accessing the IP.

Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
so a 1 usec delay is needed. Add an x2 margin to be safe.
Acked-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
 yet upstream; the FDIF change will need to be added later once the FDIF
 data is merged]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

omap_hwmod_softreset() does not seem to wait for reset status
after doing a softreset. Make it use _ocp_softreset() instead
which does this correctly.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

After a softreset, make sure the sysc settings are correctly
restored.
Reported-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
[paul@pwsan.com: combined post-reset SYSCONFIG reload code into the
 _reset() function to avoid duplication and future mistakes]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available (ex: usb
host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring pad mux wakeup
capability.

Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
[paul@pwsan.com: updated function kerneldoc documentation]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Several clocks are missing clockdomains.  This can cause problems with
the hwmod and power management code.  Fill these in.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Matt Porter <mporter@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>

All DPLLs except USB are in ALWON powerdomain. Make sure the
clkdm/pwrdm for USB DPLL (l3init) is turned on before attempting
a DPLL relock. So, mark the database accordingly.

Without this fix, it was seen that DPLL relock fails while testing
relock in a loop of USB DPLL.

Cc: Nishanth Menon <nm@ti.com>
Tested-by: NAmeya Palande <ameya.palande@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

According to OMAP4 TRM Table 3-1183, CM_CLKSEL_DPLL_USB register defines
following fields for multiplication and division factors:

DPLL_MULT (bits 19:8) DPLL multiplier factor (2 to 4095)
DPLL_DIV (bits 7:0) DPLL divider factor (0 to 255)
Acked-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NAmeya Palande <ameya.palande@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit b1cbdb00 ("OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup") was assuming that
pwrdm_state_switch() does wait for the powerdomain transition which is
not the case.  The missing wait for the powerdomain transition
violates the sequence which the hardware expects, which causes power
management failures on some devices.

Fix this API by adding the pwrdm_wait_transition().
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[paul@pwsan.com: added some more details in the commit log]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Rename EMAC clocks to match driver expectations: both davinci_emac and
davinci_mdio drivers call clk_get(dev, NULL) so we have to provide
("davinci_emac", NULL) and ("davinci_mdio.0", NULL) clocks instead of
("davinci_emac", "emac_clk") and ("davinci_emac", "phy_clk") resp.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NIlya Yanok <yanok@emcraft.com>
Tested-by: NYegor Yefremov <yegorslists@googlemail.com>
Tested-by: NMatt Porter <mporter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

CLKS signal for McBSP ports can be selected from internal (PRCM) or
external (ABE_CLKS pin) source.  To be able to use existing code we
need to create clock aliases consistent among OMAP2/3/4.

Based on a patch from Péter Ujfalusi <peter.ujfalusi@ti.com>;
the patch description above is his.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

Commit 2a9f5a4d "OMAP3 clock: remove unnecessary duplicate of dpll4_m2_ck,
added for 36xx" consolidated dpll4 clock structures between 34xx and 36xx,
but left 34xx CLKSEL masks for most dpll4 related clocks, which causes
clock code to not behave correctly when booting on DM3730 with higher
(36xx only) divisors set:
[    0.000000] WARNING: at arch/arm/mach-omap2/clkt_clksel.c:375 omap2_init_clksel_parent+0x104/0x114()
[    0.000000] clock: dpll4_m3_ck: init parent: could not find regval 0
[    0.000000] WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 omap2_clksel_recalc+0xd4/0xe4()
[    0.000000] clock: Could not find fieldval 0 for clock dpll4_m3_ck parent dpll4_ck

Fix this by switching to 36xx masks, as valid divisors will be limited
by clksel_rate lists.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

If transceiver is attached to a MMC host of ES2.1 OMAP35xx, it seems
2.1.1.128 erratum doesn't apply and there is no data corruption,
probably because of different signal timing. The workaround for this
erratum disables multiblock reads, which causes dramatic loss of
performance (over 75% slower), so avoid it when transceiver is present.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
[paul@pwsan.com: edited commit message slightly]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
the emu_sys clockdomain data in mainline is incorrect.

The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>

Fix the below section mismatch warning and alike:

WARNING: vmlinux.o(.text+0x281d4): Section mismatch in reference from
the function setup_ehci_io_mux() to the function
.init.text:omap_mux_init_signal()
The function setup_ehci_io_mux() references
the function __init omap_mux_init_signal().
This is often because setup_ehci_io_mux lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Initialize fixed regulators in the board files. Trying to
do this in a generic way in gpmc-smsc911x.c gets messy as
the regulator may be provided by drivers, such as twl4030,
for some boards.
Signed-off-by: NRuss Dill <russ.dill@ti.com>
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
[tony@atomide.com: combined into one patch, updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Adding in support for regulators here creates several headaches.
 - Boards that declare their own regulator cannot use this function.
 - Multiple calls to this function require special handling.
 - Boards that declare id's other than '0' need special handling.

Now that there is a simple regulator_register_fixed, we can push
this registration back into the board files.
Signed-off-by: NRuss Dill <russ.dill@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Looking back into git history, this code was never used and was
probably left over from a copy/paste.
Signed-off-by: NRuss Dill <russ.dill@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If this function is called the first time with flags set, and the
second time without flags set then the leftover flags from the first
called will be used rather than the desired default flags.
Signed-off-by: NRuss Dill <russ.dill@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This seems to be a leftover from when gpmc-smsc911x.c was copied
from gpmc-smc91x.c.
Signed-off-by: NRuss Dill <russ.dill@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>

arch/arm/kernel/io.c: In function '_memcpy_toio':
arch/arm/kernel/io.c:29: error: implicit declaration of function 'outer_sync'
arch/arm/mach-omap2/omap_l3_noc.c: In function 'l3_interrupt_handler':
arch/arm/mach-omap2/omap_l3_noc.c:100: error: implicit declaration of function 'outer_sync'
kernel/irq/generic-chip.c: In function 'irq_gc_mask_disable_reg':
kernel/irq/generic-chip.c:45: error: implicit declaration of function 'outer_sync'
kernel/sched/rt.c: In function 'rt_set_overload':
kernel/sched/rt.c:248: error: implicit declaration of function 'outer_sync'
...
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix the compilation break observed on latest mainline caused
by 9f97da78 (Disintegrate asm/system.h for ARM):

arch/arm/mach-omap1/pm.c: In function 'omap_pm_prepare':
arch/arm/mach-omap1/pm.c:587: error: implicit declaration of function 'disable_hlt'
arch/arm/mach-omap1/pm.c: In function 'omap_pm_finish':
arch/arm/mach-omap1/pm.c:624: error: implicit declaration of function 'enable_hlt'
arch/arm/mach-omap1/pm.c: In function 'omap_pm_init':
arch/arm/mach-omap1/pm.c:681: error: 'arm_pm_idle' undeclared (first use in this function)
...

arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin':
arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt'
arch/arm/mach-omap2/pm.c: In function 'omap_pm_end':
arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt'
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
[tony@atomide.com: updated to fix omap1 too]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The following commits change gpio-omap to use dynamic
IRQ allocation:

25db711d gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1c gpio/omap: Add DT support to GPIO driver

With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We must be using gpio_to_irq() instead.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Disintegrate asm/system.h for ARM.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Russell King <linux@arm.linux.org.uk>
cc: linux-arm-kernel@lists.infradead.org

External circuitry like level shifters may limit the maximum operation
speed of the hsmmc controller. Add a field to struct omap2_hsmmc_info
so boards can adjust the setting on demand.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes the oops below[1].

Obviously, the count of "struct irq_chip_generic" instances to be
allocated and setup should be irq_setup->nr_regs instead of
irq_setup->nr_regs plus one, so just fix the iterator to avoid
the oops.

[1], oops log.

[    1.790242] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[    1.798632] pgd = c0004000
[    1.801638] [00000004] *pgd=00000000
[    1.805400] Internal error: Oops: 805 [#1] PREEMPT SMP THUMB2
[    1.811381] Modules linked in:
[    1.814601] CPU: 1    Not tainted  (3.3.0-next-20120320+ #733)
[    1.820683] PC is at irq_setup_generic_chip+0x6a/0x84
[    1.825951] LR is at irq_get_irq_data+0x7/0x8
[    1.830508] pc : [<c006465e>]    lr : [<c0063a03>]    psr: 20000133
[    1.830512] sp : ee04ff58  ip : 00000000  fp : 00000000
[    1.842461] r10: 00000000  r9 : 00000000  r8 : 00000800
[    1.847905] r7 : c064e260  r6 : 000001dc  r5 : 00000001  r4 : ee0accc0
[    1.854687] r3 : 00000002  r2 : 00000800  r1 : 000001dc  r0 : 00000000
[    1.861472] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment kernel
[    1.869234] Control: 50c5387d  Table: 8000404a  DAC: 00000015
[    1.875215] Process swapper/0 (pid: 1, stack limit = 0xee04e2f8)
[    1.881463] Stack: (0xee04ff58 to 0xee050000)
[    1.886017] ff40: c061b668 00000008
[    1.894497] ff60: c0682090 ee0accc0 00000003 c001c637 00000000 00000000 00000201 00000000
[    1.902976] ff80: 00000004 c0473820 c0473800 c0459e8d c0680ac0 c000866d 00000004 00000004
[    1.911455] ffa0: ee04ffa8 00000004 c047381c 00000004 c0473820 c0473800 c0680ac0 00000082
[    1.919934] ffc0: c0489694 c045265f 00000004 00000004 c0452135 c000d105 00000033 00000000
[    1.928413] ffe0: c04525b5 c000d111 00000033 00000000 00000000 c000d111 aaaaaaaa aaaaaaaa
[    1.936912] [<c006465e>] (irq_setup_generic_chip+0x6a/0x84) from [<c001c637>] (omap_prcm_register_chain_handler+0x147/0x1a0)
[    1.948516] [<c001c637>] (omap_prcm_register_chain_handler+0x147/0x1a0) from [<c000866d>] (do_one_initcall+0x65/0xf4)
[    1.959500] [<c000866d>] (do_one_initcall+0x65/0xf4) from [<c045265f>] (kernel_init+0xab/0x138)
[    1.968529] [<c045265f>] (kernel_init+0xab/0x138) from [<c000d111>] (kernel_thread_exit+0x1/0x6)
[    1.977632] Code: f7ff f9d1 6b23 1af3 (6043) 086d
[    1.982684] ---[ end trace 1b75b31a2719ed1c ]---
[    1.987526] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

On platforms such as OMAP3, certain variants may not have IVA, SGX
or some specific component. We currently have a check to aid fixing
wrong population of OPP entries for issues such as typos. This however
causes a conflict with valid requirement where the SoC variant does
not actually have the module present.

So, reduce the severity of the print to a debug statement and skip
registering that specific OPP, but continue down the list.
Reported-by: NSteve Sakoman <steve@sakoman.com>
Reported-by: NMaximilian Schwerin <mvs@tigris.de>
Acked-by: NSteve Sakoman <steve@sakoman.com>
Tested-by: NMaximilian Schwerin <mvs@tigris.de>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Currently, pm34xx.c has a mix of printk() and pr_*() statements
so replace the printk() statements with the equivalent pr_*()
statements.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

It appears that the error paths were overlooked when the
omap3_pm_init() routine had the prcm chain handler code
added.  Fix this by adding a goto target and reordering
the error handling code.  Also fix how the irq argument
for free_irq() is determined.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.

The issue is due to the synchronization methodology used in the SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.

Further investigation revealed that it applies to gptimer1 and watchdog timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.

The BUG has not made it yet to the OMAP errata list and it is applicable to
OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps.

By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU
is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces
the OCP clock to be running and allow the counter value to be updated properly
in the OCP clock domain.

The bug is going to fixed in future OMAP versions.

Reported-Tested-by: dave.long@linaro.org
[dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer
and helped to test this patch]
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

With the introduction of dynamically allocated IRQ in the twl6030 driver,
the board files can no longer rely of static IRQ defines like before.

Retrieve the value dynamically allocated from the mmc -> twl6030 init
callback.

Note: The Panda board does not seems to use the card detect IRQ.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: NRobert Lee <rob.lee@linaro.org>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Reviewed-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NLen Brown <len.brown@intel.com>