arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS
driver. A more logical place for it is in include/video.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Blindly setting 1.2V in the initial structure may not even match the
default voltages stored in the voltage table which are supported for
the domain. For example, OMAP3430 core domain does not use 1.2V and
ends up generating a warning on the first transition.

Further, since omap2_set_init_voltage is called as part of the pm
framework's initialization sequence to configure the voltage required
for the current OPP, the call does(and has to) setup the system
voltage(curr_volt as a result) using the right mechanisms appropriate
for the system at that point of time. This also overrides
initialization we are currently doing in voltage.c making it
redundant. So, remove the wrong and redundant initialization.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP4 has two different Devices IVA and DSP. DSP is bound
with IVA for DVFS. The registration of IVA dev in API
'omap2_init_processor_devices' was missing. Init dev for
'iva_dev' is added.

This also fixes the following error seen during boot as
omap2_set_init_voltage can now find the iva device

	omap2_set_init_voltage: Invalid parameters!
	omap2_set_init_voltage: Unable to put vdd_iva to its init voltage
Signed-off-by: NShweta Gulati <shweta.gulati@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

So that omap_vram_set_sdram_vram() is called before
omap_vram_reserve_sdram_memblock().
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If an error occurs in the L3 on any other initiator than MPU,
the interrupt goes unhandled given that the 'base' register
was calculated with the initialized err_source value (which
coincidentally points to MPU) and not with the actual source
of the error.

Removed parenthesis that are not needed for the touched lines.
Signed-off-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This fixes broken build when using binutils 2.21.
Signed-off-by: NOskar Andero <oskar.andero@sonyericsson.com>
Signed-off-by: NTony Lindgren <tony@atomide.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>

As per OMAP3 erratum (i671), ROM code adds extra latencies while
restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1.

This patch stores 0's in scratchpad content area corresponding to
AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since
it won't respect proper programing scheme.

This register is then stored in prcm context. The saving and restore
is now done by kernel side.

Here follow the erratum description

DESCRIPTION

After OFF mode transition, among many restorations, the ROM Code restores the
CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL.

In case the restoration data stored in scratchpad memory contains a field
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and
locks the PER DPLL does not respect the PER DPLL programming scheme.

In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER
DPLL, the ROM Code does not hang. Only extra latencies are introduced at
wake-up.

WORKAROUND

When saving the context-restore structure in scratchpad memory, in order to
respect the PER DPLL programming scheme, it is advised to store 0 in the
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL field of the saved structure.

After wake-up, the application should store in CM_AUTOIDLE_PLL register the
right desired value.
Signed-off-by: NEduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The saving of CCR.CM_AUTOIDLE_PLL is done in scratchpad area.

However, in current code, the saving is done for CM_AUTOIDLE2_PLL
(offset 0x34) instead of CM_AUTOIDLE_PLL (offset 0x30).

This patch changes the code to save the correct register.
Signed-off-by: NEduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
running, and also to get the pixel clock's source clock rate from the
fck.

On OMAP4 the clock data is set up in a different way, as there's no ick,
dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
dss_dss_clk if the DSS_FCK.

>From DSS driver's point of view the dss_fck sounds like an ick, and
dss_dss_clk is the fck. While this is not entirely correct from HW point
of view, especially for the ick, configuring the clock aliases that way
makes DSS "just work" with OMAP4's clock setup.

In the (hopefully near) future DSS driver will be reworked to use
pm_runtime support which should clean up the clock code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Benoît Cousson <b-cousson@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>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

Use irq_set_chip_and_handler() instead. Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Convert to the new function names. Automated with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

In Blaze and Panda, 32KHz clock - CLK32KG to WLAN is supplied
from Phoenix TWL6030.
Add CLK32KG platform data to blaze and omap4panda board file.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Make sure the kernel can be compiled with both OMAP2 and OMAP3 camera
support linked in, and give public symbols proper omap2/omap3 prefixes.
Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The omap3isp platform device requires platform data. Instead of
registering the device in omap2_init_devices(), export an
omap3_init_camera() function to fill the device structure with the
platform data pointer and register the device.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The ISP CBUFF module isn't use, its resource isn't needed.
Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add new/changed base address definitions and resources for
OMAP3630 ISP.

The OMAP3430 CSI2PHY block is same as the OMAP3630 CSIPHY2
block. But the later name is chosen as it gives more symmetry
to the names.
Signed-off-by: NTuukka Toivonen <tuukkat76@gmail.com>
Signed-off-by: NVimarsh Zutshi <vimarsh.zutshi@gmail.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Commit db97eb7d
(omap: gpmc: enable irq mode in gpmc) enabled interrupts for
GPMC (General Purpose Memory Controller). However, looks like
this patch only works on omap3. Fix the issues to avoid warnings
on omap4 during the boot.

GPMC: number of chip select is 8, CS0 to CS7. One less IRQ
allocated throws below warning at boot:

[    0.429290] Trying to install type control for IRQ409
[    0.429290] Trying to set irq flags for IRQ409

Resolve following warning messages in boot when irq chip is not set:

[    0.429229] Trying to install interrupt handler for IRQ402
[    0.429229] Trying to install interrupt handler for IRQ403
[    0.429229] Trying to install interrupt handler for IRQ404
[    0.429260] Trying to install interrupt handler for IRQ405
[    0.429260] Trying to install interrupt handler for IRQ406
[    0.429260] Trying to install interrupt handler for IRQ407
[    0.429290] Trying to install interrupt handler for IRQ408

Resolve following warning in OMAP4:
[    0.429290] gpmc: irq-20 could not claim: err -22
Signed-off-by: NBalaji T K <balajitk@ti.com>
[tony@atomide.com: combined patches into one, updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

the pandaboard does not use the VUSIM or VAUX1 power regulators on the TWL6030
and are left floating. if the VUSIM and VAUX1 power regulators are initilized,
noise on the unloaded regulators generates an overcurrent interrupt causing the
system to power down. this patch removes the initialization of the unused power
regulators of VUSIM and VAUX1.
Signed-off-by: NDavid Anders <x0132446@ti.com>
Acked-by: NAndy Green <andy.green@linaro.org>
Acked-by: NAnand Gadiyar <gadiyar@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The handler function may be called from the point it is registered.
Since the handler inspects IRQ numbers, we must set them up before
registration.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix the return value for the successful case.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Adding DVI support to OMAP4 PandaBoard.

PandaBoard uses TFP410 DVI Framer chip
http://focus.ti.com/lit/ds/symlink/tfp410.pdf

The TFP410 gets its power enable and display data over GPIO lines muxed
in from OMAP4430. PandaBoard supports other LCD displays through
expansion
connectors, following board rework. This will disable the DVI interface.
However, the existing mux settings remain the same

PandaBoard additionally supports display over HDMI interface. It is
mutually exclusive to display over DVI. Hence the mux settings need to
be
configured seperately, as and when HDMI is enabled

Also, I2C3 bus used for reading EDID data from DVI Monitors is
registered here. Since the design is similar to BeagleBoard, the code
for the same is taken from the kernel.org commit e3333f48
(omap: Adding beagle i2c eeprom driver to read EDID)
Reviewed-by: NManjunath G Kondaiah <manjugk@ti.com>
Reviewed-by: NAnand Gadiyar <gadiyar@ti.com>
Reviewed-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NRaghuveer Murthy <raghuveer.murthy@ti.com>
[tomi.valkeinen@ti.com: fixed conflicts with HDMI]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Adding  board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: NMythri P K <mythripk@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Adding  board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: NMythri P K <mythripk@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The wl1271's irq line is completely controlled by the 1271 device, and
the host does not not need to pull it up.

While there's no functional effect, letting the host pull this line up is
just redundant, and wastes power.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This adapts the register offsets used to read the CPU DIE ID registers
when run on 44XX so they match what is in the OMAP4430 Reference Manual
page 269
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove duplicate mux modes to make the binary smaller:

text    data     bss     dec     hex filename
9378   24472       0   33850    843a mux44xx.o
9378   19104       0   28482    6f42 mux44xx.o

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix compile when CONFIG_OMAP_MUX is not selected
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use the mux framework to initialise the serial pads.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use the mux framework to initialise the serial pads.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use the mux framework to initialise the serial pads.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add macro for defining static pins in the board file.

We can now start implementing pin multiplexing in the platform init
code for devices that call omap_hwmod_mux_init. Currently that is
only implemented for serial.c.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently OMAP_DEVICE_PAD_IDLE flag is used to mux pins
dynamically. This can be simplified by using the enabled
state variable of each pad. This also fixes the issue of
the static pads not getting muxed after idling and
disable/enable state transitions.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This avoids going through the list unnecessarily when
idling devices for runtime PM.

Based on an earlier patch by sricharan <r.sricharan@ti.com>.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The patch adds the new power management trace points for
the OMAP architecture.

The trace points are for:
- default idle handler. Since the cpuidle framework is
  instrumented in the generic way there is no need to
  add trace points in the OMAP specific cpuidle handler;
- SoC clocks changes (enable, disable, set_rate),
- power domain states: the desired target state and -if different-
  the actually hit state.

Because of the generic nature of the changes, OMAP3 and OMAP4 are supported.

Tested on OMAP3 with suspend/resume, cpuidle, basic DVFS.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This Patch adds OPP enteries for IVA  in OMAP4 OPP Table

Tested on OMAP4430 SDP Board.
Signed-off-by: NShweta Gulati <shweta.gulati@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Update MPU, IVA and CORE voltage Rail values obtained from
OMAP4430 Data Manual Operating Condition Addendum_v0.4.

Tested on OMAP4430 SDP Board.
Signed-off-by: NShweta Gulati <shweta.gulati@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Almost all OMAP4 boards support OPP 800 MHz and OPP 1 GHz.
Enable them in OPP Table. For small minority of boards which use
OMAP4430-800 MHz device OPP 1GHz is not supported,
OPP 1GHz should be disabled from board file.
Signed-off-by: NShweta Gulati <shweta.gulati@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>