rpmsg: client: add more options to the sample

Options:

@threads=1	number of thread per rpmsg channel
@msg_n=100	number of messages to send to the remoteproc per thread
@delay=0	delay between each message
@rand=0		delay between messages is random value from 0 to @delay
@print_every	print a trace every @print_every messages

Value showed are default values and it can be changed.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
remoteproc: use runtime PM APIs to turn on/off the remote processor

Use runtime PM framework to turn on/off the remote processors.
The operations start and stop are still available in case of some
actions are needed by the below layer before turn on and after
turn off the remote processor.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
omap: remoteproc: migrate to runtime PM

Implement activate and deactivate function in order to work with
runtime PM framework.

Now, functions device_enable and device_shutdown are not needed anymore.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
remoteproc: add suspend and resume support

Add support for system wide and runtime suspend a resume.
This functions should be registered by the platform driver
and implement the low level suspend and resume functions
if needed.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
omap: remoteproc: implement suspend and resume callbacks

Implement resume and suspend callbacks, that way omap remote
processors can support suspend and resume.

The host processor can not save the context of the remote processors
for that reason it sends messages to the remote processor requesting
enter to suspend. The remote processor can ack the request or cancel
the request depending of if it is still doing some work. However
when there is a system suspend the remote processor should suspend
even if it is doing some job. Therefore, in the system suspend case
we send a different suspend request to the remote processor saying
that the suspend is forced and it must enter to suspend.
Also, if the remoteproc has a register that can say if the remote
processor is in idle state, it can be specify in the platform data that
way the host can know if it is in idle state without the need to send
a message to the remote processor.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
remoteproc: add autosuspend support

Going to suspend and resuming a remote processor is a heavy task with a
big latency. For that reason, remoteproc should go to suspend only after
some time of inactivity. Remoteproc module is using autosuspend feature
of PM runtime framework to accomplish that. Once it is suspended the
remote processor will be waken up every time the host needs to send it a
message, it is done in the rproc_kick function.

The default timeout can be configured at compilation time and it can be
also configured for individual remote processors at runtime using
PM runtime sysfs entry.

Example:
echo 4000 > /sys/devices/platform/omap/omap-rproc.1/power/autosuspend_delay_ms

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
omap: mailbox: enable mailbox irq per instance

omap2_mbox_startup is only called once in order to initialize
whole mbox module. Enabling mbox irq there is limiting to only
enabling the irq of the very first mailbox instance created.

Instead, the enable_irq function should be called every time a
new mbox instance is created inside omap_mbox_startup at
plat-omap.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
omap4: iommu: fix irq and clock name for dsp-iommu

Irq and clock names were wrong for dsp iommu configuration
for omap4.

Renamed tesla_ick to dsp_fck.
Renamed INT_44XX_DSP_MMU to OMAP44XX_IRQ_TESLA_MMU

Also the macro name for enabling dsp-iommu was changed.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
omap4: remoteproc: support for dsp/Tesla subsystem

Add the omap-rproc device for using OMAP4's dsp "Tesla"
subsystem.

Bind this device to its dedicated iommu, and assing it to
mailbox-2.

Contiguos memory region was allocated for dsp.

Renamed macro for CMA allocation for reflecting the memory
owner.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
omap4: remoteproc: load boot adrress at rproc start

Some processors needs to explicitly storage the boot address
in a special register or memory location. So when the proc
is taken out of reset starts executing code from that specific
entry point.

The memory or register address where the bootaddr is storaged
should be specified in the .ctrl_bootaddr field of the platform
data in the remoteproc. omap_rproc_start function will write
the bootaddr in the corresponding .ctrl_bootaddr register.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
HACK: adding address limit to DRM's cma reservation

Ducati and Tesla firmwares need fixed base adresses (for now).
Because DRM reserves memory before remoteproc init does, we are giving
a limit adress to avoid stealing fixed physical memory of remote
processors.

this limit adress is temporary defined in arch/arm/mach-omap2/remoteproc.c
Update config

Signed-off-by: Xavier Boudet <x-boudet@ti.com>
Version: 3.3.0-1481.11

Signed-off-by: Xavier Boudet <x-boudet@ti.com>
Update Hack for omap_drm.h and omap_drv.h

Add sym link for omap_drm.h and omap_drv.h in include/linux
Force delivery of the 2 files into drivers/staging/omapdrm

Signed-off-by: Xavier Boudet <x-boudet@ti.com>
Version: 3.3.0-1481.12

Signed-off-by: Xavier Boudet <x-boudet@ti.com>