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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Add hwmod support to enable access to UART4 of the AM35xx series of
chips.  The UART4 device referenced from the TRM will show up as ttyO3.

This was tested on an AM3505.
Signed-off-by: NKyle Manna <kyle.manna@fuel7.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Booting the Linux kernel on Nokia RM-680 board has been broken since
2.6.39 due to the following:

[    0.217193] omap_hwmod: timer12: enabling
[    0.221435] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa304010
[    0.229431] Internal error: : 1028 [#1] SMP
[    0.233825] Modules linked in:
[    0.237060] CPU: 0    Not tainted  (3.2.0-rc4-dirty #46)
[    0.242645] PC is at _update_sysc_cache+0x2c/0x7c
[    0.247589] LR is at _enable+0x1b0/0x2d8
[    0.251708] pc : [<c0026108>]    lr : [<c0026df4>]    psr: 40000013
[    0.251708] sp : ef831f40  ip : ef82f380  fp : c06ac0c0
[    0.263702] r10: 00000000  r9 : c05dfb2c  r8 : ef830000
[    0.269165] r7 : c0027494  r6 : 00000000  r5 : 00000000  r4 : c06608b0
[    0.276000] r3 : fa304000  r2 : 00000010  r1 : c0661e28  r0 : c06608b0
[    0.282806] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    0.290405] Control: 10c5387d  Table: 80004019  DAC: 00000017
[    0.296417] Process swapper (pid: 1, stack limit = 0xef8302f8)
[    0.302520] Stack: (0xef831f40 to 0xef832000)
[    0.307098] 1f40: c06608b0 c0026df4 c06ad094 c0035120 00000001 c06608b0 00000000 c0027530
[    0.315612] 1f60: c0027604 ef830000 c05dfb2c c06608b0 c0642ac0 c0025bf0 c0621234 c062120c
[    0.324127] 1f80: c0621738 00000013 ef830000 c05dfb6c c0621234 c0008688 c062c880 c009eadc
[    0.332641] 1fa0: 0000005f 00000000 c0621738 35390013 00000000 00000000 00000000 0000019a
[    0.341156] 1fc0: c0681cf4 c0621234 c062120c c0621738 00000013 00000000 00000000 00000000
[    0.349670] 1fe0: 00000000 c05d5298 00000000 c05d5200 c0014fa8 c0014fa8 ffff0000 ffff0000
[    0.358184] [<c0026108>] (_update_sysc_cache+0x2c/0x7c) from [<c0026df4>] (_enable+0x1b0/0x2d8)
[    0.367248] [<c0026df4>] (_enable+0x1b0/0x2d8) from [<c0027530>] (_setup+0x9c/0x170)
[    0.375335] [<c0027530>] (_setup+0x9c/0x170) from [<c0025bf0>] (omap_hwmod_for_each+0x38/0x58)
[    0.384307] [<c0025bf0>] (omap_hwmod_for_each+0x38/0x58) from [<c05dfb6c>] (omap_hwmod_setup_all+0x40/0xa0)
[    0.394409] [<c05dfb6c>] (omap_hwmod_setup_all+0x40/0xa0) from [<c0008688>] (do_one_initcall+0x34/0x180)
[    0.404296] [<c0008688>] (do_one_initcall+0x34/0x180) from [<c05d5298>] (kernel_init+0x98/0x144)
[    0.413452] [<c05d5298>] (kernel_init+0x98/0x144) from [<c0014fa8>] (kernel_thread_exit+0x0/0x8)
[    0.422576] Code: e3130c01 1590304c 0590304c 119320b2 (07932002)
[    0.429046] ---[ end trace 1b75b31a2719ed1c ]---
[    0.433959] Kernel panic - not syncing: Attempted to kill init!

Timer 12 is not necessarily available on non-GP devices (see e.g.
http://marc.info/?l=linux-omap&m=129433066521102&w=2), so it should be
registered only on GP OMAPs. With this change it's again possible to
boot RM-680 into the shell. Tested with 3.2-rc4.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
[paul@pwsan.com: changed subject line]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Seems the commit 7e89098c was overly aggressive in adding iva and mailbox
hwmods so now they are registered twice.

------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c()
omap_hwmod: iva: _register returned -22
Modules linked in:
[<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64)
[<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c)
[<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c)
[<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28)
[<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4)
[<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264)
[<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040)
---[ end trace 1b75b31a2719ed1c ]---
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c()
omap_hwmod: mailbox: _register returned -22
Modules linked in:
[<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64)
[<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c)
[<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c)
[<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28)
[<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4)
[<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264)
[<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040)
---[ end trace 1b75b31a2719ed1d ]---
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.

Add function dispc_disable_outputs() which disables all active overlay manager
and ensure all frame transfers are completed.

Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
DSS2 driver starts.

This resolves the hang issue(caused by a L3 error during boot) seen on the
beagle board C3, which has a factory bootloader that enables display. The issue
is resolved with this patch.

Thanks to Tomi and Sricharan for some additional testing.
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NR, Sricharan <r.sricharan@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
[paul@pwsan.com: restructured code, removed omap_{read,write}l(), removed
 cpu_is_omap*() calls and converted to dev_attr]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP3 HWMOD data currently contains these errors with DSS clocks:

- dss_rfbi is missing ick opt-clock, which is needed for RFBI to
  calculate timings

- dss_dsi is missing ick and sys_clk

- dss_venc is missing dss_96m_fck opt-clock, which is required on
  OMAP3430

- dss_venc's interface and main clocks are wrong, causing VENC to fail
  to start

These problems were temporarily fixed with a DSS patch
9ede365a ("HACK: OMAP: DSS2: clk hack
for OMAP2/3"), which can be reverted after this patch (and the similar
patches for other OMAPs).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.

HWMOD framework does not currently enable all the DSS clocks when
resetting the DSS hardware. This hasn't caused any problems so far, but
we may just have been lucky.

dss_core's opt-clocks is also missing dss_96m_fck, which is a DSS clock
present only on OMAP3430, and thus required on OMAP3430 to finish the
reset.

This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET and adds the dss_96m_fck
opt-clock for dss_core in OMAP3 HWMOD data, fixing the issue.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
[paul@pwsan.com: merged duplicate .flags fields]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit d6504acd ("OMAP2+: hwmod:
remove OMAP_CHIP*") tests the inverse condition of what it should be
testing for the return value from omap_hwmod_register().  This causes
several IP blocks to not be registered on several OMAP3 family devices.

Fixing that bug also unmasked another bug, originally reported by
Chase Maupin <chase.maupin@ti.com> and then subsequently by Abhilash K
V <abhilash.kv@ti.com>, which caused SmartReflex IP blocks to be
registered on SoCs that don't support them.

Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for comments
on a previous version of the patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Chase Maupin <chase.maupin@ti.com>
Cc: Abhilash K V <abhilash.kv@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.  This removes quite a few warnings on boot for AM35x.
Signed-off-by: NAbhilash K V <abhilash.kv@ti.com>
[paul@pwsan.com: dropped 'mailbox class' comments; updated changelog]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver.
In addition, capability attribute of each of the timers is added in
hwmod database.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NThara Gopinath <thara@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NCousson, Benoit <b-cousson@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This voltage domain (a.k.a. VDD1) contains both the MPU and the IVA, so
rename appropriately.

Also fixup any users of the "mpu" name to use "mpu_iva"
Signed-off-by: NKevin Hilman <khilman@ti.com>

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: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>

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

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
[paul@pwsan.com: combined this patch with a patch to remove
 HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register
 offset conditional code to use the IP block revision; minor code
 cleanup]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This adds the new functionality flags for omap i2c unit to all OMAP2
hwmod definitions

Cc: patches@linaro.org
Cc: Ben Dooks <ben-linux@fluff.org>
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Since we cannot trust (or even reliably find) the OMAP I2C
peripheral unit's own revision register, we must inform the
OMAP i2c driver of which IP version it is running on.  We
do this by tagging the omap_hwmod_class for i2c on all the
OMAP2+ platform / cpu specific hwmod init and passing it up
to the driver (next patches).

Cc: patches@linaro.org
Cc: Ben Dooks <ben-linux@fluff.org>
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Peter Maydell noticed when running under QEMU he was getting
errors reporting 32-bit access to I2C peripheral unit registers
that are documented to be 8 or 16-bit only[1][2]

The I2C driver is blameless as it wraps its accesses in a
function using __raw_writew and __raw_readw, it turned out it
is the hwmod stuff.

However the hwmod code already has a flag to force a
perhipheral unit to only be accessed using 16-bit operations.

This patch applies the 16-bit only flag to the 2430,
OMAP3xxx and OMAP44xx hwmod structs.  2420 was already
correctly marked up as 16-bit.

The 2430 change will need testing by TI as arranged
in the comments to the previous patch version.

When the 16-bit flag is or-ed with other flags, it is placed
first as requested in comments.

[1] OMAP4430 Technical reference manual section 23.1.6.2
[2] OMAP3530 Techincal reference manual section 18.6

Cc: patches@linaro.org
Cc: Ben Dooks <ben-linux@fluff.org>
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To reduce kernel source file data duplication, share struct
omap_hwmod_class and omap_hwmod_class_sysconfig arrays across OMAP2xxx
and 3xxx hwmod data files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To reduce kernel source file data duplication, share struct
omap_hwmod_dma_info arrays across OMAP2xxx and 3xxx hwmod data files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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

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

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

To reduce kernel source file data duplication, share struct
omap_hwmod_mpu_irqs arrays across OMAP2xxx and 3xxx hwmod data files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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

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

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

To reduce kernel source file data duplication, share struct
omap_hwmod_addr_space arrays across OMAP2xxx and 3xxx hwmod data
files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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

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

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

GPIO module expects the debounce clocks to be enabled during reset. It doesn't
reset properly and timeouts are seen, if this clock isn't enabled during
reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
which the debounce clocks are enabled during reset.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP2420, 2430 and 3xxx were using the OMAP4 end address
that unfortunately is not located at the same base address.
Moreover the OMAP4 size was set to 256 instead of 4096.

Change all .pa_end to set them to .pa_start + 0xfff

Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Reported-by: NMichael Fillinger <m-fillinger@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently, the core DSS platform device requests for an irq line for OMAP2 and
OMAP3. Make DISPC and DSI platform devices request for a shared IRQ line.

On OMAP3, the logical OR of DSI and DISPC interrupt lines goes to the MPU. There
is a register DSS_IRQSTATUS which tells if the interrupt came from DISPC or DSI.

On OMAP2, there is no DSI, only DISPC interrupts goto the MPU. There is no
DSS_IRQSTATUS register.

Hence, it makes more sense to have separate irq handlers corresponding to the
DSS sub modules instead of having a common handler.

Since on OMAP3 the logical OR of the lines goes to MPU, the irq line is shared
among the IRQ handlers.

The hwmod irq info has been removed for DSS to DISPC and DSI for OMAP2 and OMAP3
hwmod databases. The Probes of DISPC and DSI now request for irq handlers.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>