OMAPDSS: DSSCOMP: Remove PVR_SGX dependency.

In order to disable the in-kernel version of the DDK
and be able to use it as a module we need to remove
this dependency.
No harm to DSSCOMP, it will just wait until a DDK
is installed to execute.

Change-Id: Ie1436a45fb20044d0121eb196c6155b50baa7915
Signed-off-by: Rogelio Garcia <rgarcia@ti.com>
omap: fix dsscomp platform default to configure a 16MB slot size

Initial commit over allocated the default tiler slot

Change-Id: Ic5ac1048a9f4e43f44c2d568de0903aa7f33a5ba
Signed-off-by: Tony Lofthouse <a0741364@ti.com>
remoteproc: add an api to do pa to da conversion

Added an api to provide memory translation from a
physical address to a device virtual address.

Change-Id: I476ce1ba8dc53562c500ad069be42b62e69c5ee3
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: remove pa hardcoding of IPU_MEM_IOBUFS

While adding a mem entry, we currently check the pa of
IPU_MEM_IOBUFS and mark the entry not to be considered
during core dump. The pa hardcoding is removed in this
patch and we use the resource name instead, to make it
independent of the address location of this section.

Change-Id: If0fa893e033b8d0252d8d9d13532c7385417045c
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@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>
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>

Conflicts:
	arch/arm/mach-omap2/remoteproc.c
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>
remoteproc: config: enable dsp by default

The DSP processor is currently not enabled by default in the
menuconfig. This is being turned on by default to make sure
DSP is activated, and usable in the system.

A DSP binary, tesla-dsp.bin is expected to be present in
the firmware folder for a successful load of the DSP remote
processor.

Change-Id: Ibd305a5a22e98cd09e59e037e428c49a4242abd2
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: set the load boot address in activate function

This is needed because the register holding the boot address may
lose context if a deep c-state is reached (either during Device
OFF or during suspend) by the power domain where the register
resides.

Save the extracted bootaddr and then populate the boot address
register before taking the remoteproc out of reset in the activate
function to cover both rproc_start and resume paths.

Change-Id: I0ab3a70268877bcf55d053c9144e3fb834b58939
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
omap: remoteproc: fix a compilation error on autosuspend disable

The patch,
"omap: remoteproc: set the load boot address in activate function",
introduced a compilation error when the remoteproc autosuspend is
disabled from the kernel menuconfig.

drivers/remoteproc/omap_remoteproc.c: In function 'omap_rproc_activate':
drivers/remoteproc/omap_remoteproc.c:191: error: 'struct omap_rproc_priv' has no member named 'bootaddr'
drivers/remoteproc/omap_remoteproc.c: In function 'omap_rproc_start':
drivers/remoteproc/omap_remoteproc.c:470: error: 'struct omap_rproc_priv' has no member named 'bootaddr'
make[2]: *** [drivers/remoteproc/omap_remoteproc.o] Error 1
make[1]: *** [drivers/remoteproc] Error 2
make: *** [drivers] Error 2

The same has been fixed.

Change-Id: I99506d6d30724e51a0325762d9ba2dff533fe852
Reported-by: Mihail Dobrev <x0099086@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
remoteproc: export rproc_da_to_pa function

The rproc_da_to_pa function has been converted from an internal
function to a public function. The function's signature is also
modified to be similar to its counter-part and already exported
function, rproc_pa_to_da.

Change-Id: I30492e90ea839124483b7eefd41cb8bec45065ce
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: return -EAGAIN on a suspend time out

Support has been added on the remote processor side to allow
applications to deny the remote processor from going into a
suspend state. If one or more applications on the remote
processor request to avoid suspend, then the suspend flag is
never set by the remote processor while the request is active,
resulting in a timeout on the host side suspend code.

The runtime suspend function for remoteproc returns -EIO at
present in case of a timeout, causing the runtime pm framework
to avoid further runtime pm suspend callbacks. This is not
desired and hence the return value is changed to -EAGAIN. This
allows the runtime pm framework to retry the suspend after the
re-expiration of the timeout. This would allow the applications
on the remote processor to allow or disallow suspend independently
of the host-side.

The inital idea of having -EIO was to avoid callbacks, since a
timeout would mean that the remoteproc is in an error state.
However, if the remoteproc were in a bad state at this point, the
recovery mechanism would kick in and reload the image.

Change-Id: Ic7b9cfa220724e8024b960704598ec93854de86c
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Paul Hunt <hunt@ti.com>
remoteproc: use dev_dbg to print image version

The version of the remote processor's resource table format is printed
using dev_info during the startup path of a remoteproc. The version
changes very rarely and hence is converted to use a dev_dbg. An error
message is printed anyway in case of a mismatch, so this conversion is
useful in helping improve the overall processor init time.

Also, version info can be looked up using an offline readrprc utility.

Change-Id: I546d3c73582bb7a3fdb2b32b4e3df03ce3a6e7f2
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: add a notification for loading error

When calling rproc_get for the first time, the loading of
the remoteproc image will be requested using a non-blocking
request_firmware_no_wait, and the caller can continue before
the actual loading is complete.

The loader later can return an error due to a non-existing
or wrong image and there should be a way to notify about this
to users having a rproc handle.

This functionality is added and is leveraged by rpmsg to
release some resources it had already acquired since requesting
a firmware load.

Change-Id: I1d3523efbcfd613bca74d363084791ceaaaa9989
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
remoteproc: add a notify event for firmware preload

Added a new rproc event, RPROC_PRELOAD, to send a notification
about commencement of loading of a image into remoteproc's
memory. This event will currently be used for bumping up the
remoteproc frequency to optimize the overall boot time of the
remote processor.

Change-Id: I7e36e54fe938b3242b9e87fd33d6e190a1233083
Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
remoteproc: omap: differentiate auto-suspend from system suspend

The omap remoteproc driver sends a mailbox message to the remote
processor requesting it to save its context and then be suspended.
This can happen either through the runtime auto-suspend path or
through the system suspend.

The mailbox message being sent to the remote processor is now
differentiated between the two paths. This differentiation provides
flexibility on the remote processor to allow an application cancel
auto-suspend. This flexibility is needed as there can be some
operations wherein there is no on-going activity between the host
and the remote processor with the remote processor idle waiting for
an event that would take more time to complete than the auto-suspend
timeout.

The auto-suspend cancellation is detected by the driver on the
host-side through a timeout for the processor to be idled, and is
simply rescheduled.

Change-Id: Ifdeeb80a632ac0145194d3c20f66256226e7efd4
Signed-off-by: Shahid Akhtar <sakhtar@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: rpres: add api to lookup max frequency for a remote device

A new public function, rpres_get_max_freq, is added to perform a
lookup for the maximum supported frequency from the OPP table for
a remote processor device.

This API can be used by the remote resource layer in sharing this
data to the remote processor application code for performing power
related policy decisions.

Change-Id: Idbea6884fa47b3bd1f000b6f696fbbcf7036a6ee
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Paul Hunt <hunt@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>