Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

The core files of DSS2. DSS2 commits are split a bit artificially to
make the individual commits smaller, and DSS2 doesn't compile properly
without the rest of the core commits. This shouldn't be a problem, as no
configuration uses DSS2 yet.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.

Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:

- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations

The upcoming DSS2 uses VRAM manager.

VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Split arch/arm/plat-omap/include/mach/omapfb.h into two files:

include/linux/omapfb.h - ioctls etc for userspace and some kernel
                         stuff for board files
drivers/video/omap/omapfb.h - for omapfb internal use

This cleans up omapfb.h and also makes it easier for the upcoming new
DSS driver to co-exist with the old driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: NTony Lindgren <tony@atomide.com>

SMS_ROT_* registers are used by VRFB rotation engine.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-By: NJamie Iles <jamie@jamieiles.com>

Added runtime programming for the differences in EHCI interface between
OMAP3EVM revisions (Rev >= E) and (Rev < E).

Changes:
	- EHCI PHY reset GPIO pin is 21 on Rev >= E while Rev < E
	  uses GPIO pin 135.
	- Rev >= E uses EHCI Vbus enable GPIO22 line.
	- Rev >= E uses GPIO61 to select EHCI port either on main board or
	  on Mistral Daughter Card (MDC). OMAP3EVM Rev < E doesn't have
	  EHCI port on main board.
	- Currently GPIO61 it programmed to enable EHCI port on main
	  board only.
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>

Added function to differentiate between the OMAP3EVM revisions. The
chip-id of the ethernet PHY is being used for this purpose.

Rev A to D : 0x01150000
Rev >= E   : 0x92200000
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch disables a GPIO module when all pins of a GPIO
module are inactive (clock gating forced at module level) and
enables the module when any gpio in the module is requested.

The module is enabled only when "mod_usage" indicates that no GPIO
in that  module is currently active and the GPIO being requested
is the 1st one to be active in that module.

Each module would be disabled in omap_gpio_free() API when all
GPIOs in a particular module becomes inactive. The module is
re-enabled in omap_gpio_request() API when a GPIO is requested
from the module that was previously disabled.

Since individual GPIO's bookkeeping is added in this patch
via "mod_usage", the same is used in omap_set_gpio_debounce()
& omap_set_gpio_debounce_time() APIs to ensure that the gpio being
used is actually "requested" prior to being used (Nishant Menon's
<nm@ti.comSuggestion)

GPIO module level details are specific to hardware and hence
introducing this patch in low level layer (plat-omap/gpio.c)
Signed-off-by: NCharulatha V <charu@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch uses a tasklet implementation for
sending mailbox messages.
Signed-off-by: NC A Subramaniam <subramaniam.ca@ti.com>
Signed-off-by: NRamesh Gupta G <grgupta@ti.com>
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently, this facilitates both the tesla and ducati
sides to request for the same irq through an
omap_mbox_get() call.
Signed-off-by: NC A Subramaniam <subramaniam.ca@ti.com>
Signed-off-by: NRamesh Gupta G <grgupta@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds code changes in the mailbox driver module to
add support for OMAP4 mailbox.
Signed-off-by: NHari Kanigeri <h-kanigeri2@ti.com>
Signed-off-by: NC A Subramaniam <subramaniam.ca@ti.com>
Signed-off-by: NRamesh Gupta G <grgupta@ti.com>
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Expose omap_mbox_enable()/disable_irq()
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>

Also removed from tx_data
Signed-off-by: NC A Subramaniam <subramaniam.ca@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

No need to handle it in isr, since irq won't happen during isr.
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

It's not used at present.
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Any protocol should be handled in the upper layer and mailbox driver
shouldn't care about the contents of messages.
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds resource information of mailbox driver for
OMAP4 mailbox module. Register base address also added
Signed-off-by: NC A Subramaniam <subramaniam.ca@ti.com>
Signed-off-by: NRamesh Gupta G <grgupta@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

map_iovm_area is only called from a context where its second argument is
known not to be NULL, so drop the unnecessary test.  If new could be NULL,
the initialization of da should be moved below the test.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// <smpl>
@match exists@
expression x, E;
identifier fld;
@@

* x->fld
  ... when != \(x = E\|&x\)
* x == NULL
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

All of the OMAP3 IVA physical address macros in
plat-omap/include/plat/omap34xx.h are wrong[1]:

OMAP34XX_IVA_INTC_BASE: The IVA interrupt controller does not appear
to be accessible from the L3 interconnect, and in any case is
definitely not at 0x40000000; the latter address appears to be the
internal IVA physical address base for the OMAP2420's interrupt control[2].

OMAP34XX_DSP_BASE: The section of L3 physical address space mapped to
the IVA starts at 0x5c000000, not 0x58000000.

OMAP34XX_DSP_MEM_BASE: It's not clear what this refers to, but it's not
in the L3 IVA address space.

OMAP34XX_DSP_IPI_BASE: The Intrusive Port Interface is a relic from
the OMAP2420 days and no longer applies to OMAP3.

OMAP34XX_DSP_MMU_BASE: The DSP MMU is mapped at 0x5d000000, not 0x5a000000.


Nothing that uses these can possibly be working, so drop them.  When
future code needs these, correct versions can be added in.

1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. W, Table 2-8:
   "L3 Interconnect View of the IVA2.2 Subsystem Memory Space."  p. 229.

2. OMAP2420 Multimedia Processor Silicon Revision 2.1.1, 2.2 (Rev. Q),
   section 2.2.4.1, "IVA Memory Space Seen by L3", p. 132.

3. ibid., section 4.3.11, "DSP IPI Overview", p. 200.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add support for omap hsmmc2 8-bit mux configuration.
Signed-off-by: NMadhusudhan Chikkature <madhu.cr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The speed ctrl bit for MMC I/O is part of CONTROL_PROG_IO1 register
in omap3630.This patch sets it up accordingly.
Signed-off-by: NMadhusudhan Chikkature <madhu.cr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The use of the spin lock, which supposed to protect the the
dma_op_mode causing "INFO: inconsistent lock state" on
playback start.
Remove the spin locks around the dma_op_mode, when it's
purpuse is to protect the dma_op_mode.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: NJarkko Nikula <jhnikula@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Cache flush operation is handled in the upper client layer and iovmm
modules doesn't have to care about it. This patch will improve some
performance with current camera isp driver.
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

MPU side (v)-(p) mapping is necessary only if IOVMF_MMIO is set in
"flags".
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add platform init code for EHCI driver.

Various fixes to the original patch by Ajay Kumar Gupta <ajay.gupta@ti.com>
and Anand Gadiyar <gadiyar@ti.com>.

Overo support added by Olof Johansson <olof@lixom.net>
Beagle support added by Koen Kooi <koen@beagleboard.org>
CM-T32 support added by Mike Rapoport <mike@compulab.co.il>
Signed-off-by: NSigned-off-by: Olof Johansson <olof@lixom.net>
Acked-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NKoen Kooi <koen@beagleboard.org>
Signed-off-by: NMike Rapoport <mike@compulab.co.il>
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add missing declarations to allow the recently introduced
ehci-omap driver to build on OMAP3
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add support to detect AM3505/AM3517 devices at runtime.
Also updates the CPU names printed during boot.
Signed-off-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

3630 is getting treated like next rev of 3430
omap_chip.oc variable has to be updated for 3630 version

Otherwise the Core power domain is not getting registered.

This gets used in the registration of power domains in:
"arch/arm/mach-omap2/powerdomains34xx.h"
core_34xx_es3_1_pwrdm
OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1)

Core power doman will get registered for 3630 only when .oc is
populated correctly.

Tested on Zoom3(3630) board
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Acked-by: NAlexander Shishkin <virtuoso@slind.org>
Acked-by: NAri Kauppi <kauppi@papupata.org>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:

New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.

Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12836&contentId=52606

Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=125343303400003&r=1&w=2

Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices

As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by using "FEATURES"
  infrastructure.
  For details how to do this, see thread:
  http://marc.info/?t=125050998500001&r=1&w=2
* Most of existing 34xx infrastructure can be reused(almost 90%+)
	- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
	  all over the place
	- lesser chance of bugs due to reuse of proven code flow
	- 36xx specific handling can still be done where required
	  within the existing infrastructure

NOTE:
* If additional 34xx series are added, OMAP3430_REV_ESXXXX can be
  added on top of the existing 3630 ones are renumbered

This patch was tested on SDP3430, boot tested on 3630 platform using
3430sdp defconfig
Signed-off-by: NMadhusudhan Chikkature Rajashekar <madhu.cr@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Cc: Allen Pais <allen.pais@ti.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Sergio Alberto Aguirre Rodriguez <saaguirre@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add runtime check for these OMAP35x variations
based on the detected Si features:
  OMAP3503, OMAP3515, OMAP3525 and OMA3530.

Also, delayed the call to pr_info() into actual
variant is detected in omap3_cpuinfo()
Signed-off-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP35x family has multiple variants differing
in the HW features. This patch detects these features
at runtime and prints information during the boot.

Since most of the code seemed repetitive, macros
have been used for readability.
Signed-off-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The l3_ocpi_ck clock is needed on omap7xx processors for USB.
Additionally, bit 8 of the SOFT_REQ_REG needs to be enabled for
the usb_dc_ck on omap7xx, which is a different bit than that
of the omap16xx-defined clock of the same name.

I added a provision for the usb_dc_ck and l3_ocpi_ck clocks as
dc_clk and hhc_clk, respectively, for omap7xx CPUs.  Additionally,
I added a check in machine_without_vbus_sense for all omap7xx
devices, as presently I know of no omap7xx-based devices that
have vbus sense, and it made more sense to me to use a cpu check
here than to spell out each machine one at a time.  Finally, DMA
is disabled for omap7xx, as it causes problems with these chips.

Cc: linux-usb@vger.kernel.org
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The MMC mux pins normally used by omap chips in devices.c
are different from what is needed by omap7xx chips.  This
change adds a conditional around the mux setup code to
enable the correct mux pins.

The omap730 and omap850 both use a different clock for the "fck"
clock of the MMC interface than other omap processors based on the
SOFT_REQ_REG, pin 12.  The "ick" clock is the same as that used
by other omap processors.

* Added the missing clock definition as mmc3_ck to clock.h
* Added the clock definition to omap_clks in clock.c
* Added CK_7XX to the mmci-omap.0 "ick" clock already in clock.c

With these changes, it is now possible to initialize and use MMC
cards with omap730 and omap850 devices.
Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Zoom2/Zoom3 kind of boards do not use omap uarts for console.
These use external debug board for console.

So these boards should not have "Uncompressing Kernel...."
log put on omap uarts.

By interoducing OMAP_LL_DEBUG_NONE option,
unnecessary writes to omap uarts is avoided.

In future, the DEBUG_LL interface will be enhanced
to use external debug board.
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Eliminate OMAP_MAX_NR_PORTS

Note that also the null terminator entry for omap1
serial_platform_data needs to be now removed to avoid
oopsing.

Note that mach-omap1 uses struct plat_serial8250_port
array, which requires a null terminator at the end,
and that's why we need to use ARRAY_SIZE - 1. This
is not needed on mach-omap2 as the array used is
struct omap_uart_state, and does not use a null
terminator.
Signed-off-by: NAlexander Shishkin <virtuoso@slind.org>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The closing parenthesis was not in the right location.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS.  This causes ondemand and conservative governors to
sample CPU load more often resulting in more responsive behavior.

Tested on Android 2.6.29; using this value and conservative governor, CORE
power consumption on Zoom2 was comparable to the old and unresponsive
10,000,000uS value while UI responsiveness was greatly improved.
Signed-off-by: NMike Turquette <mturquette@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Due to an OMAP3 errata (1.142), on HS/EMU devices SDRC should be
programed to issue automatic self refresh on timeout
of AUTO_CNT = 1 prior to any transition to OFF mode.
This is needed only on sil rev's ES3.0 and above.

This patch enables the above needed WA in the SDRC power register
value stored in scratchpad, so that ROM code restores this value
in SDRC POWER on the wakeup path.
The original SDRC POWER register value is stored and restored back
in omap_sram_idle() function.

This fixes some random crashes observed while stressing suspend
on HS/EMU devices.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NKalle Jokiniemi <kalle.jokiniemi@digia.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>