virtio: add rpmsg appendix to the virtio-spec

Add an RPMSG appendix to the virtio-spec.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
rpmsg: add server sample driver

*** I'm carrying this around so it won't get lost, but this sample
*** doesn't work for now as I've dropped the static channels support
*** (that's why it's not in the samples folder, too).

There's some resource table groundwork to do for the static channels
to return, so this sample will be revised later when that happens.

Designed with Brian Swetland <swetland@google.com>.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
rpmsg: add OMX driver

*** I'm carrying it here so it doesn't get lost, but this driver still
*** needs some work

Add an rpmsg OMX driver, which enables user space to offload
cpu-intensive multimedia tasks to OMX instances running on remote
processors.

The current driver is a raw skeleton: it supports connecting to (and by
that, creating) remote OMX instances, and sending and receiving raw
messages from them, but there's no OMX API knowledge yet, no buffer
management, and no per-connection resource tracking and cleaning up.

The goal of this driver is to demonstrate rpmsg usage and the life
cycle (and usage) of local/remote rpmsg addresses while allowing
creation of, and connection to multiple remote OMX instances, while
only enabling a strict point-to-point communications between user space
and those OMX components.

Designed with Brian Swetland <swetland@google.com>.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
tools: /dev/rpmsg-omx demo app

*** I'm carrying it here so it doesn't get lost, but this sample
*** probably needs to be refreshed (and moved to samples/...)

This is a user space application that demonstrates usage
of the /dev/rpmsg-omx device.

The app creates a remote OMX instance, and once connection
is established, it starts ping-ponging raw messages with that new OMX
instance (note: currently a generic "OMX" name is used while connecting.
this can be changed to a specific OMX instance name, such as
"h264_decode", when we implement the entire GetHandle function within
the context of the connect ioctl).

We don't really invoke meaningful OMX remote API yet, but this
should be enough infrastructure to start doing real OMX work on both sides
(A9 and Ducati).

Btw I'm using eventfd(2), which I'm not sure bionic supports. Anyway it
can be trivially replaced by pipe(2).

Designed with Brian Swetland <swetland@google.com>.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
ARM: OMAP3: support a phony omap3isp device

This is non-upstream stuff.

Only required to test omap3isp IOMMU functionality.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
net: add rpmsg sockets and a userland demo app

Warning: this is still completely preliminary and buggy.

It's only here to assist folks who needs this for development.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
ARM: OMAP: add remoteproc devices for OMAP4

Add an omap-rproc device with which one can start using OMAP4's
dual-M3 "Ducati" ipu subsystem.

Currently we're adding support only for the first M3 core (hence
the name "ipu_c0"); support for the second M3 core, as well as for
the DSP subsystem, will be added later on.

Bind this device to its dedicated IOMMU device, and assign it a
dedicated mailbox instance too.

In addition, reserve it a physically contiguous memory region using
the upcoming CMA mechanism (this makes this patch impossible to merge
at this point).

Note: at this point we're using a fixed CMA base address (as defined by
OMAP_RPROC_CMA_BASE), but this will go away once the generic iommu-based
DMA API will materialize, because at that point we will (almost) not care about
the physical location of the CMA memory.

Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com>.

Designed with Brian Swetland <swetland@google.com>.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
ARM: OMAP4: adapt rproc CMA base addr to 3.3 RAM truncation

On 3.3 the System RAM is truncated earlier than it was before,
due to an increase in the vmalloc region to 240MB (from 120MB);
see commit 0536bdf33faff4d940ac094c77998cfac368cfff "ARM: move
iotable mappings within the vmalloc region".

Adapt the rproc CMA region to accomodate that (otherwise some of the pages
will elicit invalid pfn warnings when the cma regions are activated).

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
HACK! {virtio/hvc}_console: wicked temporary workarounds to make things work

1. kzalloc -> dma_alloc_coherent: because we want memory to be iommu
   mapped. and we're limiting allocations, because no iommu-based dma
   api yet limits our rtos address space
2. remove TTY_DRIVER_RESET_TERMIOS, so it won't reset after stty

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
softirq: wicked temporary workaround to eliminate warning
remoteproc: add support for smp

This temporary easy patch for support smp
The complete patch should have a config for enable
disable smp feature.

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.

dsp-iommu is enabled by default.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
omap: remoteproc: add support for a boot register

Some remote processors (like Omap4's 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.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@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 assign it to
mailbox-2.

Contiguos memory region was allocated for dsp

Macros for CMA allocation were renamed to reflect the memory
owner.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
omap: add ipu and dsp as configurable remoteproc instances

OMAP4 supports two remoteproc instances - ipu & dsp. The
CONFIG_OMAPREMOTE_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_OMAPREMOTE_PROC will continue to be the generic
option for enabling remoteproc driver support for OMAP.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: only send disconnect if omx state is connected

otherwise just destroy the end point.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
omap: remoteproc: request a timer(s) for remoteproc usage

The usage of an external timer for some purposes
is a good way to low the power consumption of the
remote processor and allow it to go to a lower state.

Some processors use their internal timers as ticks,
this looks like the right thing to do but this behaviour
might not allow it to go to a lower state since the
internal timer is running.

Provide a way to request a timer(s) to be used by
the remoteproc whenever it is enabled and disable them
when the remoteproc is disabled.

Also for the case of ipu_c0 request gptimer 3 to be used
as tick and set the source ipu_c0 is expecting. For dsp
gptimr 5 is requested.

Note: if the gptimer is already in use by the time ipu_c0/
dsp is loaded it will not load.

This same mechanism to request a timer(s) can be used for
ipu_c1, watchdog or any other purpose.

Signed-off-by: Miguel Vadillo <vadillo@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

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: omap5: clockdomain: set iss clk domain to SWSUP

This patch sets the cam/iss clock domain from HW_AUTO to just
SW_SUP. This patch is based on a similar patch done for OMAP4,

"ARM: OMAP: clockdomain: set iss clk domain to just SWSUP"

This is done because CAM domain has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain needs
to be in force wakeup in order to be able to be used or accessed
for configuration.

Also since there is no clock in the domain managed automatically
by the hardware, so there is no need to configure automatic
clock domain transition. SW should keep the SW_WKUP domain
transition as long as a module in the domain is required to
be functional.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap5: clkdata: added clock data for ipu, iva, iss and sl2if

This patch adds clock data for ipu, iva, iss and sl2if
Also corrected fdif clock data.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>