Fixed pr_debug to pr_err when hwmod returns an error when enabling
a module.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain")
changed the GIC driver to use a non-legacy IRQ domain on DT
platforms. This patch assumes that DT-driven systems are getting
all of their interrupts from device tree.

Turns out that OMAP has quite a few hidden gems, and still uses
hardcoded interrupts despite having fairly complete DTs.

This patch attempts to work around these by offering a translation
method that can be called directly from the hwmod code, if present.
The same hack is sprinkled over PRCM and TWL.

It isn't pretty, but it seems to do the job without having to add
more hacks to the interrupt controller code.

Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: updated to fix make randconfig issue]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
"parent" hwmod that needs to be enabled for the "child" hwmod to work.

This is used at hwmod setup time: when doing the initial setup and
reset, first enable the parent hwmod, and after setup and reset is done,
restore the parent hwmod to postsetup_state.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit.taneja@gmail.com>
[paul@pwsan.com: add kerneldoc documentation for parent_hwmod; note that it
 is a temporary workaround]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

ml->node and sl->node are currently initialized
by means of INIT_LIST_HEAD(). That initialiation
is followed by a list_add() call.

Looking at what both these functions do we will have:

	ml->node.next = &ml->node;
	ml->node.prev = &ml->node;
	oi->master->master_ports.next.prev = &ml->node;
	ml->node.next = &oi->master->master_ports.next;
	ml->node.prev = &oi->master->master_ports;
	oi->master->master_ports.next = &ml->node;

from this, it's clear that both INIT_LIST_HEAD() calls
are unnecessary and can be safely removed.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This adds a generic API for reconfiguring the I/O chain. The implementation
will call the SoC specific function registered during init time. The SoC
specific reconfigure functions are also made static, as they don't need
to be accessed outside the PRM driver itself.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: updated for recent omap3 prcm fixes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

cminst44xx.h will be removed, thus move the public APIs to cm44xx.h header.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

PRM driver now has a generic API for checking hardreset status. SoC
specific support functions are registered through the prm_ll_data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

PRM driver now has a generic API for deasserting hardware resets. SoC
specific support functions are registered through the prm_ll_data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

PRM driver now has a generic API for asserting hardware resets. SoC
specific support functions are registered through the prm_ll_data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM43xx is using OMAP4+ PRM driver, so it should be using the corresponding
hardreset ops from the hwmod also.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These are now identical with the OMAP4 implementations, so use the OMAP4
versions and remove the AM33xx ones.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Adds a generic CM driver API for enabling/disabling modules.
The SoC specific implementations are registered through cm_ll_data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Adds a generic CM driver API for waiting module to enter idle / standby.
The SoC specific implementations are registered through cm_ll_data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch consolidates the parameters provided for the SoC specific
cm_*_wait_module_ready calls, adds the missing cm_ll_data function
pointers and uses the now generic call from the mach-omap2 board code.
SoC specific *_wait_module_ready calls are also made static so they
can only be accessed through the generic CM driver API only.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is not needed for anything. This also eases the consolidation of
the wait_module_ready / wait_module_idle calls behind a generic CM
driver API by reducing the number of needed parameters.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The implementation on these is identical, so no need to have them separate.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use the more common pr_warn.

Other miscellanea:

o Realign arguments
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit cc824534 ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts
for DT when MUSB is idled") fixed issues with hung UART wake-up
events by calling _reconfigure_io_chain() when MUSB is connected
or disconnected.

As pointed out by Paul Walmsley, we may need to also call
_reconfigure_io_chain() in other cases, so it should be a separate
flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul.
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We are getting "PRM: I/O chain clock line assertion timed out" errors
on early omaps for device tree based booting. This is because we are
unconditionally calling reconfigure_io_chain while legacy booting
has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.

For device tree based booting, we are calling reconfigure_io_chain
unconditionally from pinctrl framework. So we need to add a check for
omap3_has_io_chain_ctrl() to avoid the errors for trying to access
a register that does not exist.

For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration"
just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the
PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
added until in es3.1 probaly to fix issues with flakey wake-up events.

We are doing proper checks for ST_IO_CHAIN already in id.c and with
omap3_has_io_chain_ctrl(). For more information, see also commit
b02b9172 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
control detection").

Let's fix the issue by selecting the right function during init for
reconfigure_io_chain depending on the omap revision. For es3.0 and
earlier we need to just toggle EN_IO. By doing this, we can move the
check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.

Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
issue.

Fixes: 30a69ef7 ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap")
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Reviewed-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

To deal with IPs which are specific to dra74x and dra72x, maintain seperate
ocp interface lists, while keeping the common list for all common IPs.

Move USB OTG SS4 to dra74x only list since its unavailable in
dra72x and is giving an abort during boot. The dra72x only list
is empty for now and a placeholder for future hwmod additions which
are specific to dra72x.

Fixes: d904b38d ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
Reported-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
[paul@pwsan.com: fixed comment style to conform with CodingStyle]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Looks like MUSB cable removal can cause wake-up interrupts to
stop working for device tree based booting at least for UART3
even as nothing is dynamically remuxed. This can be fixed by
calling reconfigure_io_chain() for device tree based booting
in hwmod code. Note that we already do that for legacy booting
if the legacy mux is configured.

My guess is that this is related to UART3 and MUSB ULPI
hsusb0_data0 and hsusb0_data1 support for Carkit mode that
somehow affect the configured IO chain for UART3 and require
rearming the wake-up interrupts.

In general, for device tree based booting, pinctrl-single
calls the rearm hook that in turn calls reconfigure_io_chain
so calling reconfigure_io_chain should not be needed from the
hwmod code for other events.

So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
of it. If we see other devices needing similar changes we can
add more checks for it.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org # v3.16
Signed-off-by: NTony Lindgren <tony@atomide.com>

am43xx reset register layout is more similar to am33xx than omap4 so
use the am33xx functions for hwmod hardreset soc_ops rather than the
currently used omap4 functions. Without this, assert_hardreset and
deassert_hardreset will not work on am43xx.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
[paul@pwsan.com: fixed build errors for an AM43xx-only Kconfig]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.

Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Bug was introduced by commit 'f92d9597: ARM: OMAP2+: hwmod:
Extract no-idle and no-reset info from DT'

There were 2 versions of the patch posted which resulted in the above
commit. While v1 [1] had the bug, v2 [2] had it fixed.
However v1 apparently seemed to have been pulled in by mistake
introducing the bug.

Given of_find_property() does return NULL when the node passed is
NULL, it did not introduce any functional issues as such, just the
fact that the second if check was executed unnecessarily.

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg94220.html
[2] http://www.spinics.net/lists/linux-omap/msg98490.html

Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Fixes: f92d9597 ("ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT")
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit 313a76ee (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced
softreset bit cleaning right after set one. It is caused L3 error for
OMAP4 ISS because ISS register write occurs when ISS reset process is in
progress. Avoid this situation by cleaning softreset bit later, when reset
process is successfully finished.
Signed-off-by: NIllia Smyrnov <illia.smyrnov@globallogic.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Switch to memblock interfaces for early memory allocator instead of
bootmem allocator.  No functional change in beahvior than what it is in
current code from bootmem users points of view.

Archs already converted to NO_BOOTMEM now directly use memblock
interfaces instead of bootmem wrappers build on top of memblock.  And
the archs which still uses bootmem, these new apis just fallback to
exiting bootmem APIs.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

DT clocks are mostly missing clkdm info now, and this causes an issue with
counter32k which makes its slave idlemode wrong and prevents core idle.

Fixed by initializing the hwmod clkdm pointers for omap3 also which makes
sure the clkdm flag matching logic works properly.

This patch also changes the return value for _init_clkdm to 0 for
incorrect clkdm_name, as this a warning, not a fatal error.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

If the main clock for a hwmod is of basic clock type, it is illegal to type
cast this to clk_hw_omap and will result in bogus data. Fixed by checking
the clock flags before attempting the type cast.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced
missing braces, however, we just set return result if clk_get fail
and we populate the error pointer in clk pointer and pass it along to
clk_prepare. This is wrong. The intent seems to be retry remaining
clocks if they are available and warn the ones we cant find clks for.

With the current logic, we see the following crash:
omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick
Unable to handle kernel NULL pointer dereference at virtual address 00000032
pgd = c0004000
[00000032] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19
task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000
PC is at __clk_prepare+0x10/0x74
LR is at clk_prepare+0x14/0x24
  <snip>
[<c044d59c>] (__clk_prepare+0x10/0x74) from [<c044d9b0>] (clk_prepare+0x14/0x24)
[<c044d9b0>] (clk_prepare+0x14/0x24) from [<c077d8c4>] (_init+0x24c/0x3bc)
[<c077d8c4>] (_init+0x24c/0x3bc) from [<c0027328>] (omap_hwmod_for_each+0x34/0x5c)
[<c0027328>] (omap_hwmod_for_each+0x34/0x5c) from [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40)
[<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) from [<c0008928>] (do_one_initcall+0x38/0x168)
[<c0008928>] (do_one_initcall+0x38/0x168) from [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc)
[<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) from [<c0521064>] (kernel_init+0x8/0x110)
[<c0521064>] (kernel_init+0x8/0x110) from [<c000e568>] (ret_from_fork+0x14/0x2c)
Code: e92d4038 e2504000 01a05004 0a000005 (e5943034)

So, just warn and continue instead of proceeding and crashing, with
missing clock nodes/bad data, we will eventually fail, however we
should now have enough information to identify the culprit.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.

This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.

To fix this we clear the SOFTRESET bit and update the sysconfig
register + sysc_cache using write_sysconfig().
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
[paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We have some device tree properties where the ti,hwmod have multiple
values:

am33xx.dtsi:	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi:	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi:	ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi:	ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";

That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.

So they should all be fixed up to be separate devices in the .dts files.

We also have the related data removed for at least omap4 in commit
3b9b1015 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.

So we need to fix two bugs:

1. We are only checking the first entry of the ti,hwmods property

   This means that we're only initializing the first hwmods entry
   instead of the ones listed in the ti,hwmods property.

2. We are only checking the child nodes, not the nodes themselves

   This means that anything listed at OCP level is currently just
   ignored and unitialized and at least the omap4 case, with the
   legacy data missing from the hwmod.

Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.

While at it, let's also add some warnings for the bad data so it's
easier to fix.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Reuse OMAP4 operations on AM43x.

Context related ops are not used on AM43x, as this would not add value
when using DT and AM43x is DT only boot. This additionally helps not to
add context register offset for each hwmod.
Signed-off-by: NAmbresh K <ambresh@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Acked-by: NRajendra Nayak <rnayak@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Now that we have DT bindings to specify which devices should not
be reset and idled during init, make hwmod extract the information
(and store them in internal flags) from Device tree.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The hwmod init sequence involves initializing and idling all the
hwmods during bootup. If a module class has sysconfig, the init
sequence utilizes the module register base for performing any
sysc configuration.

The module address space is being removed from hwmod database and
retrieved from the <reg> property of the corresponding DT node.
If a hwmod does not have its corresponding DT node defined and the
memory address space is not defined in the corresponding
omap_hwmod_ocp_if, then the module register target address space
would be NULL and any sysc programming would result in a NULL
pointer dereference and a kernel boot hang.

Handle this scenario by checking for a valid module address space
during the _init of each hwmod, and leaving it in the registered
state if no module register address base is defined in either of
the hwmod data or the DT data.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
[paul@pwsan.com: use -ENXIO rather than -ENOMEM to indicate a missing address
 space error; fixed checkpatch.pl problem]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the write to the SYSCONFIG register is programming the
same value that is already stored in the register.

Writes to the devices SYSCONFIG register can be slow, for example, writing to
the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional
clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can
take ~100us.

Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
the SYSCONFIG register with a new value.

Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
idling the device, only write the value if the value has changed. It should be
safe to do this on idle as the context of the register will never be lost while
the device is active.

Verified that suspend, CORE off and retention states are working with this
change on OMAP3430 Beagle board.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The soc_ops for dra7xx devices can be completed reused
from the ones used for omap4 and omap5 devices.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>

Address space is being removed from hwmod database and DT information
in <reg> property is being used. Currently the 0th index of device
address space is used to map for register target address. This is not
always true, eg. cpgmac has it's sysconfig in second address space.

Handle it by specifying index of device address space to be used for
register target. As default value of this field would be zero with
static initialization, existing behaviour of using first address space
for register target while using DT would be kept as such.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Tested-by: NMugunthan V N <mugunthanvnm@ti.com>
[paul@pwsan.com: use u8 rather than int to save memory]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.

While at this, also remove unused sysc auto idle api from hwmod code.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.

The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in SWSUP. We now have a need to control
IPs sidle mode in SWSUP only while its active.

So define a new flag 'HWMOD_SWSUP_SIDLE_ACT' to help the framework
know about these new IP requirements.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)

However the same programming logic is missing when it comes to sidle mode
programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the
ones which support hardware controlled sidle modes)

This problem was hidden due to the fact that a call to _enable_wakeup()
in those same functions would overwrite the idlemodes and program them
correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases)

So fix the sidlemode handling correctly in these functions and handle the
_enable_wakeup() for SIDLEMODE supported IPs same as the way its handled
for MIDLEMODE supported ones.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>