As the FS USB code is not being actively used for omap2+
there's no point keeping it around for omap2+.

Let's make the FS USB platform init code omap1 only so
we can remove the last user of omap_read/write for omap2+,
and simplify things for further USB, DMA, and device tree
related work.

While at it, also group the mach includes for the related
drivers.

Cc: linux-usb@vger.kernel.org
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds a simple BCH ecc computation api, similar to the
existing Hamming ecc api. It is intended to be used by the MTD layer.
It implements the following features:

- support 4-bit and 8-bit ecc computation
- do not protect user bytes in spare area, only data area is protected
- ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs

This last feature is obtained by adding a constant polynomial to
the hardware computed ecc. It allows to correct bitflips in blank pages
and is extremely useful to support filesystems such as UBIFS, which expect
erased pages to contain only 0xFFs.

This api has been tested on an OMAP3630 board.

Artem: The OMAP maintainer Tony Lindgren gave us his blessing for merging
this patch via the MTD tree.
Signed-off-by: NIvan Djelic <ivan.djelic@parrot.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0
which are present on OMAP4+ processors. Now we can distinguish
conditions applicable to OMAP4,5 and those specific to OMAP24xx
and OMAP3xxx.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This cleanup got missed while implementing following:
25db711d gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1c gpio/omap: Add DT support to GPIO driver

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Tony reported the following compile warning after commit
eeb3711b ("ARM: OMAP2+: clean up some
cppcheck warnings"):

arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
arch/arm/plat-omap/usb.c:40: warning: unused variable 'status'

This happens if CONFIG_ARCH_OMAP_OTG is set but
CONFIG_USB_GADGET_OMAP, CONFIG_USB_OHCI_HCD,
CONFIG_USB_OHCI_HCD_MODULE, and CONFIG_USB_OTG are all unset.

Fix by localizing the status variable to the blocks that use it.

Compile-tested only, with omap2plus_defconfig and omap2plus_defconfig
with CONFIG_USB_OHCI_HCD and CONFIG_USB_OTG enabled.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently cpu_is_omap3517() actually detects any device in the AM35x
family (3517 and no-SGX version 3505.)  To make it more clear what is
being detected, convert the names from 3517 to AM35xx.

This adds a new soc_is_am35xx() which duplicates the cpu_is_omap3517().
In order to avoid cross-tree dependencies with clock-tree changes,
cpu_is_omap3517() is left until the clock changes are merged,
at which point cpu_is_omap3517() will be completely removed.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
[tony@atomide.com: change to use soc_is_omap instead]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that omap2420 is using hwmod for MMC, this code is omap1
only used on omap1.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This hardware exists only on 2430 and later omaps, so there's no
need to have it in plat-omap/devices.c.

Note that we don't have any users for exported omap_dsp_get_mempool_base(),
so we can make it static.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This hardware exists on omap1 only and there's no need to keep it
in plat-omap/devices.c. No functional changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NChris Lalancette <clalancette@gmail.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

arch/arm/plat-omap/devices.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/plat-omap/devices.c:170: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t'
arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_init':
arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t'
arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'phys_addr_t'
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -

1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.

The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
So, in order to use option 2, deeper idle state MUST be disabled.

Option 3 will still work but it is no better than 32K sync-timer
based clocksource.

We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.

Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.

And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.

So, the solution is,

Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also use hwmod database
lookup mechanism, through which at run-time we can identify availability
of 32k-sync timer on the device, else fall back to gptimer.

Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Implement a custom reset function for the HDQ1W IP block.  This is
because the HDQ1W IP block, like I2C, has an internal clock gating bit
that needs to be toggled after setting the SOFTRESET bit to allow the
reset to propagate.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Avinash.H.M <avinashhm@ti.com>
Tested-by: NNeilBrown <neilb@suse.de>

Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
[paul@pwsan.com: updated to apply on top of the 3.5 hwmod cleanup;
 changed mmc hwmod name/class to "msdi" as documented in the 2420 TRM Rev X;
 added sysconfig register information; added 16 bit register width flag;
 added MSDI custom reset code]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The system dma module has capabiities register indicating
the support for descriptor loading, constant fill, etc.
Use this instead of OMAP revision check to identify the features
supported runtime.

This avoids patching the code for feature SOCs which has
those capabilities.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code
cpu checks accordingly so that there is no need to patch
the file for any future OMAP2+ devices.

In long run, all these attributes should come from hwmod dev_attr based
on DMA IP version.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

We do not use iclk anywhere in the dmtimer driver and so removing it.
Hence removing the timer iclk entries from OMAP4 clkdev table as well.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To improve the clarity of the code, replace the CK_3517 flag used in
the clock data with CK_AM35XX.  The CK_3505 flag can also be
removed, since it is now unused.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

At the moment, read_persistent_clock is implemented at the
platform level, which makes it impossible to compile these
platforms in a single kernel.

Implement these two functions at the architecture level, and
provide a thin registration interface for both read_boot_clock
and read_persistent_clock. The two affected platforms (OMAP and
Tegra) are converted at the same time.
Reported-by: NJeff Ohlstein <johlstei@codeaurora.org>
Tested-by: NStephen Warren <swarren@wwwdotorg.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Using coherent DMA memory with the OMAP DMA engine results in
unpredictable behaviour due to memory ordering issues; as things stand,
there is no guarantee that data written to coherent DMA memory will be
visible to the DMA hardware.

This is because the OMAP dma_write() accessor contains no barriers,
necessary on ARMv6 and above.  The effect of this can be seen in comments
in the OMAP serial driver, which incorrectly talks about cache flushing
for the coherent DMA stuff.

Rather than adding barriers to the accessors, add it in the DMA support
code just before we enable DMA, and just after we disable DMA.  This
avoids having barriers for every DMA register access.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add the SL2 interface IP block and interconnect data.  The SL2 is related
to the IVA-HD subsystem.

Add IP block and interconnect data for the C2C ("Chip-to-chip")
interconnect.  This can provide a direct system interconnect link to
other devices stacked on the OMAP package.

Add the ELM IP block and interconnect data.  The ELM can be used
to locate errors in NAND flash connected to the GPMC.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Add support for direct IP block interconnect ("link") registration to
the hwmod code via a new function, omap_hwmod_register_links().  This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().

This change will allow a subsequent patch to remove the hwmod data
link arrays.  This will reduce the size of the hwmod static data and
also make it easier to generate the data files.  It will also make it
possible to share some of the struct omap_hwmod records across
multiple SoCs, since the link array pointers will be removed from the
struct omap_hwmod.

The downside is that boot time will increase.  Minimizing boot time
was the reason why the link arrays were originally introduced.
Removing them will require extra computation during boot to allocate
memory and associate IP blocks with their interconnects.  However,
since the current kernel development focus is on reducing the number
of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
considered a lower priority.

This patch contains additional complexity to reduce the number of
memory allocations required for this change.  This reduces the boot
time impact: total hwmod link registration time was ~ 2655
microseconds with a simple allocation strategy, but is now ~ 549
microseconds[1] with the approach taken by this patch.

1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
   of 7 samples.  Total uncertainty is +/- 61 microseconds.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Extend the OCP_* register offsets in the struct
omap_hwmod_class_sysconfig to 32 bits.  This is required to add the
OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
bits.

Another possible solution may be to simply add a single 16 bit offset
field in this structure, and to add code to factor that offset into
all OCP_* register accesses.  This would save some memory, since
almost no modules need 32 bit offsets.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

One of the OMAP4 links was missing OCP_USER flags, since it was only
used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
Future patches will switch the hwmod code and data to register
interfaces, rather than hwmods, and it will be mandatory for all
interfaces to have at least one user bit set.  This patch resolves the
issue by adding OCP_USER_DSP and marking the DSP-IVA interface
appropriately.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The timer integration code pokes around in hwmod data structures.
Those data structures are about to change.  Define a function,
omap_hwmod_get_resource_byname(), for the timer integration code to
use instead.

The original patch has been changed to use struct resource by Tony's
request, although the caller of this function should not be a driver._
Platform drivers should get their data through the regular platform_*
functions; DT drivers through the appropriate of_* functions.  This a
function is only for use by OMAP core code in arch/arm/*omap*.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Reviewed-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:

    [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
    [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
    [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
    [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
    [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
    [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
    [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
    [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
    [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
    [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
    [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
    [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
    [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used

Some of them are pretty good catches, such as gpio.c:56 and
usb-tusb6010.c:129.

Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
It seems that the kernel sscanf() ignores the field width anyway for the
%d format, so those changes have been dropped from this second version.

Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
out that a variable was unnecessarily marked static in the
board-omap3evm.c change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c

_omap3_sram_configure_core_dpll is called when SDRC is reprogrammed,
which is done regardless of CONFIG_PM setting, so we always need it's
setup code too. Without this, we hit a BUG() on OMAP3 when kernel is
built without CONFIG_PM:

Reprogramming SDRC clock to 332000000 Hz
------------[ cut here ]------------
kernel BUG at arch/arm/plat-omap/sram.c:342!
Internal error: Oops - BUG: 0 [#1] ARM
...
[<c001c694>] (omap3_configure_core_dpll+0x68/0x6c) from [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x1)
[<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [<c001a478>] (omap2_clk_set_rate+0x14/0x2)
[<c001a478>] (omap2_clk_set_rate+0x14/0x20) from [<c001c9dc>] (clk_set_rate+0x54/0x74)
[<c001c9dc>] (clk_set_rate+0x54/0x74) from [<c022b9c8>] (omap_sdrc_init+0x70/0x90)
[<c022b9c8>] (omap_sdrc_init+0x70/0x90) from [<c022f178>] (omap3pandora_init+0x11c/0x164)
[<c022f178>] (omap3pandora_init+0x11c/0x164) from [<c022849c>] (customize_machine+0x20/0x28)
[<c022849c>] (customize_machine+0x20/0x28) from [<c0225810>] (do_one_initcall+0xa0/0x16c)
[<c0225810>] (do_one_initcall+0xa0/0x16c) from [<c02259e0>] (kernel_init+0x104/0x1ac)
[<c02259e0>] (kernel_init+0x104/0x1ac) from [<c0009cec>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables.  Remove it.

Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.

Thanks to Russell King for pointing out the parts I missed under
plat-omap in the original version and also pointing out the build
errors when CPUFREQ_TABLE support was not enabled.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Remove the include of mach-omap2/common.h from plat-omap/usb.c.  It
appears to be unneeded.  Removing it also resolves the sparse warning:

arch/arm/plat-omap/../mach-omap2/common.h:183:12: warning: symbol 'omap_intc_of_init' was not declared. Should it be static?
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

gcc can apparently handle stack-allocated arrays that use a dynamic
variable as the array maximum.  Rather than using a mutable quantity,
simply use a constant maximum possible size.  To me, code clarity is
improved; and it also avoids the following sparse warnings:

arch/arm/plat-omap/dma.c:886:40: error: bad constant expression
arch/arm/plat-omap/dma.c:892:17: error: cannot size expression
arch/arm/plat-omap/dma.c:970:40: error: bad constant expression
arch/arm/plat-omap/dma.c:972:17: error: cannot size expression

Also drop some dead code from the OMAP1 LCD DMA code:

arch/arm/mach-omap1/lcd_dma.c:80:6: warning: symbol 'omap_set_lcd_dma_src_port' was not declared. Should it be static?
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We currently treat the OCM RAM memory as memory that hangs off an
I/O bus, so use memset_io() to clear it rather than memset().
This also takes care of this sparse warning:

arch/arm/plat-omap/sram.c:199:9: warning: cast removes address space of expression

There is still one SRAM-related sparse warning, but it appears that
fixing it correctly will take some time and thought.

N.B., at some point, the OCM RAM IP block interface code should probably
be reimplemented as an MTD device or something similar under drivers/.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

sparse warns when 0 is passed to a function expecting a pointer argument.
Resolve these warnings by replacing the 0 with NULL.

arch/arm/plat-omap/include/plat/dmtimer.h:319:34: warning: Using plain integer as NULL pointer
arch/arm/plat-omap/include/plat/dmtimer.h:324:35: warning: Using plain integer as NULL pointer
arch/arm/mach-omap2/irq.c:294:22: warning: Using plain integer as NULL pointer
arch/arm/mach-omap1/board-palmz71.c:292:50: warning: Using plain integer as NULL pointer
arch/arm/mach-omap1/board-palmz71.c:295:73: warning: Using plain integer as NULL pointer
arch/arm/mach-omap1/ams-delta-fiq.c:105:63: warning: Using plain integer as NULL pointer
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP1 OHCI driver needs to enable the OCPI IP block before it can
work.  Previously, the driver was simply calling a symbol defined in
the OMAP platform code, but this is incorrect: drivers should be fully
decoupled from platform and architecture code.

So instead, modify the driver to call through a platform_data function
pointer instead.  We skip any DT aspect, since OMAP1 is not scheduled
to be converted to DT in the near future.

This resolves the following sparse warning:

It also gets rid of a cpu_is_omap16xx() call in a driver.

In the long term, it probably makes sense to move the OCPI bus code to
somewhere under drivers/.  This should avoid the whole platform_data/DT
issue with this function.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>

Move the OMAP1 OCPI "bus" code to arch/arm/mach-omap1, since it is
only used on OMAP1 devices.  In the long term, it probably makes sense
to move the OCPI bus code to somewhere under drivers/.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare
functions that are used by other files, but don't include the header
file where the prototype is declared.  This results in the following
warnings from sparse:

    arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static?
    arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static?
    arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static?
    arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static?
    arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static?

Fix by including the appropriate header files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

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: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NFernando 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: NPaul Walmsley <paul@pwsan.com>

With commit c334bc15 (ARM: make mach/io.h include optional), PCMCIA was
broken. PCMCIA depends on __io() returning a valid i/o address, and most
ARM platforms require IO_SPACE_LIMIT be set to 0xffffffff for PCMCIA. This
needs a better fix with a fixed i/o address mapping, but for now we just
restore things to the previous behavior.

This fixes at91, omap1, pxa and sa11xx. pxa needs io.h if PCI is enabled,
but PCMCIA is not. sa11xx already has IO_SPACE_LIMIT set to 0xffffffff,
so it doesn't need an io.h.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Joachim Eastwood <joachim.eastwood@jotron.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Tested-by: Paul Parsons <lost.distance@yahoo.com> (pxa270)
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>