History log of /arch/arm/mach-omap2/omap_hwmod.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
3c55c1baffa5f719eb2ae9729088bc867f972f53 13-Apr-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status"

This reverts commit f9a2f9c3fa76eec55928e8e06f3094c8f01df7cb. 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 2800852a079504f35f88e44faf5c9c96318c0cca ("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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
d99de7f552fac43e24fd4fb8048d8f21abaea691 13-Apr-2012 Fernando Guzman Lugo <fernando.lugo@ti.com> ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data

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: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Fernando 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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
a8f5b6e5ef0faf64997bfa87698aaabc989e64c4 06-Apr-2012 Olof Johansson <olof@lixom.net> Merge tag 'omap-fixes-a2-for-3.4rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes

From Paul Walmsley:

OMAP clock, powerdomain, clockdomain, and hwmod fixes intended for the
early v3.4-rc series. Also contains an HSMMC integration refinement
of an earlier hardware bug workaround.

* tag 'omap-fixes-a2-for-3.4rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending:
ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
ARM: OMAP2+: hwmod: Restore sysc after a reset
ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
ARM: OMAP3: clock data: fill in some missing clockdomains
ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases
ARM: OMAP: clock: fix race in disable all clocks
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks
ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached
ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data
f9a2f9c3fa76eec55928e8e06f3094c8f01df7cb 13-Mar-2012 Rajendra Nayak <rnayak@ti.com> ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status

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: Rajendra 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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
2800852a079504f35f88e44faf5c9c96318c0cca 13-Mar-2012 Rajendra Nayak <rnayak@ti.com> ARM: OMAP2+: hwmod: Restore sysc after a reset

After a softreset, make sure the sysc settings are correctly
restored.

Reported-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Rajendra 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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
2a1cc1445a51e3a81c10d294586756cdb9174469 05-Apr-2012 Govindraj.R <govindraj.raja@ti.com> ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules

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: Govindraj.R <govindraj.raja@ti.com>
[paul@pwsan.com: updated function kerneldoc documentation]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
387ca5bf4fe2297c93869b6f639afa8d849fb877 12-Mar-2012 Rajendra Nayak <rnayak@ti.com> ARM: OMAP: hwmod: Use sysc_fields->srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK

This is useful when we have broken type2 compliant IPs' where
the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT
and hence is overridden using sysc_fields->srst_shift.

We have at least one such instance now with onchip keypad on OMAP5
which has a different softreset shift as compared to other type2
IPs'.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Balaji TK <balajitk@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Acked-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
4f8a428dac431e7bd09673b404769d87df948eef 07-Feb-2012 Russell King <rmk+kernel@arm.linux.org.uk> ARM: omap: fix wrapped error messages in omap_hwmod.c

While trying to debug my OMAP platforms, they emitted this message:

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

The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.

The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.

Acked-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/arm/mach-omap2/omap_hwmod.c
b3c37522928b5452588fc202eaa0f11f6e339256 09-Jan-2012 Linus Torvalds <torvalds@linux-foundation.org> Merge tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

power management changes for omap and imx

A significant part of the changes for these two platforms went into
power management, so they are split out into a separate branch.

* tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (65 commits)
ARM: imx6: remove __CPUINIT annotation from v7_invalidate_l1
ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
ARM: imx6q: resume PL310 only when CACHE_L2X0 defined
ARM: imx6q: build pm code only when CONFIG_PM selected
ARM: mx5: use generic irq chip pm interface for pm functions on
ARM: omap: pass minimal SoC/board data for UART from dt
arm/dts: Add minimal device tree support for omap2420 and omap2430
omap-serial: Add minimal device tree support
omap-serial: Use default clock speed (48Mhz) if not specified
omap-serial: Get rid of all pdev->id usage
ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at init
ARM: OMAP4: PRM: use PRCM interrupt handler
ARM: OMAP3: pm: use prcm chain handler
ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup pad
ARM: OMAP2+: mux: add support for PAD wakeup interrupts
ARM: OMAP: PRCM: add suspend prepare / finish support
ARM: OMAP: PRCM: add support for chain interrupt handler
ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrier
ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup
ARM: OMAP2+: mux: add wakeup-capable hwmod mux entries to dynamic list
...
57e964e1ae9bd4f699ae1074430bcf81a9a11377 09-Jan-2012 Linus Torvalds <torvalds@linux-foundation.org> Merge tag 'fixes-non-critical' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Non-critical bug fixes

Simple bug fixes that were not considered important enough for inclusion
into 3.2.

* tag 'fixes-non-critical' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
MAINTAINERS: update pxa and mmp
ARM: pxa: Include linux/export.h in balloon3.c
ARM: OMAP4: clock: Add CPU local timer clock node
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported
ARM: OMAP: AM3517/3505: fix crash on boot due to incorrect voltagedomain data
ARM: OMAP: hwmod data: fix the panic on Nokia RM-680 during boot
ARM: OMAP2+: DMA: Workaround for invalid destination position
ARM: OMAP2+: DMA: Workaround for invalid source position
bfc141e3a515008d85e57af39c9faa4d2bbc65e0 17-Dec-2011 Benoit Cousson <b-cousson@ti.com> ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported

If the module does not have any modulemode, the _disable_module function
will do nothing. There is then no point waiting for a idle status change.

It will remove the following warnings.

[ 0.331848] omap_hwmod: dmm: _wait_target_disable failed
[ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed
[ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed
[ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed
[ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed
[ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed
[ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed
[ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed
[ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed
[ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed
[ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed
[ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed
[ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed
[ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed
[ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed
[ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed
[ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed
[ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed

Note: For such module, the state is managed automatically by HW according
to clock domain transition. It is then not possible to wait for idle even
later in the _idle function since the status will change at clock domain
boundary.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved
_wait_target_disable() into _disable_module(), removing duplicate code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
9d297f5ee1b92a84e2cd6c547c3ac1f893128359 16-Dec-2011 Tony Lindgren <tony@atomide.com> Merge branch 'tk_prm_chain_handler_devel_3.3' of git://git.pwsan.com/linux-2.6 into prcm

Conflicts:
arch/arm/mach-omap2/Makefile
aacf094128759cfb29a3ce88f92d08b79b74a4e8 16-Dec-2011 Rajendra Nayak <rnayak@ti.com> ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at init

An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hwmod framework throws a WARN() about
the device being already in enabled state.

Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to
identify such devices/hwmods. When the device/hwmod is requested to be
enabled (the first time) by its driver/user, nothing except the
mux-enable is needed. The mux data is board specific and is
unavailable during initial enable() of the device, done by the
framework as part of setup().

A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.

Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: use a flag rather than a state; updated commit message;
edited some documentation]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
abc2d5456334d548328978d0b0d22c0e5d44cdcd 16-Dec-2011 Tero Kristo <t-kristo@ti.com> ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup pad

By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to be re-routed this way must
have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq).

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved fn to omap_hwmod.c; separated fn from mux scan_wakeups
changes; added kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
eceec00914e3a74b94eea832f9e829c3efcea9bc 16-Dec-2011 Govindraj R <govindraj.raja@ti.com> ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup

Add API to enable IO pad wakeup capability based on mux pad and
wake_up enable flag available from hwmod_mux initialization.

Use the wakeup_enable flag and enable wakeup capability for the given
pads. Wakeup capability will be enabled/disabled during hwmod idle
transition based on whether wakeup_flag is set or cleared. If the
hwmod is currently idled, and any mux values were changed by
_set_idle_ioring_wakeup(), the SCM PADCTRL registers will be updated.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: rearranged code to limit indentation; cleaned up
function documentation; removed unused non-static functions; modified
to search all hwmod pads, not just dynamic remuxing ones; modified to
update SCM regs if hwmod is currently idle and any pads have changed]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
742eaa6a6e356a16788ce6530271de89bc4f8fb5 06-Dec-2011 Russell King <rmk+kernel@arm.linux.org.uk> Merge branch 'for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into devel-stable

Conflicts:
arch/arm/common/gic.c
arch/arm/plat-omap/include/plat/common.h
cc1b0765da6078b906772b79ff211b88cc0ae958 23-Nov-2011 sricharan <r.sricharan@ti.com> ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs

The address spaces, irqs and dma reqs count APIs return the
number of corresponding entries in a hwmod including a additional
null value or a -1 terminator in the structure introduced recently.
More information here:

- 212738a4: omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs
arrays

- 78183f3f: omap_hwmod: use a null structure record to terminate
omap_hwmod_addr_space arrays

- bc614958: omap_hwmod: use a terminator record with omap_hwmod_dma_info
arrays

The issue with irqs and dma info was originally reported by Benoit Cousson.

The devices which have multiple hwmods and use device_build_ss are
broken with this, as their resources are populated with a extra null
value, subsequently the probe fails. So fix the API not to include
the array terminator in the count.

Reported-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimar@ti.com>
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
4e65331c6bb4a777bd61a4dac0daa9fc47777b63 10-Nov-2011 Tony Lindgren <tony@atomide.com> ARM: 7159/1: OMAP: Introduce local common.h files

As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>,
there's no need to keep local prototypes in non-local headers.

Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/arm/mach-omap2/omap_hwmod.c
fc01387302c01899e3cc67d3c81fd4287db9bab9 09-Jun-2011 Tomi Valkeinen <tomi.valkeinen@ti.com> ARM: OMAP: change get_context_loss_count ret value to int

get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.

Change the functions to return an int, with negative value meaning an
error.

OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated to fix a warning with recent dmtimer changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
d6504acd2125984c61dce24727dd3842d0144015 15-Sep-2011 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: remove OMAP_CHIP*

At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.

Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
AM3517/3505 support, and for other review comments.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>
/arch/arm/mach-omap2/omap_hwmod.c
665d001338b494d6d62810aa99b4c0fa1a0884b9 10-Jul-2011 Rajendra Nayak <rnayak@ti.com> OMAP2+: hwmod: Follow the recommended PRCM module enable sequence

On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Configure desired module mode to "enable" or "auto"
-4- Wait for the desired module idle status to be FUNC
-5- Program clkdm in HW_AUTO(if supported)

This sequence applies to all older OMAPs' as well,
however since they use autodeps, it makes sure that
no clkdm is in IDLE, and hence not requiring a force
SW_WKUP when a module is being enabled.

OMAP4 does not need to support autodeps, because
of the dyanamic dependency feature, wherein
the HW takes care of waking up a clockdomain from
idle and hence the module, whenever an interconnect
access happens to the given module.

Implementing the sequence for OMAP4 requires
the clockdomain handling that is currently done in
clock framework to be done as part of hwmod framework
since the step -4- above to "Wait for the desired
module idle status to be FUNC" is done as part of
hwmod framework.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[b-cousson@ti.com: Adapt it to the new clkdm hwmod attribute and API]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[paul@pwsan.com: dropped mach-omap2/clock.c changes; modified to only
call the clockdomain code if oh->clkdm is set; disable clock->clockdomain
interaction on OMAP4]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
45c38252d76a96e6e0e05f982ca44096191a8eea 10-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP4: hwmod: Introduce the module control in hwmod control

Take advantage of the explicit modulemode control to fix
the way parents clocks are managed.
A module must be disabled before any parents are disabled.
That programming model was not possible with the previous
implementation that was considering a modulemode as a leaf
clock node managed by the clock fmwk.
This was leading to bad crash upon disable when the parent
clock was gated before the module completed its transition
to idle.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
eaac329dfa6d3a4025242bf34d33aa3cb9df9f9f 10-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros

The RSTCTRL 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 an offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update prm_xxx accessors, move definition to the proper header file and
update copyrights.
Change the s16 register offset parameter to u16.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: use '_prminst_' in function names that are part of the
prminst44xx.c file]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
11b10341bd12c87a8409c69cdcd7ee898400842f 10-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Wait the idle status to be disabled

It is mandatory to wait for a module to be in disabled state before
potentially disabling source clock or re-asserting a reset.

omap_hwmod_idle and omap_hwmod_shutdown does not wait for
the module to be fully idle.

Add a cm_xxx accessor to wait the clkctrl idle status to be disabled.
Fix hwmod_[idle|shutdown] to use this API.

Based on Rajendra's initial patch.

Please note that most interconnects hwmod will return one timeout because
it is impossible for them to be in idle since the processor is accessing
the registers though the interconnect.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Todd Poynor <toddpoynor@google.com>
[paul@pwsan.com: move cpu_is_*() tests to the top of _wait_target_disable();
incorporate some feedback from Todd]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
d0f0631ddc61026dca71b5b679803000d70fde50 10-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros

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: Benoit 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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
6ae769973adf1325115d0dfe3fec17e26cbacd81 10-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Init clkdm field at boot time

At boot time, lookup the clkdm_name to get the clkdm
structure pointer for further usage.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
6d3c55fd4f0f94a9455d30df9414ddb0f755f402 10-Jul-2011 Avinash.H.M <avinashhm@ti.com> OMAP: hwmod: fix the i2c-reset timeout during bootup

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: Avinash.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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
c402c0d9dfa8d4fb54dd98fc12525f39d0f29bfe 10-Jul-2011 Paul Walmsley <paul@pwsan.com> Merge branches 'dmtimer_precleanup_3.1', 'hwmod_core_cleanup_a_3.1', 'combine_common_hwmod_3.1', 'omap4_hwmod_data_cleanup_a_3.1', 'clock_cleanup_a_3.1', 'prcm_cleanup_a_3.1', 'omap_pm_cleanup_3.1' and 'omap_device_cleanup_3.1' into prcm-cleanup-3.1
bc6149587b309e3231e5ac7138b84197813e17ec 10-Jul-2011 Paul Walmsley <paul@pwsan.com> omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays

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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
212738a4499d278254ed6fdb400e3b4be4cb1de2 10-Jul-2011 Paul Walmsley <paul@pwsan.com> omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays

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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
78183f3fdf76f422431a81852468be01b36db325 10-Jul-2011 Paul Walmsley <paul@pwsan.com> omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays

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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
34617e2a4d331fdd8172077d8c70a0421fc136e6 01-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Move pr_debug to improve the readability

Move the pr_debug at the top of the function
to trace the entry even if the first test is failing.
That help understanding that we entered the function
but failed in it.

Move the _enable last part out of the test to reduce
indentation and improve readability.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
6652271a2556c086c04658dce16de2947e849ffd 01-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Add warnings if enable failed

Change the debug into warning to check what IPs are failing.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
31f62866c578b3d47ef7810b336e9e193b90167f 01-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Fix the HW reset management

The HW reset must be de-assert after the clocks are enabled
but before waiting for the target to be ready. Otherwise the
reset might not work properly since the clock is not running
to proceed the reset.

De-assert the reset after _enable_clocks and before
_wait_target_ready.
Re-assert it only when the clocks are disabled.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
d24bcaa3fa711f7dd9c4aacf3c58083cf666418f 01-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Remove _populate_mpu_rt_base warning

It is perfectly valid for some hwmod to not have any
register target address for sysconfig. This is especially
true for interconnect hwmods.
Remove the warning.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
1fe741139be5acfe3758b53cdbf0b5e3d26db3fe 01-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Do not write the enawakeup bit if SYSC_HAS_ENAWAKEUP is not set

The Type 2 type of IPs will not have any enawakeup bit in their sysconfig.
Writing to that bit will instead trigger a softreset.
Check the flag to write this bit only if the module supports it.

Reported-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
6481c73c22613660a5b791d2b4d0faf60508d731 01-Jul-2011 Miguel Vadillo <vadillo@ti.com> OMAP2+: hwmod: Enable module in shutdown to access sysconfig

When calling the shutdown, the module may be already in idle.
Accessing the sysconfig register will then lead to a crash.
In that case, re-enable the module in order to allow the access
to the sysconfig register.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
724019b0137acf2ea43e5ca854798851f5ebf51f 01-Jul-2011 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Fix smart-standby + wakeup support

The commit 86009eb326afde34ffdc5648cd344aa86b8d58d4 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: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
30ebad9d756a0b2c97c6c4ca6c5e6b799e3b64da 01-Jun-2011 Govindraj.R <govindraj.raja@ti.com> OMAP2+: mux: fix compilation warnings

Fix below compilation warnings.

arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each':
arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used uninitialized in this function

arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_gpio':
arch/arm/mach-omap2/mux.c:917: warning: 'm' may be used uninitialized in this function

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
029268e4c124a38b11ae965849ea2dfef724a568 11-Mar-2011 Tony Lindgren <tony@atomide.com> omap2+: Add separate list for dynamic pads to mux

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: sricharan <r.sricharan@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
2d403fe03070b541cc93cfa915f6e6c592cf231c 11-Mar-2011 Paul Walmsley <paul@pwsan.com> 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
21ace5452ce3327f0d11f85b0c33dfcd0d20fdb2 11-Mar-2011 Paul Walmsley <paul@pwsan.com> 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
570b54c7fae65b65320d5a7d4b2249c86eeaa497 10-Mar-2011 Paul Walmsley <paul@pwsan.com> 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>
/arch/arm/mach-omap2/omap_hwmod.c
9599217a06da5f5a95794ca9192c14317d441187 10-Mar-2011 Kishon Vijay Abraham I <kishon@ti.com> 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>
/arch/arm/mach-omap2/omap_hwmod.c
43b01643355672a266b95c4719f47cd1abac4680 10-Mar-2011 Paul Walmsley <paul@pwsan.com> 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>
/arch/arm/mach-omap2/omap_hwmod.c
cc1226e7635011c7dd1e786770ed51ee751800f2 04-Mar-2011 omar ramirez <omar.ramirez@ti.com> 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>
/arch/arm/mach-omap2/omap_hwmod.c
09c35f2fee8a8633dde7b8b588b1cb496eb220a1 16-Feb-2011 Rajendra Nayak <rnayak@ti.com> 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>
/arch/arm/mach-omap2/omap_hwmod.c
8985b63d072413f0446fd2d0d654795f2d683323 03-Mar-2011 Tarun Kanti DebBarma <tarun.kanti@ti.com> 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>
/arch/arm/mach-omap2/omap_hwmod.c
b2833a0578453449dce1b8b8e54f67a544c5e37f 03-Mar-2011 Tony Lindgren <tony@atomide.com> Merge branches 'devel-iommu-mailbox', 'devel-mcbsp', 'devel-board' and 'devel-hsmmc' into omap-for-linus

Conflicts:
arch/arm/mach-omap2/omap_hwmod_44xx_data.c
a2debdbd1ad896a410019c9cf30785cad15930fc 23-Feb-2011 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: add ability to setup individual hwmods

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: Paul 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>
/arch/arm/mach-omap2/omap_hwmod.c
48d54f3fd20b435311f295b3bca3570096a2ac83 23-Feb-2011 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: ignore attempts to re-setup a hwmod

Previously, if a hwmod had already been set up, and the code attempted
to set up the hwmod again, an error would be returned. This is not
really useful behavior if we wish to allow the OMAP core code to setup
the hwmods needed for the Linux clocksources and clockevents before
the rest of the hwmods are setup. So, instead of generating errors,
just ignore the attempt to re-setup the hwmod.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
569edd705cc4e81a9129b5557f1fb259e21418a9 23-Feb-2011 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: find MPU initiator hwmod during in _register()

Move the code that looks for the MPU initiator hwmod to run during
the individual hwmod _register() function. (Previously, it ran after
all hwmods were registered in the omap_hwmod_late_init() function.)

This is done so code can late-initialize a few individual hwmods --
for example, for the system timer -- before the entire set of hwmods is
initialized later in boot via omap_hwmod_late_init().

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
550c8092c55c22db8f843bad070fd1731292a75e 28-Feb-2011 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: rename some init functions

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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
bac1a0f0bbf0b11b23fe714826f29fc9aeb35855 23-Feb-2011 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: allow multiple calls to omap_hwmod_init()

There's no longer any reason why we should prevent multiple
calls to omap_hwmod_init(). It is now simply used to register an
array of hwmods.

This should allow a subset of hwmods (e.g., hwmods
handling the system clocksource and clockevents) to be registered
earlier than the remaining mass of hwmods.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
cd5038024d6c92fbe4bf67af91eea5c6fb24a192 24-Feb-2011 Kishon Vijay Abraham I <kishon@ti.com> OMAP: hwmod: allow hwmod to provide address space accessible from SDMA

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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
e7c7d760859e78a4f47e7be647df683491e420fb 15-Feb-2011 Tony Lindgren <tony@atomide.com> omap: hwmod: Populate _mpu_rt_va later on in omap_hwmod_late_init

Otherwise ioremap can fail with early_init patch unless we have
a static mapping for everything.

Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
44dc046e93eb98d41048954f700b1927f7e288ed 15-Feb-2011 Tony Lindgren <tony@atomide.com> omap2+: Make omap_hwmod_late_init into core_initcall

Otherwise things will fail with early_init changes.

Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
8d9af88f55be89fa4c897ded3204ef12c947731e 23-Dec-2010 Tony Lindgren <tony@atomide.com> omap2+: Allow hwmod state changes to mux pads based on the state changes

Allow hwmod state changes to mux pads based on the state changes.

By default, only enable and disable the pads. In some rare cases
dynamic remuxing for the idles states is needed, this can be done
by passing the enable, idle, and off pads from board-*.c file along
with OMAP_DEVICE_PAD_REMUX flag.

Thanks to Paul Walmsley <paul@booyaka.com> for the comments on the
hwmod related changes.

Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
c80705aa7074045e7431ed2ebeb0f7d5773615ab 22-Dec-2010 Kevin Hilman <khilman@deeprootsystems.com> OMAP: PM: implement context loss count APIs

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: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
86009eb326afde34ffdc5648cd344aa86b8d58d4 22-Dec-2010 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs

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: Benoit Cousson <b-cousson@ti.com>
Tested-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
f2dd7e09db3e18e4c053810b72fe026685d9bf0c 22-Dec-2010 Rajendra Nayak <rnayak@ti.com> OMAP2+: hwmod: Disable clocks when hwmod enable fails

In cases where a module (hwmod) does not become accesible on enabling
the main clocks (can happen if there are external clocks needed
for the module to become accesible), make sure the clocks are not
left enabled.
This ensures that when the requisite external dependencies are met
a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable
and disable clocks using clk framework. Leaving the clocks enabled in
the error case causes additional usecounting at the clock framework
level leaving the clock enabled forever.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
ce35b2446945c506cb02960eab2072f56efdf1c0 22-Dec-2010 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Remove omap_hwmod_mutex

The hwmod list will be built are init time and never
be modified at runtime. There is no need anymore to protect
the list from concurrent accesses using a mutex.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
01592df95049a6f3d4abb0571ae1c7cb6e9d1cd7 22-Dec-2010 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Mark functions used only during initialization with __init

_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs
that will be used only during the omap_hwmod initialization phase.
There is no need to keep them for runtime.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
0102b62789af5aed92cea4cf7f36afaa1ab12c72 22-Dec-2010 Benoit Cousson <b-cousson@ti.com> OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister

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: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
5a7ddcbdaf1bb7603422fb6188156ccc39711b0f 22-Dec-2010 Kevin Hilman <khilman@deeprootsystems.com> OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency

In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.

This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.

This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:

commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle

commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable

There resulting in code in _enable_sysc() was this:

/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);

_write_sysconfig(v, oh);

so here, 'v' has wakeups disabled.

/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);

Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)

/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}

And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.

Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
72e06d087204f3bc9acf281717b90ebf0b9731f7 22-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: powerdomain: move header file from plat-omap to mach-omap2

The OMAP powerdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h
to mach-omap2/powerdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access powerdomain code
and data directly.

As part of this process, remove the references to powerdomain data
from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap.
Change the DSPBridge code to point to the new location for the
powerdomain headers. The DSPBridge code should not be including the
powerdomain headers; these should be removed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
/arch/arm/mach-omap2/omap_hwmod.c
1540f214065982e6cbc6b8da1fe65a15e358f7c5 22-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: clockdomain: move header file from plat-omap to mach-omap2

The OMAP clockdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h
to mach-omap2/clockdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access clockdomain code
and data directly.

DSPBridge also uses the clockdomain headers for some reason, so,
modify it also. The DSPBridge code should not be including the
clockdomain headers; these should be removed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
59fb659b065f52fcc2deed293cfbfc58f890376c 21-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files

In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.

This process also requires the #includes in each of these files to be
changed to reference the new file name. As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.

Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
d198b514bd9e94930ee0b9ca1cad0a51f5e29608 21-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP4: PRCM: reorganize existing OMAP4 PRCM header files

Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
so they match their underlying OMAP hardware modules. Add clockdomain
offset information.

Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the
SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI
should do this.

Move the "_MOD" macros out of the prcm-common.h header file, into the
header file of the hardware module that they belong to. For example,
OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header.

Adjust #includes of all files that used the old PRCM header file names
to point to the new filenames.

The autogeneration scripts have been updated accordingly.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
233cbe5b94096f95ba7bca2162d63275b0b90b5b 14-Dec-2010 Rajendra Nayak <rnayak@ti.com> OMAP2+: hwmod: Update the sysc_cache in case module context is lost

Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).

Identifying if a module has lost context requires atleast one
register read, and since a register read has more latency than
a write, it makes sense to do a blind write always.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
dc6d1cda044b24c3d9f8e4af0431887ebe3488ef 14-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock

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
848240223c35fcc71c424ad51a8e8aef42d3879c - 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
bd36179eec2827cd60b4a8c6e180cc030c74a4ec 14-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: add support for per-class custom device reset functions

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: Paul 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>
/arch/arm/mach-omap2/omap_hwmod.c
2092e5ccf89db09ebde94e9aabd3c86d5fa05c6c 14-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: add postsetup state

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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha Varadarajan <charu@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
e4dc8f507c3066d6fcece988d99b6d766c46af85 14-Dec-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod: allow custom pre-shutdown functions

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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
cc7a1d2a540a780066aa562c651a88dd28b6fc8a 08-Oct-2010 Rajendra Nayak <rnayak@ti.com> omap: hwmod: Handle modules with 16bit registers

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: Rajendra Nayak <rnayak@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
78f26e872f77b6312273216de1a8f836c6f2e143 24-Sep-2010 Hema HK <hemahk@ti.com> OMAP: hwmod: Set autoidle after smartidle during _sysc_enable

OMAP USBOTG module has a requirement to set the autoidle bit only after
setting smartidle bit. Modified the _sys_enable api to set the smartidle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.

Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
74ff3a68ed11f1e9eede4fe301f42cc3cdf7396a 21-Sep-2010 Paul Walmsley <paul@pwsan.com> OMAP: hwmod: improve documentation, clean up function names

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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
9980ce53c97392a3dbdc9d1ac3e455d79b4167ed 21-Sep-2010 Rajendra Nayak <rnayak@ti.com> OMAP: hwmod: Enable module wakeup if in smartidle

If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.

The thread "[PATCH 7/8] : Hwmod api changes" archived here:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34212.html

has additional technical information on the rationale of this patch.

Sergei Shtylyov <sshtylyov@mvista.com> identified an indentation
problem with this patch - thanks, Sergei.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
[paul@pwsan.com: revised patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
/arch/arm/mach-omap2/omap_hwmod.c
96835af970e5d6aeedf868e53590a947be5e4a7a 21-Sep-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Fix softreset for modules with optional clocks

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: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
2cb068149c365f1c2b10f2ece6786139527dcc16 21-Sep-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

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: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
aee48e3c9cee3698d17b4cf4203551de0a804760 21-Sep-2010 Paul Walmsley <paul@pwsan.com> OMAP: hwmod: add an hardreset API for use by other core code

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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
76e5589e5b7cd0fd589264ab193f10550e1d8ab6 21-Sep-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Force a softreset during _setup

Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
5365efbe29250a227502256cc912351fe2157b42 21-Sep-2010 Benoît Cousson <b-cousson@ti.com> OMAP: hwmod: Add hardreset management support

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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
12b1fdb45c2594070bb36e39cd89a33547aad8fb 21-Sep-2010 Kevin Hilman <khilman@ti.com> OMAP: hwmod: separate list locking and hwmod hardware locking

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: Kevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: added structure documentation; changed mutex variable
name]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
9b579114efc4bd00532de33c783b4cb4638910ff 21-Sep-2010 Liam Girdwood <lrg@slimlogic.co.uk> OMAP: hwmod: Fix omap_hwmod_reset wrong state test

The reset function wrongly used the state flag as a bit mask and was trying
to re-enable after a reset.

hwmod is still enabled for the PRCM point of view after a softreset
so there is no need to re-enable.

Remove the state check from omap_hwmod_reset since the _reset
function is checking that as well and in addition can generate
a warning

Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
[b-cousson@ti.com: remove the wrong test, remove the re-enable]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
3827f9492bdff045ae57fe67e65ce7e259ed4219 21-Sep-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Do not disable clocks if hwmod already in idle

The disable function was disabling clocks and dependencies
from both enable and idle state. Since idle function is already
disabling both, an enable -> idle -> disable sequence will
try to disable twice the clocks and thus generate a
"Trying disable clock XXX with 0 usecount" warning.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
9ee9fff92e02e8c5f84794b3a5ce47646c2dfc39 21-Sep-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Rename dma_ch to dma_req

The dma request line attribute was named dma channel, which leads
to confusion with the real dma channel definition.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
887adeac28a3e354ebb3f9aeca6fc2296c105267 27-Jul-2010 Paul Walmsley <paul@pwsan.com> OMAP2+: hwmod/device: update documentation and copyright

Update some minor documentation issues and update copyright for
omap_device/omap_hwmod code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
db2a60bf2527209b42e6f512d5892089a835ceaa 27-Jul-2010 Paul Walmsley <paul@pwsan.com> OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_va

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: Paul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
97d60162f64ef068b639d8a77ef3bc148baa53ad 27-Jul-2010 Paul Walmsley <paul@pwsan.com> OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in _setup()

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: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
848240223c35fcc71c424ad51a8e8aef42d3879c 27-Jul-2010 Kevin Hilman <khilman@deeprootsystems.com> OMAP: hwmod: add non-locking versions of enable and idle functions

Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.

Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are only exposed at the
hwmod level and not at the omap-device level.

The use-case that led to the need for the non-locking versions is
hwmods that are enabled/idled from within the core idle/suspend path.
Since interrupts are already disabled here, the mutex-based locking in
hwmod can sleep and will cause potential deadlocks.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
dc75925d67950889b79df1cc1518c21ec678df6c 24-Jun-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Fix the missing braces

As reported by Sergei, a couple of braces were missing after
the WARN removal patch.

[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed

https://patchwork.kernel.org/patch/100756/

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: fixed patch description per Anand's E-mail]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
f6304f5804f228b6c2fea9e3dfac25c5b2db9b38 20-May-2010 Tony Lindgren <tony@atomide.com> Merge branch 'omap4-i2c-init' into omap-for-linus
4788da268f83dedc58b79dc7b2f6072687f63a19 19-May-2010 Paul Walmsley <paul@pwsan.com> OMAP powerdomain, hwmod, omap_device: add some credits

Add some missing credits for people who have contributed significant features
or fixes.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Thara Gopinath <thara@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
63403384233e3f58514eea891003458dedd43c12 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Replace WARN by pr_warning for clockdomain check

Most of the clock nodes belong to a clock domain, but it is perfectly valid
to have clock without clock domain.
Root clocks for example does not belong to any clock domain.
Keep the warning but reduce the verbosity.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
5c2c02961ea39d7bbe4d87f362ab3173a424794b 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Rename hwmod name for the MPU

In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.

The same cleanup will be have to done for other hwmods in
OMAP2 & 3 data files.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
f5c1f84bcc9c5b7a664886d0a5e7143d0bc3251f 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Do not exit the iteration if one clock init failed

During the _init_clocks phase, the iteration is stopped but the
status is still change from _HWMOD_STATE_REGISTERED to
_HWMOD_STATE_CLKS_INITED.
Since the _setup phase will be done nevertheless, it might be
better to keep initializing the others clocks nodes and just
keep the warning.
It is much easier to debug when a important number of clocks
name are wrong during the early debug phase of a new platform.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
20383d82160d918047bb10a4f6e170f4bac195a7 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed

The WARN is a little bit too verbose and is not providing
usefull information in that case.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
4d3ae5a9a7b3685c6d260a82f4098145862b2cd3 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Remove IS_ERR check with omap_clk_get_by_name return value

The previous clock API was returning a standard linux error code in
case of failure. This is not the case anymore with the new
omap_clk_get_by_name API. A NULL value means that the clock node
does not exist.
Replace all the IS_ERR check by a !clk check.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
682fdc96f3afb5ec34e4893fae41d09346d656ed 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP: hwmod: Fix wrong pointer iteration in oh->slaves

The iteration is currently done on the omap_hwmod_ocp_if pointer
and not on the table pointer that reference them.
It worked most of the time because the structure are contiguous in
memory.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
33f7ec81fb3e525eec0575f33dbab02240eda6d4 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP4: hwmod: Replace OCPIF_HAS_IDLEST by HWMOD_NO_IDLEST

Some initiator modules in OMAP2 & 3 does not have IDLEST bit,
in that case we cannot detect the module readiness by
polling that bit and must exist the function immediately
assuming that the module is ready.

The previous flag was affected to the OCP interface. While it is
technically true that the idlest is related to the L4 slave
interface of the module, the PRCM status belong to the module.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
9a23dfe12806920a8dfadec5ea5b83e5ca5378c9 20-May-2010 Benoit Cousson <b-cousson@ti.com> OMAP4: hwmod & CM: Implement the omap4_cm_wait_module_ready function

The return of the omap4_cm_wait_module_ready function is checked
in order to avoid accessing the sysconfig register if the module is
not in the correct state.
In that case the _setup will exit without trying to reset
using sysconfig.
For the moment a warning is printed. A proper management of fclk
and module reset will have to be done in order to init correctly
the problematic IPs listed below.

<4>omap_hwmod: ivahd: cannot be enabled (3)
<4>omap_hwmod: iss: cannot be enabled (3)
<4>omap_hwmod: tesla: cannot be enabled (3)
<4>omap_hwmod: sdma: cannot be enabled (3)
<4>omap_hwmod: sl2: cannot be enabled (3)
<4>omap_hwmod: sad2d: cannot be enabled (3)
<4>omap_hwmod: ducati: cannot be enabled (3)

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
ac1d426e825ab5778995f2f6f053ca2e6b45c622 17-May-2010 Russell King <rmk+kernel@arm.linux.org.uk> Merge branch 'devel-stable' into devel

Conflicts:
arch/arm/Kconfig
arch/arm/include/asm/system.h
arch/arm/mm/Kconfig
6262c92f51ffb074800d5a340ee16bc06758e037 25-Mar-2010 Russell King <rmk+kernel@arm.linux.org.uk> ARM: Remove useless linux/bootmem.h includes

These files include linux/bootmem.h without using anything from this
file; remove the unnecessary include.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/arm/mach-omap2/omap_hwmod.c
d5647c18eac9a313a89a3049a9fff51b20021a44 31-Mar-2010 Thara Gopinath <thara@ti.com> OMAP: HWMOD: Adding clockdomain check

This patch adds check for presence of clockdomain structure in the API
omap_hwmod_get_pwrdm before trying to access the powerdomain structure.
This will prevent unnecessary crashing of the system in case of a
clock node with out an associated clockdomain.

Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
43b40992ce21def8d5957f32d7ddb728af89bfce 23-Feb-2010 Paul Walmsley <paul@pwsan.com> OMAP hwmod: add hwmod class support

Add support for categorizing and iterating over hardware IP blocks by
the "class" of the IP block. The class is the type of the IP block:
e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data
from the struct omap_hwmod into the struct omap_hwmod_class, since
it's expected to stay consistent for each class. While here, fix some
comments.

The hwmod_class structures in this patch were designed and proposed by
Benoît Cousson <b-cousson@ti.com> and were refined in a discussion
between Thara Gopinath <thara@ti.com>, Kevin Hilman
<khilman@deeprootsystems.com>, and myself.

This patch uses WARN() lines that are longer than 80 characters, as
Kevin noted a broader lkml consensus to increase greppability by
keeping the messages all on one line.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
50ebdac2ec9fb2de9c271cb2e0e13aae3b454166 23-Feb-2010 Paul Walmsley <paul@pwsan.com> OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev dev+con

The OMAP hwmod core code is intended to use SoC IP block description
structures that are autogenerated from TI's OMAP hardware database.
Currently the hwmod code uses clkdev device + connection addressing to
identify clocks. This causes problems in the hwmod autogeneration
process, since the TI hardware database doesn't use platform_device or
clkdev addressing; it uses a single clock signal name string, which
tends to bear some resemblance to what is used in the OMAP TRMs. This
patch converts the hwmod code and existing data to use omap_clk_get_by_name(),
introduced in the previous patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
358f0e630d5409ab3837b86db3595560eae773b6 24-Feb-2010 Thara Gopinath <thara@ti.com> OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits.

In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
register.Instead clockactivity bits are part of another register at a
different bit position than the usual bit positions 8 and 9.

In OMAP4, a new scheme is available due to the new protocol
between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG
bitfields position will be different.
The IP_REVISION register should be at offset 0x00.
It should contain a SCHEME field. From this we can determine whether
the IP follows legacy scheme or the new scheme.

31:30 SCHEME Used to distinguish between old scheme and current.
Read 0x0: Legacy protocol.
Read 0x1: New PRCM protocol defined for new OMAP4 IPs

For legacy IP
13:12 MIDLEMODE
11:8 CLOCKACTIVITY
6 EMUSOFT
5 EMUFREE
4:3 SIDLEMODE
2 ENAWAKEUP
1 SOFTRESET
0 AUTOIDLE

For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target):
5:4 STANDBYMODE (Ex MIDLEMODE)
3:2 IDLEMODE (Ex SIDLEMODE)
1 FREEEMU (Ex EMUFREE)
0 SOFTRESET

Unfortunately In OMAP4 also some IPs will not follow any of these
two schemes. This is the case at least for McASP, SmartReflex
and some security IPs.

This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which
can be used by the hwmod structures to specify the offsets for the
sysconfig register of the IP.Also two static structures
omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined
which can be used directly to populate the sysc_fields if the IP follows
legacy or new OMAP4 scheme. If the IP follows none of these two schemes
a new omap_hwmod_sysc_fields structure has to be defined and
passed as part of omap_hwmod_sysconfig.

Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
46273e6f37bdf3801363986e2228350ecad19059 27-Jan-2010 Kevin Hilman <khilman@deeprootsystems.com> OMAP: hwmod: add API for slave idlemode setting

Some HW blocks have errata which requires specific slave idle mode
under certain conditions.

This patch adds an hwmod API to allow setting slave idlemode
ensuring that any SYSCONFIG register updates go through hwmod.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
55ed96945b1f3d0f4ad21a27b32ce4bd99d8c268 27-Jan-2010 Paul Walmsley <paul@pwsan.com> OMAP2/3 clkdm/pwrdm: move wkdep/sleepdep handling from pwrdm to clkdm

Move clockdomain wakeup dependency and sleep dependency data
structures from the powerdomain layer to the clockdomain layer, where
they belong. These dependencies were originally placed in the
powerdomain layer due to unclear documentation; however, it is clear
now that these dependencies are between clockdomains. For OMAP2/3,
this is not such a big problem, but for OMAP4 this needs to be fixed.

Thanks to Benoît Cousson <b-cousson@ti.com> for his advice on this
patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
883edfdd58419b0cc298db14ba25c26d55c6d1af 20-Jan-2010 Thara Gopinath <thara@ti.com> OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.

In the current implementation the sysconfig value is read into
_sysc_cache once and an actual update to the sysconfig register
happens only if the new value paased is differnt from the one in _sysc_cache.
_sysc_cache is updated only if _HWMOD_SYSCONFIG_LOADED is not set.
This can lead to the follwing issue if off mode is enabled in modules
which employs "always-retore" mechanism of context save and restore.

a. The module sets the sysconfig register through omap_device_enable.
Here _sysc_cache is updated with the value written to the sysconfig
register and left.
b. The power domain containig the module enters off mode and the
module context is lost.
c. The module in use becomes active and calls omap_device_enable to
enable itself. Here a read of sysconfig register does not happen
as _HWMOD_SYSCONFIG_LOADED flag is set. The value to be written
to the sysconfig register will be same as the one written in step a.
Since _sysc_cache reflects the previous written value an update
of the sysconfig register does not happen.
This means in modules which employs "always-restore" mechanism
after off , the sysconfig regsiters will never get updated.

This patch introduces a flag SYSC_NO_CACHE which if set ensures that the
sysconfig register is always read into _sysc_cache before an update is
attempted.

This flags need to be set only by modules which does not do a context save
but re-initializes the registers every time the module is accessed. This
includes modules like i2c, smartreflex etc.

Signed-off-by: Thara Gopinath <thara@ti.com>
[paul@pwsan.com: tweaked to apply on a different head, added flag comment]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
81d7c6ffccd1d5369942c428faa9ee25a3d59db8 09-Dec-2009 Kevin Hilman <khilman@deeprootsystems.com> OMAP: hwmod: warn on missing clockdomain

WARN if a clock/hwmod is missing a clockdomain association since
resulting hwmod will not be able to correctly enable/disable clocks.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
a16b1f7f8692163e0c6b4741d8980837dfca75f1 09-Dec-2009 Paul Walmsley <paul@pwsan.com> OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code

Earlier, the hwmod code had considered the OCP_SYSCONFIG.CLOCKACTIVITY
bits to be incremental power saving bits, controlling internal IP
block clock gates. This was a misapprehension. The CLOCKACTIVITY
bits are used to indicate, in advance, which clocks will be cut when
the module acknowledges an idle request. This enables the IP block to
take whatever action is necessary to complete any in-progress work
before asserting its IdleAck.

In the current Linux-OMAP code, this implies that the clock framework
should be changing module CLOCKACTIVITY bits as module clocks are enabled
and disabled. We don't do that yet, but in the future, we should.
This must wait until the clock tree is annotated with omap_hwmod pointers
(or vice-versa). In the meantime, drop most of the hwmod code that
controls CLOCKACTIVITY bits to avoid confusion.

This patch has benefited from many illuminating discussions with (in
alphabetical order) Benoît Cousson <b-cousson@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Sebastien Sabatier <s-sabatier1@ti.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Sebastien Sabatier <s-sabatier1@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c
718bfd76932c566f79eb55083693ef0b68071bf8 09-Dec-2009 Paul Walmsley <paul@pwsan.com> OMAP hwmod: add names to module MPU IRQ lines

Replace the existing u8 array of module MPU IRQ lines with a struct
that includes a name - similar to the existing struct
omap_hwmod_dma_info. Device drivers can then use
platform_get_resource_byname() to retrieve specific IRQs without nasty
dependencies on array ordering.

Thanks to Benoît Cousson <b-cousson@ti.com> and Kevin Hilman
<khilman@deeprootsystems.com> for feedback on this approach.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
726072e5dd459e3831d1dd4308ba469ff3ded419 09-Dec-2009 Paul Walmsley <paul@pwsan.com> OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling

This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP
hwmod code.

After this patch, the hwmod code will set the module AUTOIDLE bit
(generally <module>.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon
enable. If the hwmod flag HWMOD_NO_OCP_AUTOIDLE is set, AUTOIDLE will
be set to 0 upon enable. Upon module disable, AUTOIDLE will be set to
1.

Enabling module autoidle should save some power. The only reason to
not set the OCP_SYSCONFIG.AUTOIDLE bit is if there is a bug in the
module RTL, e.g., the MPUINTC block on OMAP3.

Comments from Kevin Hilman <khilman@deeprootsystems.com> inspired this patch,
and Kevin tested an earlier version of this patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
b835d0142196466c5ff3695b90cff1e3ea635c8e 09-Dec-2009 Paul Walmsley <paul@pwsan.com> OMAP3 hwmod: reprogram OCP_SYSCONFIG register after setting SOFTRESET

Reprogram the module's OCP_SYSCONFIG register after module reset (SOFTRESET
= 1). This may not be needed, but the definition of the reset performed by
the SOFTRESET bit is unclear.

Kevin Hilman <khilman@deeprootsystems.com> tested an earlier version of
this patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-omap2/omap_hwmod.c
6f8b7ff5b01e16a65c3b17865ce047faeca40907 09-Dec-2009 Paul Walmsley <paul@pwsan.com> OMAP clock/hwmod: fix off-by-one errors

Fix loop bailout off-by-one bugs reported by Juha Leppänen
<juha_motorsportcom@luukku.com>.

This second version incorporates comments from Russell King
<linux@arm.linux.org.uk>. A new macro, 'omap_test_timeout', has
been created, with cleaner code, and existing code has been converted
to use it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Juha Leppänen <juha_motorsportcom@luukku.com>
Cc: Russell King <linux@arm.linux.org.uk>
/arch/arm/mach-omap2/omap_hwmod.c
ce491cf85466c3377228c5a852ea627ec5136956 20-Oct-2009 Tony Lindgren <tony@atomide.com> omap: headers: Move remaining headers from include/mach to include/plat

Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.

This was done with:

#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"

for header in $headers; do
old="#include <mach\/$header"
new="#include <plat\/$header"
for dir in $omap_dirs; do
find $dir -type f -name \*.[chS] | \
xargs sed -i "s/$old/$new/"
done
find drivers/ -type f -name \*omap*.[chS] | \
xargs sed -i "s/$old/$new/"
for file in $other_files; do
sed -i "s/$old/$new/" $file
done
done

for header in $(ls $mach_dir_old/*.h); do
git mv $header $plat_dir_new/
done

Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
986a13f508156e1d041d59166beb2a3dec2ddfad 20-Oct-2009 Tony Lindgren <tony@atomide.com> omap: Use ioremap in omap_hwmod.c

Use ioremap in omap_hwmod.c

Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
/arch/arm/mach-omap2/omap_hwmod.c
02bfc030e4417003b7a94393102c92e39b2dfa65 03-Sep-2009 Paul Walmsley <paul@pwsan.com> OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects

Connect the omap_hwmod code to the kernel boot. Create some basic
interconnect and device structures for OMAP2/3 chips.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/omap_hwmod.c
63c852384125ca0eff0e695f92cbbd439bed4aa3 03-Sep-2009 Paul Walmsley <paul@pwsan.com> OMAP2/3/4: create omap_hwmod layer

OMAP SoCs can be considered a collection of hardware IP blocks
connected by various interconnects. The bus topology and device
integration data is somewhat more complex than platform_device can
encode. This patch creates code and structures to manage information
about OMAP on-chip devices ("hardware modules") and their integration
to the rest of the chip. Hardware module data is intended to be
generated dynamically from the TI hardware database for the OMAP4
chips and beyond, easing Linux support for new chip variants.

This code currently:

- resets and configures all hardware modules upon startup, reducing bootloader
dependencies;

- provides hooks for Linux driver model code to enable, idle, and shutdown
hardware modules (forthcoming patch);

- waits for hardware modules to leave idle once their clocks
are enabled and OCP_SYSCONFIG bits are set appropriately.

- provides a means to pass arbitrary IP block configuration data (e.g.,
FIFO size) to the device driver (via the dev_attr void pointer)

In the future this code is intended to:

- estimate interconnect bandwidth and latency characteristics to
ensure constraints are satisfied during DVFS

- provide *GRPSEL bit data to the powerdomain code

- handle pin/ball muxing for devices

- generate IO mapping information dynamically

- supply device firewall configuration data

- provide hardware module data to other on-chip coprocessor software

- allow the removal of the "disable unused clocks" code in the OMAP2/3
clock code

This patch represents a collaborative effort involving many people from TI,
Nokia, and the Linux-OMAP community.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Vikram Pandita <vikram.pandita@ti.com>
Cc: Sakari Poussa <sakari.poussa@nokia.com>
Cc: Anand Sawant <sawant@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Eric Thomas <ethomas@ti.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
/arch/arm/mach-omap2/omap_hwmod.c