All definitions in arch/arm/mach-omap2/dma.h are removed so it can be
removed now.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Last remaining DMA channel definitions in arch/arm/mach-omap2/dma.h
are used only by omap_hwmod_2xxx_3xxx_ipblock_data.c and
omap_hwmod_3xxx_data.c. Remove them by using directly DMA channel number in
hwmod data and drop definitions with a following script:

egrep '#define [OMAP|AM35XX].*DMA' arch/arm/mach-omap2/dma.h | cut -f 1,3 \
	| while read i; do \
		DEF=`echo $i |cut -d ' ' -f 2`; \
		CH=`echo $i |cut -d ' ' -f 3`; \
		echo "removing" $DEF; \
		sed -i "s/${DEF}/${CH}/" arch/arm/mach-omap2/omap_hwmod_*.c; \
		sed -i "/${DEF}/d" arch/arm/mach-omap2/dma.h; \
	done
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The different generations of OMAP2+ SoCs have almost the same
mailbox IP, but the IP has configurable parameters for number
of users (interrupts it can generate out towards processors)
and number of fifos (the base unidirectional h/w communication
channel). This data cannot be read from any registers, and so
has been added to the platform data.

This data together with the interrupt-type configuration can be
used in properly figuring out the number of registers to save
and restore in the OMAP mailbox driver code.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.

The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of mailbox devices and register with the
mailbox driver. This data is now represented in a concise format
and moved to the respective omap_hwmod data files and published
to the driver through the platform data.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in platform code.
This however breaks in case of device tree because of missing idle handling
APIs.

Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which
takes care of the mentioned requirement. Hence add the flag for all UART IPs
to take advantage of feature supported by framework.

Subsequent patches removes the slave idle handling from driver 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>

Convert the device data for the OMAP3 AES crypto IP
from explicit platform_data to hwmod.

CC: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: fixed lines causing sparse warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod.

CC: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: updated to use per-SoC registration lists for GP-only hwmods;
 fixed lines causing sparse warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than "force
standby" before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and "force standby" is restored before
suspend attempt. To recover from this, soft reset can be used, but
that's not suitable solution for suspend.

Keeping the register set at force standby (reset value) makes it work
and device still functions properly, as musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal.
Note that TI PSP kernels also have similar workarounds.

This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
actual flag name.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:

    http://www.spinics.net/lists/arm-kernel/msg174734.html

Further troubleshooting was unable to narrow the problem down.  So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.

Based on Mark's original patch.  We're removing the omap_device-based
pm_lats code, so a different approach was needed.

This third version contains some corrections thanks to Mark's review.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>

Based on earlier discussions[1] we attempted to find a suitable
location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
to dmaengine is complete.

Unfortunately that was before I was able to try to test compile
of the ARM multiplatform builds for omap2+, and the end result
was not very good.

So I'm creating yet another all over the place patch to cut the
last dependency for building omap2+ for ARM multiplatform. After
this, we have finally removed the driver dependencies to the
arch/arm code, except for few drivers that are being worked on.

The other option was to make the <plat-omap/dma-omap.h> path
to work, but we'd have to add some new header directory to for
multiplatform builds.

Or we would have to manually include arch/arm/plat-omap/include
again from arch/arm/Makefile for omap2+.

Neither of these alternatives sound appealing as they will
likely lead addition of various other headers exposed to the
drivers, which we want to avoid for the multiplatform kernels.

Since we already have a minimal include/linux/omap-dma.h,
let's just use that instead and add a note to it to not
use the custom omap DMA functions any longer where possible.

Note that converting omap DMA to dmaengine depends on
dmaengine supporting automatically incrementing the FIFO
address at the device end, and converting all the remaining
legacy drivers. So it's going to be few more merge windows.

[1] https://patchwork.kernel.org/patch/1519591/#

cc: Russell King <linux@arm.linux.org.uk>
cc: Kevin Hilman <khilman@ti.com>
cc: "Benoît Cousson" <b-cousson@ti.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Vinod Koul <vinod.koul@intel.com>
cc: Dan Williams <djbw@fb.com>
cc: Mauro Carvalho Chehab <mchehab@infradead.org>
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
cc: Hans Verkuil <hans.verkuil@cisco.com>
cc: Vaibhav Hiremath <hvaibhav@ti.com>
cc: Lokesh Vutla <lokeshvutla@ti.com>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
cc: Afzal Mohammed <afzal@ti.com>
cc: linux-crypto@vger.kernel.org
cc: linux-media@vger.kernel.org
cc: linux-mtd@lists.infradead.org
cc: linux-usb@vger.kernel.org
cc: linux-fbdev@vger.kernel.org
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.

Partially based on an earlier version by Ido Yariv <ido@wizery.com>.

Cc: Ido Yariv <ido@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NJoerg Roedel <joro@8bytes.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.

For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.

Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d0807 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.

For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.

Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.

For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

For omap1, we'll keep mach/serial.h around for 8250.c hardware
workarounds. For omap2+, we no longer need mach/serial.h and
can make it local to mach-omap2.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's make omap_hwmod local to mach-omap2 for
ARM common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to keep the device related things in the
common i2c.c as omap2+ is using hwmod. Split the code to
mach-omap1 and mach-omap2 parts and only leave common
code to plat-omap/i2c.c.

Note that as omap1 only has one i2c controller, we can
now remove the old device related macros.
Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Rename the smartreflex fck names for consistency and better readability;
rename the clock aliases so that they match the hwmod main_clk names.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Similar to omap1, some of the omap2+ dma channel definitions are
used by some drivers. For moving omap2+ dma channel definitions
to mach-omap2/, the used ones should be defined locally to driver.
Drivers can eliminate it using DT, platform data, or IORESOURCE_DMA
And moving omap2+ DMA channel definitions to mach-omap2
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We need to remove this from plat for ARM common zImage
support.

Also remove includes not needed by the omap_hsmmc.c driver.

Cc: linux-mmc@vger.kernel.org
Acked-by: NChris Ball <cjb@laptop.org>
Acked-by: NVenkatraman S <svenkatr@ti.com>
[tony@atomide.com: fold in removal of unused driver includes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Found by http://coccinelle.lip6.fr/Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds a missing hwmod entry for the HDQ/1-Wire module present
in the AM3505/17 CPUs.

This restores 1-Wire support to our AM3505 boards. We think it probably
stopped working with commit 96b1b29d
ARM: OMAP2+: HDQ1W: use omap_device
Signed-off-by: NRaphael Assenat <raph@8d.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) and commit ec2c0825
(ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ) updated the way
interrupts for OMAP2/3 devices are defined in the HWMOD data structures to
being an index plus a fixed offset (defined by OMAP_INTC_START). The definition
of the PMU interrupts on OMAP2/3 devices is missing the OMAP_INTC_START offset
and so this is causing the allocation of PMU interrupts to fail on OMAP2/3
devices. So add the offset to fix this.

This is patch is based upon Tony's master branch for OMAP.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
interrupts to the MPU HWMOD so we can use these for PMU events on these
devices. The PMU interrupts need to be the first interrupts in the array of
interrupts as the ARM PMU driver assumes this.

By using these dedicated interrupts we only need to enable the MPU and DEBUG
sub-systems for PMU to work. This is different to OMAP4430 that did not have
dedicated interrupts and required other power domains in addition to the DEBUG
sub-system to be enabled so we could route the PMU events to the CTI interrupts.
Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
the PMU device that is using by OMAP3.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU
on OMAP2 devices we only need to use MPU sub-system and so we can simply use
the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need
to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU
device for OMAP3.

The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so
add the PMU interrupt to the MPU HWMOD for these devices.

This change also moves the PMU code out of the mach-omap2/devices.c files into
its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed checkpatch messages; updated to apply; dropped old-style
 initial filename line in header comments]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
data for the debug sub-system for OMAP3, we can build the PMU device using the
debug sub-system HWMOD and control this power domain using runtime PM.
Reviewed-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply; added L4-EMU address space]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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

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

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

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

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

Add mmu hwmod data for iva and isp.

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

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

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

This can be local to mach-omap2.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This can be local to mach-omap2.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This can be local to mach-omap2.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Platform data for device drivers should be defined in
include/linux/platform_data/*.h, not in the architecture
and platform specific directories.

This moves such data out of the omap include directories
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Jean Pihet <j-pihet@ti.com>
Cc: J Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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