remoteproc: get suspend address from resource table

The suspend address is used as a flag to check if the remoteproc
has actually suspended. The address could vary according to the
memory map in the remoteproc. Changing the memory map in the
remote processor changes the value of the suspend address.
Passing the address in the resource table information avoids
hardcoding the value in the platform data of the remoteproc.
The value is instead assigned while parsing the resource table.

Change-Id: I698b81d61d391af85bc1556d2abc4c407c1db018
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg-omx: Use ion abstraction to get handle from PVR fd

PVRExportFDToIONHandles was being called directly by rpmsg-omx.
This is now abstracted by ion and drivers should use
omap_ion_fd_to_handles instead.

Change-Id: I2f750887a048eb3d9cd28cdc9c4b08eb3e83e31b
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
rpmsg: omx: use different name for each rproc in device id_table

The rpmsg omx driver currently uses the same name to match a
device during its probe. The cdevs exposed by the driver are
simply created sequentially in the prone based on the discovery
of each device. The devices can be created in a random order
when multiple remote processors are involved, and is merely a
factor of when the remote processor has come up and published
its OMX service.

Userspace is assuming that the second cdev registered is always
for ipu_c1 (/dev/rpmsg-omx1). This is valid only as long as
ipu is the only remote processor being used. ipu_c1 always gets
created second today due to the boot-up sequence of the ipu
cores and the images they are executing, but this may not be
valid always. When dsp is being used, the rpmsg channel devices
for dsp and ipu can be created in any order. This would break
any existing userspace libraries/applications that may be
communicating with different remote processors.

The device id table is updated now to match specific names to
specific processors, so that they always remain the same
irrespective of the boot sequence.
 "rpmsg-omx0"    ipu_c0
 "rpmsg-omx1"    ipu_c1
 "rpmsg-omx2"    dsp

Change-Id: Ia75f944c87b6dffa982ee208dcaadb48f79da42a
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: implement separate register ioctl for sgx buffers

This implements a new register ioctl specifically meant for sgx
buffers. rpmsg_omx clients are expected to call register ioctl
for the specific buffer type (ion or sgx) before sending a buffer
to .write for mapping. The registration allows the rpmsg_omx
driver to hold a reference to the ion buffers making up the sgx
buffer, thereby preventing the buffer(s) to be freed up from
under the remote processor.

The individual imported ion handles are expected to be passed
into the .write call.

When a client no longer expects remote processor to use the buffer,
client should call unregister ioctl. A separate unregister ioctl
for pvr buffers is not created, and the same ion unregister ioctl
is expected to be used for all the ion handles a sgx buffer is
comprised of.

Change-Id: Ib36aab90136627899e98717aeb29bfa637ec09fd
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: add ion system heap to omx ion client

Allow the rpmsg omx ion client to access buffers from
the ion system heap.

Change-Id: Ic2d6922cb5cb05ec96f807a36b77c124769f4ef2
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: David Schleef <ds@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: add handling of ion system heap buffers

Generate page lists for ION system heap buffers.  This is used to
share system heap buffers with the remote processor. The address
of the page list is sent as a physical address to the list (as
opposed to the virtual address of the buffer), so the remote must
be informed using external mechanisms to expect a page list.

Also, adds a rpmsg_buffer structure to help with the book keeping
that is necessary while page list handling is in rpmsg omx.

This is expected to be moved out to a more generic place to
provide access to other potential rpmsg client drivers.

Change-Id: I5fb96a44a2054d396561a5ab559dc0ac486537df
Signed-off-by: David Schleef <ds@ti.com>
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: return correct handle count in 'OMX_IOCPVRREGISTER'

omap_ion_share_fd_to_buffers is always returning 2 in num_handles
even for fd's pointing to 1D memory. In order to return the correct
number of handles to rpmsg client in this ioctl call, 'break' out
of for loop instead of continuing.

Change-Id: Ic7fecc682895a63ad7b7f74b8824f0dc0eb57481
Signed-off-by: Emilian Peev <epeev@mm-sol.com>
Signed-off-by: Tyler Luu <tluu@ti.com>
rpmsg: resmgr: use absolute inputs for auxclk rates

Aux clock rates are currently passed as an integer MHz value.
The rpmsg resource manager multiplies it by the MHz value to
get the absolute clock rate. This does not allow other clock
rates like 19.2MHz for aux clock. This is resolved by removing
the integer MHz restrictions on inputs. Ducati-side is expected
to pass absolute clock rates.

Change-Id: I051fb59914d2c5fd3ef03c4bbc8c7ff09bb47a06
Signed-off-by: Suman Anna <s-anna@ti.com>