Some instances of the DMTIMER peripheral on OMAP devices have the ability
to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER
attribute to indicate which timers can interrupt the DSP. By using the
omap_dm_timer_request_by_cap() API, driver will now be able to allocate
a DMTIMER that can interrupt the DSP based upon this attribute and not require
the driver to know which instance has this capability.

DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as
follows ...

- OMAP1 (OMAP5912/16xx/17xx) devices	- All 8 DMTIMERs
- OMAP2/3/4 devices			- DMTIMERs 5-8

Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and
generate a PWM output.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add gpmc hwmod and associated interconnect data
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
[paul@pwsan.com: added comments to the use of HWMOD_INIT_NO_RESET]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add mmu hwmod data for iva and isp.

Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: fixed some kerneldoc and whitespace; ISP MMUs not present
 on AM35xx so restricted these hwmods to 34xx/36xx]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

SAD2D stands for the die to die interface, and is used for communicating
with the optional stacked modem. This hwmod is added in preparation for
the d2d_idle move from pm34xx.c to hwmod data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
[paul@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx,
 so only add it to the OMAP34xx/OMAP36xx lists]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

As the plat and mach includes need to disappear for single zImage work,
we need to remove plat/hardware.h.

Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.

The old plat/hardware.h already has omap1 only defines, so it gets moved
to mach/hardware.h for omap1. For omap2+, we use the local soc.h
that for now just includes the related SoC headers to keep this patch more
readable.

Note that the local soc.h still includes plat/cpu.h that can be dealt
with in later patches. Let's also include plat/serial.h from common.h for
all the board-*.c files. This allows making the include files local later
on without patching these files again.

Note that only minimal changes are done in this patch for the
drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
patches are needed to eventually remove cpu_is_omap usage in the drivers.

Also only minimal changes are done to sound/soc/omap/* to remove the
unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
no need to include omap44xx.h.

While at it, also sort some of the includes in the standard way.

Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Acked-by: NWim Van Sebroeck <wim@iguana.be>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As the interrupts should only be defined in the platform_data, and
eventually coming from device tree, there's no need to define them
in header files.

Let's remove the hardcoded references to irqs.h and fix up the includes
so we don't rely on headers included in irqs.h. Note that we're
defining OMAP_INTC_START as 0 to the interrupts. This will be needed
when we enable SPARSE_IRQ. For some drivers we need to add
#include <plat/cpu.h> for now until these drivers are fixed to
remove cpu_is_omapxxxx() usage.

While at it, sort som of the includes the standard way, and add
the trailing commas where they are missing in the related data
structures.

Note that for drivers/staging/tidspbridge we just define things
locally.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This way we can remove includes of plat/gpio.h which won't work
with the single zImage support.

Note that we also remove the cpu_class_is_omap2() check
in gpio-omap.c as the drivers should not call it as we need to
make it local to arch/arm/mach-omap2 for single zImage support.

While at it, arrange the related includes in the standard way.

Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-mtd@lists.infradead.org
Cc: alsa-devel@alsa-project.org
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

IVA2 hwmod resets were missing the status bit offsets. Also, as the
hwmod itself didn't have prcm info at all, resetting iva hwmod was
accessing some bogus memory addresses. Added both infos to fix this.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: updated subject line; updated to apply on v3.5-rc4;
 added comments to hwmod data regarding IPSS]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:

omap_hwmod: uart4: softreset failed (waited 10000 usec)

This also results in another warning later in the boot process:

omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state

From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets.  Otherwise
the reset will never complete.  So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process.  (The choice of
uart1_fck over uart2_fck was arbitrary.)

Unfortunately this observation raises many questions.  Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly?  What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like?  If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.

Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>

Add missing terminators to the arrays of IRQ, DMA, and address space
structure records in the AM35xx UART4 hwmod data.  Without these
terminators, the following warnings appear on boot:

omap_uart.3: failed to claim resource 58
omap_device: omap_uart: build failed (-16)
WARNING: at /home/paul/linux/arch/arm/mach-omap2/serial.c:375 omap_serial_init_port+0x198/0x284()
Could not build omap_device for omap_uart: uart4.

Also, AM35xx uart4_fck has an incorrect parent clock pointer.  Fix it
and clean up a whitespace issue.

Fix some incorrectly-named macros related to AM35xx UART4.

Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>

Partially fix the hwmod data for the AM35xx USB OTG hwmod.  This
should resolve the following boot warning on AM35xx platforms:

omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)

While here, also fix the clkdev records, to avoid warnings about
duplicate clock aliases.

The hwmod is also connected to the wrong interconnect.  It should be
connected to the IPSS, not the L4 CORE.  But that is left for a future
fix, since it probably has a dependency on some hwmod core changes.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Hema HK <hemahk@ti.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>

Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The enable/disable module functions are specific to SoCs with
OMAP4-class PRCM.  Rather than use cpu_is* checks at runtime inside
the enable/disable module functions, use cpu_is at init time to
initialize function pointers only for SoCs that need them.

NOTE: the cpu_is* check for _enable_module was different than
      the one for _disable_module, and this patch uses
      cpu_is_omap44xx() for both.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than
 per-hwmod since they do not vary by hwmod; added kerneldoc]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
that OMAP3 devices can use an external clock source.

Rather than use the IP version, just let the clock framework handle this.
If the "alt_ck" does not exist for a timer then the clock framework will fail
to find the clock and hence will return an error. By doing this we can eliminate
the "timer_ip_version" variable passed as part of the platform data and simplify
the code.

We can also remove the timer IP version from the HWMOD data because the dmtimer
driver uses the TIDR register to determine the IP version.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix the following issues with the timer device attributes for OMAP2+ devices:

1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
   that these timers are in an ALWAYS-ON power domain. This is not the case
   only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
   that these timers are in an ALWAYS-ON power domain. This is not the case
   only timer1 and timer12 are in an ALWAYS-ON power domain.
3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
   is in an always-on power domain.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Change the name field value to better reflect the smartreflex
integration in the system.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NJ Keerthy <j-keerthy@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Move the smartreflex header file
(arch/arm/mach-omap2/smartreflex.h) in a new header file
include/linux/power/smartreflex.h.

This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NJ Keerthy <j-keerthy@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Currently cpu_is_omap3517() actually detects any device in the AM35x
family (3517 and no-SGX version 3505.)  To make it more clear what is
being detected, convert the names from 3517 to AM35xx.

This adds a new soc_is_am35xx() which duplicates the cpu_is_omap3517().
In order to avoid cross-tree dependencies with clock-tree changes,
cpu_is_omap3517() is left until the clock changes are merged,
at which point cpu_is_omap3517() will be completely removed.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
[tony@atomide.com: change to use soc_is_omap instead]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Without runtime PM enabled, hwmod needs to leave all IP blocks in an
enabled state by default so any driver access to the HW will succeed.
This is accomplished by seting the postsetup_state to enabled for all
hwmods during init when runtime PM is disabled.

Currently, we have a special case for WDT in that its postsetup_state
is always set to disabled.  This is done so that the WDT is disabled
and the timer is disarmed at boot in case there is no WDT driver.
This also means that when runtime PM is disabled, if a WDT driver *is*
built in the kernel, the kernel will crash on the first access to the
WDT hardware.

We can't simply leave the WDT module enabled, because the timer is
armed by default after reset. That means that if there is no WDT
driver initialzed or loaded before the timer expires, the kernel will
reboot.

To fix this, a custom reset method is added to the watchdog class of
omap_hwmod.  This method will *always* disarm the timer after hwmod
reset.  The WDT timer then will only be rearmed when/if the driver is
loaded for the WDT.  With the timer disarmed by default, we no longer
need a special-case for the postsetup_state of WDT during init, so it
is removed.

Any platforms wishing to ensure the watchdog remains armed across the
entire boot boot can simply disable the reset-on-init feature of the
watchdog hwmod using omap_hwmod_no_setup_reset().

Tested on 3530/Overo, 4430/Panda.

NOTE: on 4430, the hwmod OCP reset does not seem to rearm the timer as
documented in the TRM (and what happens on OMAP3.)  I noticed this
because testing the HWMOD_INIT_NO_RESET feature with no driver loaded,
I expected a reboot part way through the boot, but did not see a
reboot.  Adding some debug to read the counter, I verified that right
after OCP softreset, the counter is not firing.  After writing the
magic start sequence, the timer starts counting.  This means that the
timer disarm sequence added here does not seem to be needed for 4430,
but is technically the correct way to ensure the timer is disarmed, so
it is left in for OMAP4.

Special thanks to Paul Walmsley for helping brainstorm ideas to fix
this problem.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: updated the omap2_wd_timer_reset() function in the
 wake of commit 3c55c1ba ("ARM:
 OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset
 wait for reset status""); added kerneldoc; rolled in warning fix from Kevin]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 & 3 hwmod table.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and the OMAP4 hwmod data
will be using the same name.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the HDQ1W hwmod for OMAP34xx, OMAP36xx, and AM3505/3517 devices.
According to the respective TRMs, it doesn't appear to be available for the
816x/814x or the AM335x.

The OCPIF_SWSUP_IDLE flag is added to work around an apparent hardware
bug: the hardware is not taking the CM_FCLKEN*_CORE.EN_HDQ bit into
account when considering whether to go idle:

    http://www.spinics.net/lists/linux-omap/msg63576.html

This causes HDQ transfers to fail or become corrupt.  Thanks to
NeilBrown for his help diagnosing and testing fixes for this problem.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NNeilBrown <neilb@suse.de>

The IVA hwmod data is missing some fields that cause the following
warning on boot:

[    0.118011] omap_hwmod: iva: cannot be enabled for reset (3)

Fix by encoding the IP block's main functional clock, reset lines, and
clockdomain.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP3 hwmod data listed iva2_ck as an interface clock between the
IVA and L3.  This is incorrect.  iva2_ck is not an interface clock.
Since it cannot auto-idle, specifying it here prevents the IVA and at
least one of the CORE clockdomains from going idle, which causes PM
problems such as these upon system suspend:

[   70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1
[   70.626190] Powerdomain (core_pwrdm) didn't enter target state 1

Fix by specifying the actual interface clock in the hwmod data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Reorganize the hwmod data to declare the IP blocks first and the
interconnects second.  This allows us to remove the forward
declarations, which this patch also does. Saves some lines of source
data.  While here, take the opportunity to synchronize the order of
the OMAP44xx hwmod data with the autogenerator output -- it's slightly
different due to past mismerges -- and fix a few minor typos and
whitespace problems in the files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Register interconnect links between IP blocks, rather than the IP
blocks themselves.  (The IP blocks will be registered as a side-effect
of registering the links.)

The objective is to reduce the number of lines of static data and
facilitate the sharing of IP block data between different SoCs.  These
objectives come at the penalty of increased boot time due to increased
computation.

While here, fix a few whitespace problems and inaccurate variable names.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

GPTIMER12 is attached to the L4 SEC interconnect, not directly to L4 WKUP.
Add the L4 SEC interconnect and attach GPTIMER12 to it.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the
OMAP3430 ES1 DSS hwmod.  Since the hwmod code and data is being modified
to register interfaces rather than hwmods, this would result in the DSS hwmod
not being registered correctly on OMAP3430ES1.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit a52e2ab6 ("ARM: OMAP3: hwmod
data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1")
didn't link the MMC hwmods to the interconnects correctly.  Future
patches will register hwmods by interface, so if this is not fixed,
the MMC IP blocks won't be registered.  Update the interface data
records to point to the correct IP blocks.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some of the 2xxx and 3xxx hwmod data files use the old naming style
for hwmods, ending in a "_hwmod".  These names are used by the OMAP
integration code to map hwmods to platform_devices, so they need to be
consistent, or the platform_devices won't be created.  Remove the
_hwmod suffix to conform with the rest of the OMAP SoC data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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>

Add OMAP3 SmartReflex IRQs in hwmod structures. Without these IRQs
being registered the SmartReflex driver will be unable to get the
IRQ numbers to handle notifications.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR. The value of the field must match
the voltage domain names for the binding to be effective.

Tested on OMAP3630 SDP, OMAP3530 Beagleboard and
OMAP4430 SDP Board.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NShweta Gulati <shweta.gulati@ti.com>
Acked by: Nishanth Menon <nm@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

dss_core has to be initialized before any other DSS hwmod. Currently
this is broken as dss_core is listed in chip/revision specific hwmod
lists while other DSS hwmods are listed in common list which is
registered first.

This patch moves DSS hwmods (except for dss_core) to the separate list
which is registered last to ensure that dss_core is already registered.

This solves the problem with BUG() in L3 interrupt handler on boards
with DSS enabled in bootloader.

The long-term fix to this is to ensure modules are set up in dependency
order in the hwmod core code.

CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
CC: Archit Taneja <archit@ti.com>
CC: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NIlya Yanok <yanok@emcraft.com>
[paul@pwsan.com: add notes that this is just a temporary workaround until
 hwmod dependencies are added]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

dispc's sysc_flags is missing SYSC_HAS_ENAWAKEUP flag. This seems to
cause SYNC_LOST errors from the DSS when the power management is
enabled.

This patch adds the missing SYSC_HAS_ENAWAKEUP flag. Note that there are
other flags missing also (clock activity, DSI's sysc flags), but as they
are not critical, they will be fixed in the next merge window.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently OMAP2 and 3 share the same omap_hwmod_class and
omap_hwmod_class_sysconfig for dispc. However, OMAP3 has sysconfig
bits that OMAP2 doesn't have, so we need to split those structs into
OMAP2 and OMAP3 specific versions.

This patch only splits the structs, without changing the contents.
This is a prerequisite for a subsequent fix.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
[paul@pwsan.com: added commit note]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

For I2C clockactivity field is added for OMAP3 and OMAP4 that defines how the
interface (OCP) and functional (system) clocks behave when the I2C module is
idle.

The configuration of the clock activity bit field (per TRM) is as follows:
0x0: Both clocks can be cut off
0x1: Only OCP clock must be kept active; system clock
     can be cut off
0x3: Both clocks must be kept active
0x2: Only system clock must be kept active; OCP clock
     can be cut off

The patch makes 0x2(CLOCKACT_TEST_ICLK) the default for OMAP3 and OMAP4.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The HSMMC1/HSMMC2 host controllers on OMAP34xx and
OMAP3503/3515/3525/3530 chips at ES levels prior to 3.0 can't do multiple
block reads[1].  Mark the hwmod data appropriately.

Reported by Dave Hylands <dhylands@gmail.com> and Steve Sakoman
<sakoman@gmail.com>.  Thanks to Steve Sakoman for further help
testing this patch.

1. See for example Advisory 2.1.1.128 "MMC: Multiple Block Read
   Operation Issue" in _OMAP3530/3525/3515/3503 Silicon Errata_
   Revision F (October 2010) (SPRZ278F), available from
   http://focus.ti.com/lit/er/sprz278f/sprz278f.pdfSigned-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>

Following 2 hwmod structures are added
    1. usb_host_hs
         The hwmod of usbhs with uhh, ehci and ohci base addresses
         functional clock and ehci, ohci irqs

    2. usb_tll_hs
          hwmod of usbhs with the TLL base address and irq.
Signed-off-by: NKeshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: NPartha Basak <parthab@india.ti.com>
[paul@pwsan.com: fixed whitespace; removed nonexistent TLL->L3 interface;
 added master & slave for L4 CORE->TLL interface; skip registration on
 3430ES1; fixed multiline comment style; updated to apply on Tony's cleanup
 branch; rebased]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>