omap: mailbox: enable mailbox irq per instance

The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.

The enable_irq function should be called every time a
new mbox instance is created, in the generic platform
mailbox layer.

Change-Id: I1b7148fd0342a335e3b45cfe349c43a8491ae5c1
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: iommu: apply latency constraint based on power domain

When the iommu is taken out of reset, a latency constraint is
set to avoid its power domain going to retention/off. The iommus
for DSP and M3 reside in DSP and Core power domains respectively,
and therefore the API for setting the constraints is different.
This patch uses the appropriate API depending on the iommu (power
domain) the latency constraint is being applied on.

Change-Id: I3fa4485b3c405aa10c32a3fe0b7ac694d484ee21
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
omap: remoteproc: handle latency constraints for non-ipu rprocs

The omap remoteproc code is incorrectly applying the latency
constraint on the CORE domain for all remote processors. This
would apply only for ipu, and the others need them to be applied
on their respective domains. This patch fixes the same.

Change-Id: I1768d78b7029366d05cb5df16a032de597e1e5f3
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: add support for a boot register

Some remote processors (like DSP) need to explicitly configure
a boot address in a special register or memory location, and
this is the address from which they start executing code when
taken out of reset.

Support for this infrastructure has been added to remoteproc
code. The memory or register address where the boot address
is to be stored is supplied through the boot_reg field of the
platform data in the remoteproc. The omap_rproc_start function
will fetch the boot address from the image, and write this
address into the boot register, if provided, before taking the
processor out of reset.

Change-Id: I4efc5824791eda6e23e5d568f4568a3fe3d0014b
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: add ipu and dsp as configurable remoteproc instances

OMAP4 and OMAP5 both support two remoteproc instances - ipu &
dsp. The CONFIG_OMAP_REMOTE_PROC menuconfig option enabled
support for all OMAP remoteproc instances, but there was no
choice to enable/disable a specific remoteproc instance.

This patch adds two additional dependent config options for
finer control over these remoteproc instances. The option
CONFIG_OMAP_REMOTE_PROC will continue to be the generic
option for enabling remoteproc driver support for OMAP.

Change-Id: I9688672e4c758b9e4f4c0fb4f83654ef7b3cf48f
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
omap: add dsp carveout for remoteproc functionality

remoteproc uses DDR carveout memories for the functionality
of different rproc instances. New interfaces have been added
to perform this carveout memory during board initialization
for DSP. This patch reserves two types of carveout memory -
one whose address is dynamic, and another that leverages a
fixed static range. The dynamic pool will be used for
allocating memory for firmware sections that have no physical
memory allocated. The static pool will be used to validate the
firmware sections with fixed physical addresses.

This patch also assigns addresses for the Virtio vring buffers
for DSP. This is previously not handled, and the buffers are
currently assigned from the static pool associated with the
dsp. The rpmsg bus initialization sequence is enhanced to
process all the vprocs even if an earlier one in the list
fails due to memory requirements.

Change-Id: I0dec512b63904d3ffe0867ce00150b6c21a80805
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap4: tuna: reserve memory for dsp

(Commit modified for tuna)

DSP is configured to use 4 MB of memory. Memory for DSP is
reserved during board initialization. The memory is just
below the reserved memory for all ION heaps. This memory is
reserved at boot-time using the memblock API and it is
reserved only if CONFIG_REMOTE_PROC_DSP is enabled.

Change-Id: I437fb5e2d8c2fd5f900bbaeb213dbe662ac8208c
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-4430sdp.c
	arch/arm/mach-omap2/board-44xx-tablet.c
	arch/arm/mach-omap2/board-omap4panda.c
configs: tuna: zero out remoteproc dynamic carveout (dsp)

(Commit modified for tuna)

The dsp text & ipc sections have been programmed to use static
carveout currently, so there is no need to set-aside the dynamic
carveout memory for the same.

Change-Id: I68d5662cff86f4d5a231fcfe36e59b394c315047
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>

Conflicts:
	arch/arm/configs/panda_defconfig
omap: remoteproc: add support for dsp

Add the necessary rproc data for dsp for proper functionality
including power management.

The logic for getting the memory pool information has also
been updated to work for dsp.

Change-Id: I8c04fdad2bd85f92ea8152fd62596d0f76fa28fc
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: rpmsg: add dsp as a virtio rproc device

Add a dsp virtio rproc device to the omap_rpmsg_vproc
array, so that the corresponding virtio device can be
created and registered with the virtio bus.

The device is included only if the dsp remote rproc
is enabled.

Change-Id: Ie33f9a8bee7b1a3c603fe8f33a44a4c8f01426e2
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: ignore static pool check for dsp IO buffers

The dsp remoteproc is using the same pool of 1D buffer
region as the ducati. This cannot be configured in the
static pool of dsp as this memory region is co-located
only with ducati memory, but not dsp. So, ignore the
valid memory check to proceed with the loading & booting
for dsp.

Change-Id: Ia92a2b7329cd0b9431afad4dde8c83396d861ba2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Jesse Villarreal <jesse.villarreal@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
remoteproc: enable core dump and halt-on-crash for dsp

Support for halt-on-crash feature is enabled for dsp. The
generation of code dump file is also enabled for dsp. DSP
memory can be pulled from following file for offline
analysis:
	/d/remoteproc/omap-rproc.0/core

Currently dsp registers are not saved. The DSP IO buffer
area is skipped as per core-dump design.

Change-Id: I705d22707ef95bdd9cd722257668595622b5bb42
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: use device-specific dump-register ops

The current omap register dump function is catering only to
ARM cores. Introduce device-specific dump register functions
so that the omap remoteproc code can call into them based on
the processor type.

This patch also adds a minimal support for dumping dsp
registers in addition to moving the existing functionality
for ARM cores to the device-specific function.

Change-Id: Ic446695a6a5a1a4b1f600c1900f74c3e5932c158
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: add watchdog timer support for dsp

Use GPTimer 6 as the watchdog timer for dsp. This is used
specifically instead of the WDT3, as the latter is not
capable of generating an interrupt to the DSP core. The
former is used to generate an interrupt and thereby
gather some watchdog context data.

Change-Id: I7f8d6e7070cc14f4339e79e42a6affe169270bb2
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: resmgr: support setting constraints on dsp

Add support to set constraints on the DSP processor.

Change-Id: I2d0b80b807897fb88bd968f5f011b604f146587f
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
OMAP4: OPP: correct hwmod name for dsp in opp_def_list

Replace "dsp" with "dsp_c0" in the opp definition list.

The "dsp" name refers to the dsp's iommu hwmod, and not to the
dsp core itself (iommu is not opp-scalable).

"dsp_c0" is the correct hwmod name that should be used in
the OPP definitions list.

Change-Id: I69e89e86de32b2c0f0afdb17533548fab91cee53
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap4: hwmod_data: add clocks to dsp processor device

The dsp processor hwmod device (dsp_c0) is defined primarily as
a pseudo-hwmod device with only reset control. This shares the
same functional clock along with the dsp hwmod device that is
mainly used for controlling the MMU. This clock name is added to
this pseudo-hwmod device, as it enables the power domain lookup.
This is required to be able to put any latency constraints on
the dsp using the omap_pm_set_max_dev_wakeup_lat api.

There is no major effect on the clock framework itself due to
this change, as the clock enable & disable will simply be
reference counted and the functionality would be identical as
before.

Change-Id: I83d055806a62c583d914ead2b93371413d0b26a9
Signed-off-by: Suman Anna <s-anna@ti.com>
MUSB: Disable PING for control ep in OTG host mode

We are observing that USB 3.0 hub is not supporting PING request
from OTG host device as a result it fails to enumerate. Disable
PING packet in OTG Host mode for control ep and we dont see this
issue any more. We analyzed traffic between a USB2.0 PC host and
the USB3.0 device and observed that the host does not send PING
packets during enumeration. Turning off PING packets in the OTG
host for control ep resolves this issue. Although we observed
this on a USB 3.0 hub, the issue could be there with other
USB 2.0/3.0 devices if they dont support PING protocol

Change-Id: I44f36fc81d3b6429e59f8a73cf17545e7cb9328b
Signed-off-by: Huzefa Kankroliwala <huzefank@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
OMAP4: Android Kernel Names and Versions

Reference patch of the kernel naming and
README on the rules of the naming format
adn when the name need to change.

Change-Id: Ifac1ed946750666b9994f13d6a0d78d002bb01e0
Signed-off-by: Atanas (Tony) Zlatinski <zlatinski@gmail.com>
omap: Adding opp functions to gpu platform data.

This is required for providing opp framework access to SGX kernel module.

Change-Id: Ie968a6c51ac636b70909257be4c51430c4cc3d48
Signed-off-by: Rogelio Garcia <rgarcia@ti.com>