The CLKCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of a offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update cm_xxx accessor, move definition to the proper header file and
update copyrights.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Todd Poynor <toddpoynor@google.com>
[paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; removed empty
 fn prototype section from cm44xx.h; incorporated comments from Todd;
 documented some functions]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

At boot time, lookup the clkdm_name to get the clkdm
structure pointer for further usage.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In OMAP PRCM terminology, the clock domain is defined as a group of IPs
that share some clocks and most of the time an interface clock.
Every IP does belong to a clockdomain.
For the moment the clock domain attribute is affected to a clock node.
The issue with that approach, is that a clock might or not belong to a
clock domain. Moreover during module transition, it is up to a module
to handle properly the clock domain state and not to a clock node.

Create a clkdm_name attribute to provide this information per hwmod.

Populate this attribute for every OMAP4 hwmod entries.

Future cleanup series with remove that information from the OMAP4 clock
when it is relevant.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: fix the mpuss_clkdm name]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
special sequence to reset the module. The sequence is
 - Disable the I2C.
 - Write to SOFTRESET bit.
 - Enable the I2C.
 - Poll on the RESETDONE bit.
The sequence is implemented as a function and the i2c_class is updated with
the correct 'reset' pointer.  omap_hwmod_softreset function is implemented
which triggers the softreset by writing into sysconfig register. On following
this sequence, i2c module resets properly and timeouts are not seen.

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>
Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
[paul@pwsan.com: combined this patch with a patch to remove
 HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register
 offset conditional code to use the IP block revision; minor code
 cleanup]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Previously, struct omap_hwmod_dma_info arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array.  However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.

So far this hasn't been a problem.  However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file.  When this is done, ARRAY_SIZE() will no longer be usable.

This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info
arrays and uses a sentinel value (irq == -1) as the array terminator
instead.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Previously, struct omap_hwmod_mpu_irqs arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array.  However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.

So far this hasn't been a problem.  However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file.  When this is done, ARRAY_SIZE() will no longer be usable.

This patch removes ARRAY_SIZE() usage for struct omap_hwmod_mpu_irqs
arrays and uses a sentinel value (irq == -1) as the array terminator
instead.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Previously, struct omap_hwmod_addr_space arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array.  However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.

So far this hasn't been a problem.  However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file.  When this is done, ARRAY_SIZE() will no longer be usable.

This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space
arrays and uses a null structure member as the array terminator
instead.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The commit 86009eb3 was adding
the wakeup support for new OMAP4 IPs. This support is incomplete for
busmaster IPs that need as well to use smart-standby with wakeup.

This new standbymode is suported on HSI and USB_HOST_FS for the moment.

Add the new MSTANDBY_SMART_WKUP flag to mark the IPs that support this
capability.

Enable this new mode when applicable in _enable_wakeup, _disable_wakeup,
_enable_sysc and _idle_sysc.

The omap_hwmod_44xx_data.c will have to be updated to add this new flag.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NDjamil Elaidi <d-elaidi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This avoids going through the list unnecessarily when
idling devices for runtime PM.

Based on an earlier patch by sricharan <r.sricharan@ti.com>.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

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: NKishon 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: NPaul Walmsley <paul@pwsan.com>

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: NPaul Walmsley <paul@pwsan.com>
Cc: Michael Buesch <mb@bu3sch.de>

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: NOmar 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: NPaul Walmsley <paul@pwsan.com>

The documented name of the HWMOD_NO_OCP_AUTOIDLE flag was incorrect; fix it.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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: NPaul Walmsley <paul@pwsan.com>

Add omap_hwmod_setup_one(), which is intended for use early in boot to
selectively setup the hwmods needed for system clocksources and
clockevents, and any other hwmod that is needed in early boot.
omap_hwmod_setup_all() can then be called later in the boot process.
The point is to minimize the amount of code that needs to be run
early.
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: Tony Lindgren <tony@atomide.com>

Rename omap_hwmod_init() to omap_hwmod_register().  Rename
omap_hwmod_late_init() to omap_hwmod_setup_all().  Also change all of
the callers to reflect the new names.  While here, update some
copyrights.

Suggested by Tony Lindgren <tony@atomide.com>.

N.B. The comment in mach-omap2/serial.c may no longer be correct, given
     recent changes in init order.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Adds support for resource API to get address space info other than just MPU.
The drivers can now use platform_get_resource_byname() to get resource of
type 'IORESOURCE_MEM' by name.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise things will fail with early_init changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This allows adding hwmod specific pads dynamically during the
platform device init.

Note that we don't currently have the hwmod specific signals
listed in the hwmod data, but struct omap_hwmod_mux_info will
make that possible if necessary.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch extends the device hwmod structure to contain
info about the voltage domain to which the device belongs to.
This is needed to support a device based DVFS where the
device knows which voltage domain it belongs to.
Signed-off-by: NThara Gopinath <thara@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by
creating similar APIs at the omap_device and omap_hwmod levels.  The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to get the
context loss count.

The new APIs return an unsigned value that can wrap as the
context-loss count grows.  However, the wrapping is not important as
the role of this function is to determine context loss by checking for
any difference in subsequent calls to this function.

Note that these APIs at each level can return zero when no context
loss is detected, or on errors.  This is to avoid returning error
codes which could potentially be mistaken for large context loss
counters.

NOTE: only works for devices which have been converted to use
      omap_device/omap_hwmod.

Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup.

This new idlemode replaces the enawakeup for the new IPs but seems to
coexist as well for some legacy IPs (UART, GPIO, MCSPI...)

Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this
capability.
The omap_hwmod_44xx_data.c will have to be updated to add this new flag.

Enable this new mode when applicable in _enable_wakeup, _enable_sysc and
_idle_sysc.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Tested-by: NSebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>

Do not allow omap_hwmod_register to be used outside the core
hwmod code. An omap_hwmod should be registered only at init time.
Remove the omap_hwmod_unregister that is not used today since the
hwmod list will be built once at init time and never be modified
at runtime.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>

Trivial cleanup and documentation changes on the hwmod code and data:

- add some hwmod documentation to indicate flags that should be moved
  outside the static hwmod data in a future patch

- remove some unused fields in the struct omap_hwmod_ocp_if and
  struct omap_hwmod structures
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Change the per-hwmod mutex to a spinlock.  (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.)  Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR.  The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.

This patch also effectively reverts commit
84824022 - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions.  Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.

Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block.  This
works for most IP blocks on the chip, but unfortunately not all.  For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block.  Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.

Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.

As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>

Allow board files and OMAP core code to control the state that some or
all of the hwmods end up in at the end of _setup() (called by
omap_hwmod_late_init() ).  Reimplement the old skip_setup_idle code in
terms of this new postsetup state code.

There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
in which all IP blocks should stay enabled after _setup() finishes;
and the MPU watchdog case, in which the watchdog IP block should enter
idle if watchdog coverage of kernel initialization is desired, and
should be disabled otherwise.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha Varadarajan <charu@ti.com>

Some OMAP IP blocks, such as the watchdog timers, cannot be completely
shut down via the standard hwmod shutdown mechanism.  This patch
enables the hwmod data files to supply a pointer to a custom
pre-shutdown function via the struct omap_hwmod_class.pre_shutdown
function pointer.  If the struct omap_hwmod_class.pre_shutdown
function pointer is non-null, the function will be executed before the
existing hwmod shutdown code runs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

"gadget", "through", "command", "maintain", "maintain", "controller", "address",
"between", "initiali[zs]e", "instead", "function", "select", "already",
"equal", "access", "management", "hierarchy", "registration", "interest",
"relative", "memory", "offset", "already",
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some modules which have 16bit registers can cause imprecise
aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such
hard requirement, and handle it in the hwmod framework.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The current version contains only the interconnects and the
mpu hwmods.
The remaining hwmods will be introduced by further patches on
top of this one.

- enable as well omap_hwmod.c build for OMAP4 Soc

Please not that this file uses the new naming convention for
naming HW IPs. This convention will be backported soon for previous
OMAP2 & 3 data files.

new name        trm name
-------------   -------------------
counter_32k     synctimer_32k
l3_main         l3
timerX          gptimerX / dmtimerX
mmcX            mmchsX / sdmmcX
dma_system      sdma
smartreflex_X   sr_X / sr?
usb_host_fs     usbfshost
usb_otg_hs      hsusbotg
usb_tll_hs      usbtllhs_config
wd_timerX       wdtimerX
ipu             cortexm3 / ducati
dsp             c6x / tesla
iva             ivahd / iva2.2
kbd             kbdocp / keyboard
mailbox         system_mailbox
mpu             cortexa9 / chiron
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch:

- adds more documentation to the hwmod code

- fixes some documentation typos elsewhere in the file

- changes the _sysc_*() function names to appear in (verb, noun) order,
  to match the rest of the function names.

This patch should not result in any functional change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.

TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.
Reported-by: NPartha Basak <p-basak2@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>

In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
use the SYSC softreset bit to provide the status.

Other cases might exist:
- Some IPs like McBSP does have a softreset control but no reset status.
- Some IPs that represent subsystem, like the DSS, can contains
a reset status without softreset control. The status is the aggregation
of all the sub modules reset status.

- Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
and replace the previous SYSS_MISSING, that was used to flag IP with
softreset control but without the SYSSTATUS register, with a specific
SYSS_HAS_RESET_STATUS flag.

- MCSPI and MMC contains both programming models, so the legacy one
will be prevented by removing the syss offset field that become useless.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>

Expose an hardreset API from hwmod in order to assert / deassert all the
individual reset lines that belong to an hwmod.  This API is needed by
some of the more complicated processor drivers, e.g., DSP/Bridge,
Syslink, etc.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Most processor IPs does have a hardreset signal controlled by the PRM.
This is different of the softreset used for local IP reset from the
SYSCONFIG register.
The granularity can be much finer than orginal HWMOD, for ex, the IVA
hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2...
Since this granularity is needed by the driver, we have to ensure
than one hwmod exist for each hardreset line.

- Store reset lines as hwmod resources that a driver can query by name like
  an irq or sdma line.

- Add two functions for asserting / deasserting reset lines in hwmods
  processor that require manual reset control.
- Add one functions to get the current reset state.
- If an hwmod contains only one line, an automatic assertion / de-assertion
  is done.
  -> de-assert the hardreset line only during enable from disable transition
  -> assert the hardreset line only during shutdown

Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be
kept in INITIALIZED state.
They can be properly enabled only if the hardreset line is de-asserted
before.

For information here is the list of IPs with HW reset control
on an OMAP4430 device:

RM_DSP_RSTCTRL
  1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control'
  0,0,'RST1','RW','1','DSP - DSP reset control'

RM_IVA_RSTCTRL
  2,2,'RST3','RW','1','IVA logic and SL2 reset control'
  1,1,'RST2','RW','1','IVA Sequencer2 reset control'
  0,0,'RST1','RW','1','IVA sequencer1 reset control'

RM_IPU_RSTCTRL
  2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.'
  1,1,'RST2','RW','1','IPU Cortex M3 CPU2  reset control.'
  0,0,'RST1','RW','1','IPU Cortex M3 CPU1  reset control.'

PRM_RSTCTRL
  1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.'
  0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.'

RM_CPU0_CPU0_RSTCTRL
RM_CPU1_CPU1_RSTCTRL
  0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control'
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: made the hardreset functions static; moved the register
 twiddling into prm*.c functions in previous patches; changed the
 function names to conform with hwmod practice]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>

Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions.  This
patch separates these two types of locking.

First, omap_hwmod_mutex is used only to protect access and
modification of omap_hwmod_list.  Also cleaned up some comments
referring to this mutex that are no longer needed.

Then, for protecting concurrent access to hwmod functions, use a
per-hwmod mutex.  This protects concurrent access to a single hwmod,
but would allow concurrent access to different hwmods.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: added structure documentation; changed mutex variable
 name]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The dma request line attribute was named dma channel, which leads
to confusion with the real dma channel definition.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>

Add omap_device_get_mpu_rt_va().  This is intended to be used by
device drivers (currently, via a struct platform_data function
pointer) to retrieve their corresponding device's virtual base address
that the MPU should use to access the device.  This is needed because
the omap_hwmod code does its own ioremap(), in order to gain access to
the module's OCP_SYSCONFIG register.

Add omap_hwmod_get_mpu_rt_va().  omap_device_get_mpu_rt_va() calls this
function to do the real work.

While here, rename struct omap_hwmod._rt_va to struct
omap_hwmod._mpu_rt_va, to reinforce that it refers to the MPU's
register target virtual address base (as opposed to, for example, the
L3's).

In the future, this belongs as a function in an omap_bus, so it is not
necessary to call this through a platform_data function pointer.

The use-case for this function was originally presented by Santosh
Shilimkar <santosh.shilimkar@ti.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

On kernels that don't use the omap_device_enable() calls to enable
devices, leave all on-chip devices enabled in hwmod _setup().
Otherwise, accesses to those devices are likely to fail, crashing the
system.  It's expected that kernels built without CONFIG_PM_RUNTIME
will be the primary use-case for this.  This functionality is
controlled by adding an extra parameter to omap_hwmod_late_init().

This patch is based on the patch "OMAP: hwmod: don't auto-disable
hwmod when !CONFIG_PM_RUNTIME" by Kevin Hilman
<khilman@deeprootsystems.com>.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>