rpmsg:rpmsg.git
5 years agoomap: devices: fix compilation error if CONFIG_IOMMU_API is undefined
Subramaniam Chanderashekarapuram [Thu, 24 May 2012 20:02:24 +0000 (15:02 -0500)]
omap: devices: fix compilation error if CONFIG_IOMMU_API is undefined

Fix the following compilation error:
arch/arm/mach-omap2/devices.c: In function 'omap2_init_devices':
arch/arm/mach-omap2/devices.c:756: error: 'bogus_isp_pdata' undeclared (first use in this function)
arch/arm/mach-omap2/devices.c:756: error: (Each undeclared identifier is reported only once
arch/arm/mach-omap2/devices.c:756: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-omap2/devices.o] Error 1

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap: iommu: fix compilation error if CONFIG_IOMMU_API is undefined
Subramaniam Chanderashekarapuram [Thu, 24 May 2012 18:23:30 +0000 (13:23 -0500)]
omap: iommu: fix compilation error if CONFIG_IOMMU_API is undefined

Fix the following compilation error.

In file included from arch/arm/mach-omap2/omap_hwmod_44xx_data.c:33:
arch/arm/plat-omap/include/plat/iommu.h: In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:146: error: 'struct dev_archdata' has no member named 'iommu'
make[1]: *** [arch/arm/mach-omap2/omap_hwmod_44xx_data.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agoomap: resmgr: fix sparse warning in module init function
Subramaniam Chanderashekarapuram [Fri, 25 May 2012 00:12:21 +0000 (19:12 -0500)]
omap: resmgr: fix sparse warning in module init function

Fixed a sparse warning in the exit function

Error:
drivers/rpmsg/omap_rpmsg_resmgr.c:557:12: warning: symbol 'omap_rprm_init' was not declared. Should it be static?

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agonet: rpmsg: fix sparse warning in exit function
Subramaniam Chanderashekarapuram [Fri, 25 May 2012 00:13:16 +0000 (19:13 -0500)]
net: rpmsg: fix sparse warning in exit function

added static qualifier to the module exit function
to fix sparse warning

net/rpmsg/rpmsg_proto.c:590:13: warning: symbol 'rpmsg_proto_exit' was not declared. Should it be static?

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agoomap: remoteproc: implement suspend and resume callbacks
Fernando Guzman Lugo [Sat, 3 Dec 2011 02:37:22 +0000 (20:37 -0600)]
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>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
5 years agoremoteproc: add autosuspend support
Fernando Guzman Lugo [Fri, 30 Mar 2012 21:23:28 +0000 (16:23 -0500)]
remoteproc: add autosuspend support

In order to save power the rproc should be tunred off when it is not
in use. However going to suspend and resuming is a heavy task with a
big latency for most of the remote processors. For that reason, a
remoteproc should go to suspend only after some time of inactivity,
this auto suspend timeout is specified by the remoteproc itself
(it comes from the resource table in the firmware).

Remoteproc module is using autosuspend feature of PM runtime framework
in order to accomplish that. Remoteproc module will update the last busy
mark every time there is messaging with the remoteproc, so as you can
see it is not accurate but it gives a very good approximation of how long
the remoteproc has been idle. A new parameter in the suspend operation
for the low level drivers is added @auto_suspend flag which tells you if
the suspend comes from a autosuspend if @auto_suspend is true otherwise
it is a system suspend. In the case of auto_suspend, the low lever driver
is responsible of confirming that the remoteproc is actually idle and
then suspend the device. IF the remoteproc  is not idle, the low level
driver has the flexibility of return -EBUSY which tells to the PM
framework that the remoteproc is actually doing something and then the auto
suspend is aborted and there will be another attempt to suspend only
after a time equal to the auto suspend timeout has happened.

Please note that the system suspend needs to be performed even if the
remoteproc is not idle.

Once it is autosuspended the remote processor will be waken up every
time the host needs to send it a message, it is done in the
rproc_virtio_notify function.

The autosuspend timeout comes from the firmware, in case of the firmware
does not provide an autosuspend timeout the remoteproc module will use
a default timeout of 5 seconds. If the timeout in the firmware is
negative that means that remoteproc does not support autosuspend.

In case of autosuspend support, PM runtime framework allows to change
the autosuspend timeout at runtime using a sysfs entry available to each
remote processor.

Example:
echo 4000 > /sys/class/rproc/remoteproc0/power/autosuspend_delay_ms

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoremoteproc: add suspend and resume support
Fernando Guzman Lugo [Fri, 30 Mar 2012 00:01:05 +0000 (19:01 -0500)]
remoteproc: add suspend and resume support

Remoteproc module now is registering resume/suspend callbacks into
the pm framework using the rproc_class. That way when there is a system
suspend the suspend callback will be called and this callback will check
if the low level driver has a suspend operation that would be called in
order to put the rproc in suspend state (and of course it should save
the context). The same applies for the resume case.

If the low level driver does not have suspend/resume operations that means
it does not support system suspend, and the low driver is not affect by
the suspend and resume transitions.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoremoteproc: add a generic rproc device
Ohad Ben-Cohen [Thu, 29 Mar 2012 11:29:05 +0000 (13:29 +0200)]
remoteproc: add a generic rproc device

[this patch is in its early state - do not send upstream]

This has several merits:
- runtime PM can hook to a generic device handled by the core
- all log messages will now carry a generic name regardless of platform
- will make it possible to simplify refcounts

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
5 years agoomap: remoteproc: wait for all mbox threads
Fernando Guzman Lugo [Thu, 17 May 2012 21:17:39 +0000 (16:17 -0500)]
omap: remoteproc: wait for all mbox threads

Wait until all the threads which process mbox messages have finished
in omap_remoteproc_stop function. Doing that we are avoiding that some
virtio callbacks can be executed even when the remoteproc is stopped
and causing a panic if the vrings were already freed.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agorpmsg: omx: confirm remove function is called because of a recovery
Fernando Guzman Lugo [Thu, 17 May 2012 00:03:29 +0000 (19:03 -0500)]
rpmsg: omx: confirm remove function is called because of a recovery

Now, we have access to the remoteproc handle for the rpdev channels
using that handle we can check the state of the remoteproc and confirm
when rpmsg_omx_remove function is called because of a recovery.

Also, this patch is adding missing protection between rpmsg_omx_remove
and rpmsg_omx_release for checking omx->state.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoremoteproc: avoid processing messages after a crash
Fernando Guzman Lugo [Sat, 19 May 2012 08:58:42 +0000 (03:58 -0500)]
remoteproc: avoid processing messages after a crash

Sometimes the kick message from the remoteproc is deliver in a deferred
task by the low level driver. In that scenario it is possible to receive
a message after the remoteproc has crashed. However, there is no point
processing those messages vrings can be already deleted by the recovery
process. So, we drop that kick messages

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoremoteproc: add debugfs to enable or disable recovery at runtime
Fernando Guzman Lugo [Sat, 19 May 2012 08:51:58 +0000 (03:51 -0500)]
remoteproc: add debugfs to enable or disable recovery at runtime

This patch is adding a new debugfs to enable or disable recovery at
runtime. This is useful for debugging remoteproc crashes

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoremoteproc: reset vdev after a fatal error
Fernando Guzman Lugo [Thu, 10 May 2012 05:30:18 +0000 (00:30 -0500)]
remoteproc: reset vdev after a fatal error

One way to recover after a fatal error is resetting the virtio devices.
Doing that, all rpmsg drivers are restored along with the rpmsg devices
and that also causes the reset of the remoteproc making the rpmsg
communication with the remoteproc functional again.

Also, it is creating a rproc error handler function in charge of
handle the fatal errors. At the moment, it is only reseting the
virtio devices, but it is planned to include other functions like
core dump, register dump, stack dump, save last traces of the rproc
before crashing, etc.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoremoteproc: allocate vrings on demand, free when not needed
Ohad Ben-Cohen [Thu, 17 May 2012 11:23:59 +0000 (14:23 +0300)]
remoteproc: allocate vrings on demand, free when not needed

Dynamically allocate the vrings' DMA when the remote processor
is about to be powered on (i.e. when ->find_vqs() is invoked),
and release them as soon as it is powered off (i.e. when ->del_vqs()
is invoked).

The obvious and immediate benefit is better memory utilization, since
memory for the vrings is now only allocated when the relevant remote
processor is used.

Additionally, this approach also makes recovery of a (crashing)
remote processor easier: one just needs to remove the relevant
vdevs, and the entire vrings cleanup takes place automagically.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
5 years agoiommu: pass user-provided token when invoking fault handler
Ohad Ben-Cohen [Thu, 10 May 2012 09:31:10 +0000 (12:31 +0300)]
iommu: pass user-provided token when invoking fault handler

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
5 years agoomap: iommu: deny clkdm idle when iommu fault is not handle until shutdown
Fernando Guzman Lugo [Thu, 17 May 2012 01:31:10 +0000 (20:31 -0500)]
omap: iommu: deny clkdm idle when iommu fault is not handle until shutdown

When and iommu fault happen and it could not be handled (that means a
valid physical address could not be found) we cannot ack the status bit
of the interrupt. Therefore, we need to deny clkdm idle for the clock of
the iommu until the ack can be done. Otherwise, if there is no
clkdm activity (that can happen if the processor associated with the
processor is put under reset) the clkdm will try to go to idle and it will
fail and get stuck in transition state because of the pending interrupt.
In order to avoid that scenario we deny idle in the mmufault ISR and then
in the shutdown of the iommu we ack the interrupt and then allow idle
again.

Also, for omap4 and omap5 the IPU and DSP processors have a shared MMU
which try to use the iommu again once it is acked even if the processor
is already under reset. For that reason the shared MMU must be reset.
The shared MMU only has hardreset and it is shared with the iommu, for
that reason we need to do a hardreset en the iommuu device. In order
to accomplish that we use hwmod functions.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agoomap: remoteproc: match new names in iommu module
Fernando Guzman Lugo [Thu, 17 May 2012 00:59:36 +0000 (19:59 -0500)]
omap: remoteproc: match new names in iommu module

After commit:
b8c9afe OMAP3/4: iommu: migrate to hwmod framework

The iommu device names changed. So we need to match that name
in remoteproc that way the iommu_attach can work.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agoOMAP3/4/5: iommu: adapt to runtime pm
Fernando Guzman Lugo [Mon, 13 Jun 2011 20:48:37 +0000 (23:48 +0300)]
OMAP3/4/5: iommu: adapt to runtime pm

Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.

Removed clk handling during interrupt, given that in order to receive one,
the device should be powered on in advance. Now doing pm_runtime_get/put
on iommu_enable/disable so it doesn't rely on others to keep the clocks on.

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoOMAP3/4/5: iommu: migrate to hwmod framework
Omar Ramirez Luna [Thu, 15 Dec 2011 04:18:28 +0000 (22:18 -0600)]
OMAP3/4/5: iommu: migrate to hwmod framework

Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - Now unused, remove platform device and resource data, handling
   of sysconfig register for softreset purposes, use default
   latency structure.

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoARM: omap5: hwmod data: add mmu hwmod class for ipu and dsp
Subramaniam Chanderashekarapuram [Mon, 21 May 2012 20:18:04 +0000 (15:18 -0500)]
ARM: omap5: hwmod data: add mmu hwmod class for ipu and dsp

Add mmu hwmod class for ipu and dsp. This will enable in converting
the existing omap iommu driver to migrate to hwmod framework.

Also added missing main clk for the ipu hwmod

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Based on work by Omar Ramirez Luna <omar.ramirez@ti.com>

5 years agoARM: omap4: hwmod data: add mmu hwmod class for ipu and dsp
Subramaniam Chanderashekarapuram [Mon, 21 May 2012 19:26:03 +0000 (14:26 -0500)]
ARM: omap4: hwmod data: add mmu hwmod class for ipu and dsp

Add mmu hwmod class for ipu and dsp. This will enable in converting
the existing omap iommu driver to migrate to hwmod framework.
Added missing address space definition for dsp and ipu.

Also added the main clocks for dsp and ipu pseudo hwmods.

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Based on work by Omar Ramirez Luna <omar.ramirez@ti.com>

5 years agoomap: iommu: introduce mmu device attribute for hwmod migration
Omar Ramirez Luna [Mon, 21 May 2012 20:39:42 +0000 (15:39 -0500)]
omap: iommu: introduce mmu device attribute for hwmod migration

Introduce mmu device attribute to capture mmu specific features
as part of hwmod data. This patch enables to enhance mmu hwmod
specific data.

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
[subramaniam.ca@ti.com: reword commit log, logical patch split]

5 years agoremoteproc: fix off-by-one bug in __rproc_free_vrings
Subramaniam Chanderashekarapuram [Sun, 13 May 2012 20:14:36 +0000 (23:14 +0300)]
remoteproc: fix off-by-one bug in __rproc_free_vrings

Fix a nasty off-by-one bug in __rproc_free_vrings which
resulted in a memory leak and (for some platforms) failures
to reload the remote processor.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
[ohad@wizery.com: reword commit log, stick with the for loop]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
5 years agoremoteproc: omap: fix compile time warnings if dsp/ipu not selected
Subramaniam Chanderashekarapuram [Sat, 12 May 2012 02:04:43 +0000 (21:04 -0500)]
remoteproc: omap: fix compile time warnings if dsp/ipu not selected

Depending on whether ipu or dsp is selected, ther are a couple of
warnings. The patch fixes the same.
arch/arm/mach-omap2/remoteproc.c:55: warning: 'dsp_timers' defined but not used
arch/arm/mach-omap2/remoteproc.c:51: warning: 'ipu_timers' defined but not used
arch/arm/mach-omap2/remoteproc.c:71: warning: 'ducati_ops' defined but not used

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agoremoteproc: omap: fix compilation error when remoteproc is not selected
Subramaniam Chanderashekarapuram [Sat, 12 May 2012 02:01:16 +0000 (21:01 -0500)]
remoteproc: omap: fix compilation error when remoteproc is not selected

There is a compilation error when remote proc is not selected in the
kernel menu config. The patch fixes the same.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agorpmsg: omx: re-work buffer lookup to support contiguous NV12
Subramaniam C.A [Thu, 19 Jan 2012 02:24:35 +0000 (20:24 -0600)]
rpmsg: omx: re-work buffer lookup to support contiguous NV12

SGX544 requires Y and UV to be contiguous in SGX
virtual address space. This is done by using single FD
for two ion handles.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agorpmsg: omx: transmit remote processor virtual address
Subramaniam C.A [Sun, 7 Aug 2011 03:56:41 +0000 (22:56 -0500)]
rpmsg: omx: transmit remote processor virtual address

The rpmsg omx driver should convert the physical addresses
into remote processor virtual addresses before transmitting
them. The buffers would be an ion handle for a PVR or a
tiler buffer. Once the we get the pa, the rproc_pa_to_da api
is used to do the translation and then transmit the device
address to the remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Sarthak Aggarwal <sarthak@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agorpmsg: omx: buffer integration and transmission for ion and sgx
Subramaniam C.A [Fri, 6 May 2011 03:23:41 +0000 (22:23 -0500)]
rpmsg: omx: buffer integration and transmission for ion and sgx

The user buffers passed via the write call can be PVR buffer
or an ion buffer. This patch adds support to inspect the
omx packet, get the phys addr using ion and pvr APIs, replace
the buffer addresses in place, before transmitting them
across to the remote processor.

Depending on the type of buffer we support, upto 3 buffers
could be passed across to the remote processor in a single
omx write call.

This also adds register/unregister functionality for
ion handles with an ion client created during driver open.

The patch is essentially based on work done for ics on kernel 3.0.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Aditya Monga <admonga@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
5 years agorpmsg: omx: add safety removal of devices
Fernando Guzman Lugo [Wed, 20 Jul 2011 01:10:52 +0000 (20:10 -0500)]
rpmsg: omx: add safety removal of devices

Add safety when the rpmsg channel device is removed while the
module has users. Also that is useful when recovery is done in
RPMSG, where the channels are destroyed and created again.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agorpmsg: omx: remove additional rpmsg hex dump log
Dan Murphy [Mon, 29 Aug 2011 19:43:19 +0000 (14:43 -0500)]
rpmsg: omx: remove additional rpmsg hex dump log

Removed additional HEX dumping in the rpmsg

Signed-off-by: Dan Murphy <dmurphy@ti.com>
5 years agorpmsg: omx: lower the traces level in driver open, ioctl & release
Suman Anna [Thu, 12 Apr 2012 21:49:42 +0000 (16:49 -0500)]
rpmsg: omx: lower the traces level in driver open, ioctl & release

The dev_info traces in open, connect ioctl and release incur a time
penalty and affect application launch time performances. These have
been converted to dev_dbg traces.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agorpmsg: omx: return actual user-provided bytes written in write
Suman Anna [Thu, 5 Apr 2012 22:45:31 +0000 (17:45 -0500)]
rpmsg: omx: return actual user-provided bytes written in write

The 'write' system call is expected to return the number of bytes
written back to userspace. The rpmsg omx driver adds a small packet
header when sending a message to the remote processor, and is
currently returning this header length as well in the driver's write
fop function. This results in the write call always returning more
bytes than what the user has requested. The header length is now
left out of the bytes returned back.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: add an api to do pa to da conversion
Subramaniam C.A [Wed, 9 May 2012 00:30:14 +0000 (19:30 -0500)]
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.
Since, carveouts and mappings are stored separately,
we need to traverse both lists.

Also stored the physical addresses for RSC_DEVMEM entries
to enable pa to da conversion for dev mem address spaces too.

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>
5 years agoresmgr: omap: correct platform device registration
Subramaniam C.A [Mon, 7 May 2012 19:31:06 +0000 (14:31 -0500)]
resmgr: omap: correct platform device registration

We need to call platform_device_add instead of platform_device_register
when we are using platform_device_alloc call

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agodefconfig: select rpmsg and remote proc component as modules
Subramaniam C.A [Mon, 7 May 2012 08:29:22 +0000 (03:29 -0500)]
defconfig: select rpmsg and remote proc component as modules

The rpmsg and remoteproc components are selected as modules
by default for omap2plus_defconfig. This also select omap-iommu
and mailbox as builtin modules.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoremoteproc: omap: check for undefined mailbox messages
Subramaniam C.A [Mon, 7 May 2012 07:06:45 +0000 (02:06 -0500)]
remoteproc: omap: check for undefined mailbox messages

In case the remoteproc sends a message thats beyond the
last valid message, print it as a info message.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoARM: OMAP: add support for OMAP5 remoteproc cma sizes and start address
Subramaniam C.A [Mon, 7 May 2012 06:36:02 +0000 (01:36 -0500)]
ARM: OMAP: add support for OMAP5 remoteproc cma sizes and start address

OMAP5 has to support a larger ipc shared memory region compared
to OMAP4. This region is reserved by CMA today using memblock
APIs. To account for the increase in size, the starting address
for the CMA resrvation needs to be different for OMAP5.

This patch adds the required support for OMAP5 and upholds
OMAP4 support too.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap: remoteproc: extend remoteproc to suppport omap5
Subramaniam C.A [Mon, 7 May 2012 06:27:15 +0000 (01:27 -0500)]
omap: remoteproc: extend remoteproc to suppport omap5

Added cpu_is_omap54xx() check to extend the remoteproc
support for omap5

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap iommu: extend iommu device to support omap5
Subramaniam C.A [Mon, 7 May 2012 06:23:17 +0000 (01:23 -0500)]
omap iommu: extend iommu device to support omap5

The device structures are the same for OMAP4 and OMAP5. Added
suitable check to extend iommu device support for OMAP5 too.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap: mailbox: handle dev pm qos return values correctly
Subramaniam C.A [Tue, 10 Apr 2012 17:45:05 +0000 (12:45 -0500)]
omap: mailbox: handle dev pm qos return values correctly

The dev_pm_qos update api returns a +ve value (1) in case
the update request resulted in a change in the applied
constraint. The return values from the dev_pm_qos api
were not handled at all currently, the same has been
fixed.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: mailbox: add pm constraint field to mbox structure
Subramaniam C.A [Tue, 10 Apr 2012 17:19:41 +0000 (12:19 -0500)]
omap: mailbox: add pm constraint field to mbox structure

By adding this field, the pm qos apis can be selectively applied
only if the pm constraint is set to a +ve value.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: mailbox: enable mailbox irq per instance
Juan Gutierrez [Fri, 19 Aug 2011 20:38:23 +0000 (15:38 -0500)]
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.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: mailbox: call request_irq after mbox queues are allocated
Fernando Guzman Lugo [Mon, 17 Oct 2011 12:51:44 +0000 (07:51 -0500)]
omap: mailbox: call request_irq after mbox queues are allocated

Calling request_irq first could provoke that ISR function is executed
before the mbox queues are allocated causing a kernel panic when they are
dereference inside the ISR.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoOMAP: mailbox: fix NULL nb in omap_mbox_put
Fernando Guzman Lugo [Thu, 31 Mar 2011 01:43:41 +0000 (20:43 -0500)]
OMAP: mailbox: fix NULL nb in omap_mbox_put

omap_mbox_put must check nb for NULL before trying to unregister it

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
5 years agoOMAP: mailbox: provide enable/disable functions
Omar Ramirez Luna [Wed, 29 Feb 2012 18:57:37 +0000 (12:57 -0600)]
OMAP: mailbox: provide enable/disable functions

...for devices that will no longer use the mailbox (while
they are sleep) but still maintain a registered device.

Rather than providing a specific mach ops to [get|put]_sync,
it might be better to move the whole pm_runtime to the common
framework, but this should be addressed in subsequent patches.

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoOMAP: mailbox: support save/restore context using runtime PM
Omar Ramirez Luna [Wed, 29 Feb 2012 07:32:57 +0000 (01:32 -0600)]
OMAP: mailbox: support save/restore context using runtime PM

Add new runtime_pm functions and use these to save and restore
the context of the mailbox users.

Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoomap: mailbox: Convert to per-device PM-QOS API
Cris Jansson [Tue, 18 Oct 2011 15:42:47 +0000 (10:42 -0500)]
omap: mailbox: Convert to per-device PM-QOS API

Mailbox is updated to use the new per-device latency API of
PM-QOS.  Constraints are now placed on each mailbox device
independently.

Signed-off-by: Cris Jansson <cjansson@ti.com>
5 years agoomap: mailbox: add support for OMAP5
Subramaniam C.A [Thu, 2 Feb 2012 00:36:56 +0000 (01:36 +0100)]
omap: mailbox: add support for OMAP5

Mailbox in OMAP5 functions the same way as in OMAP4.
Added the necessary macros and compiler options to
add support for OMAP5.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Cris Jansson <cjansson@ti.com>
5 years agoomap: mailbox: check iomem resource before dereferencing it
Fernando Guzman Lugo [Thu, 3 Nov 2011 20:16:11 +0000 (15:16 -0500)]
omap: mailbox: check iomem resource before dereferencing it

Add a NULL check for iomem resource in mailbox probe functions

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap: mailbox: wait for reset completion
Suman Anna [Wed, 19 Oct 2011 18:35:07 +0000 (13:35 -0500)]
omap: mailbox: wait for reset completion

mailbox is being reset during every startup, so wait for
the reset completion confirmation before proceeding
with the context restore or interrupt programming.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: mailbox: reset mailbox every startup.
Fernando Guzman Lugo [Tue, 18 Oct 2011 20:09:12 +0000 (15:09 -0500)]
omap: mailbox: reset mailbox every startup.

That way old messages does not affect to the new user.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap: mbox: save, restore and off support
Miguel Vadillo [Mon, 12 Sep 2011 21:32:33 +0000 (16:32 -0500)]
omap: mbox: save, restore and off support

- Fix an issue related with the offsets of the registers
- Each user (Ducati, Tesla ...) should not have its own ctx
memory since the mbox module is one for all of them. A share
ctx is created to store the needed registers when saving.
- save_context function is saving just the irqs per user
currently that is the only thing needed.
- restore_context function is restoring just the irqs per user.
mbox_startup function is setting all the rest of the register
to the original state.
- Add a pm_qos constraint when calling the first get and release
it when the last put is calling, this is to support off mode.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agoARM: omap5: clock: add dsp functional clock data
Subramaniam C.A [Wed, 7 Mar 2012 17:02:18 +0000 (11:02 -0600)]
ARM: omap5: clock: add dsp functional clock data

This patch adds the dsp functional clock data structure
to the omap5 clock data module.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: add clocks to dsp processor device
Suman Anna [Tue, 6 Mar 2012 23:33:08 +0000 (17:33 -0600)]
ARM: omap5: hwmod: 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 dev_pm_qos_update_request 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.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoARM: omap5: hwmod: correct the main clock for dsp hwmods
Subramaniam C.A [Wed, 7 Mar 2012 17:03:52 +0000 (11:03 -0600)]
ARM: omap5: hwmod: correct the main clock for dsp hwmods

The dsp hwmod data is using the wrong main clock. This patch
corrects the same.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoARM: omap5: hwmod: add address space for DSP MMU
Suman Anna [Fri, 17 Feb 2012 07:32:54 +0000 (01:32 -0600)]
ARM: omap5: hwmod: add address space for DSP MMU

This patch adds the hwmod address space for DSP MMU configuration
space for OMAP5.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod_data: split DSP hwmod into two hwmod devices
Miguel Vadillo [Wed, 15 Feb 2012 16:31:33 +0000 (10:31 -0600)]
ARM: omap5: hwmod_data: split DSP hwmod into two hwmod devices

DSP has two reset lines, one for MMU and another for the core
itself. The MMU reset line needs to be deasserted first so that
it can be programmed before deasserting the core reset. There is
a single hwmod device for DSP currently, and this would not allow
the remoteproc code to program and manage the DSP properly. This
device has therefore been split into two different hwmod devices
to allow independent control of the MMU and the processor core.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: add softreset delay field
Cris Jansson [Tue, 27 Sep 2011 22:03:52 +0000 (17:03 -0500)]
ARM: omap5: hwmod: add softreset delay field

This patch accompanies the omap4 softreset delay patch to include omap5.

See "omap: hwmod: add softreset delay field".

Signed-off-by: Cris Jansson <cjansson@ti.com>
5 years agoARM: omap5: hwmod: correct iva hwmod data
Subramaniam C.A [Sun, 6 May 2012 22:30:37 +0000 (17:30 -0500)]
ARM: omap5: hwmod: correct iva hwmod data

Corrected the iva hwmod data to have separate hwmod devices
to deal with multiple processors with associated reset
lines.

The iva sequencers do not need a dedicated sysconfig. Hence,
a separate hwmod class is defined for them.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: correct ipu hwmod data
Subramaniam C.A [Sun, 6 May 2012 22:26:02 +0000 (17:26 -0500)]
ARM: omap5: hwmod: correct ipu hwmod data

Corrected the ipu hwmod data to have the correct
ipu address space, and separate hwmod devices
to deal with multiple processors with associated
reset lines.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agorpmsg_resmgr: add remoteproc as a resource
Miguel Vadillo [Tue, 24 Apr 2012 20:49:06 +0000 (15:49 -0500)]
rpmsg_resmgr: add remoteproc as a resource

Remoteproc can be seen as a resource than can be
requested by any remoteproc.

If the requested remoteproc is not up it will be boot
if already up only the handle will be obtained.

The handle can be use to set constraints on the remoteproc (if any).

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agoomap: remoteproc: specific constraints apis
Miguel Vadillo [Mon, 23 Apr 2012 06:03:00 +0000 (01:03 -0500)]
omap: remoteproc: specific constraints apis

Omap specific implementation of constraints apis.

Currently supporting:

- Latency
- Frequency
- Bandwidth

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agoremoteproc: add constraints framework
Miguel Vadillo [Mon, 23 Apr 2012 03:48:50 +0000 (22:48 -0500)]
remoteproc: add constraints framework

Add constraints api to remoteproc framework.

Currently supporting:

     - Latency
     - Frequency
     - Bandwidth

Each of them should be provided by the specific
architecture if supported.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agoomap: remoteproc: handle the vq msg in a kthread
Miguel Vadillo [Thu, 26 Apr 2012 01:42:32 +0000 (20:42 -0500)]
omap: remoteproc: handle the vq msg in a kthread

Introduce a kthread to handle the vq messages
arriving to the omap_remoteproc cb, this will let
us handle the messages in a parallel way.

This is also helping with a ugly trace about a possible deadlock when
rproc apis are called inside a rpmsg callback. As when the rproc will
be added as a resource in the resource manager that trace will appear
due to the rproc lock and the mbox lock are taken in different order.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap: resmgr: implement constraint functions
Fernando Guzman Lugo [Wed, 29 Feb 2012 20:48:05 +0000 (14:48 -0600)]
omap: resmgr: implement constraint functions

Implement constraint functions for:
-iva
-fdif
-iss

Some constraint functions for omap devices are omap specific or even
machine specific and therefore not all are exported. In order to reach
those functions the omap_rpmsg_resmgr driver would have to be built-in
in the kernel avoiding the possibility of building it as a module and
therefore all its dependencies (RPMSG, RPROC). For that reason  we are
creating small omap resmgr  module in mach-omap2 which creates a
platform device to export the constraint functions as pointers to the
upper driver. That way, omap rpmsg resmgr driver can access the
constraint APIs through the function pointers in the pdata from this
new platform device. Doing this everything can still be built as
modules.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agorpmsg: resmgr: add possibility of requesting constraints for resources
Fernando Guzman Lugo [Mon, 6 Feb 2012 20:52:23 +0000 (14:52 -0600)]
rpmsg: resmgr: add possibility of requesting constraints for resources

Some resources support scale, bandwidth and/or latency constraints.
For that reason now the resmgr framework adds new operation that
can be implement for the resource which has one or more possible
constraints.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap: resmgr: add omap resources which does not have a driver
Fernando Guzman Lugo [Fri, 3 Feb 2012 03:47:34 +0000 (21:47 -0600)]
omap: resmgr: add omap resources which does not have a driver

adding resources:
- IVA (Image and Video Acelerator)
- IVA_SEQ0
- IVA_SEQ1
- FDIF (Face Detection InterFace)
- SL2IF (Shared L2 InterFace)
- ISS (Image Sub System)

As all this devices have a associated device but they don't have a driver.
However, we only need basic turn on/off functionality which be done using
the pm_runtime framework which only requires the device pointer. So,
this patch is also adding a generic function which can request a resource
only using the device and pm_runtime framework and this function is used
for all these resources. This function only allows exclusive access to
resource, that means that these resources can be used for only one user.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoresmgr: add i2c resource to the resource manager
Fernando Guzman Lugo [Thu, 2 Feb 2012 20:54:43 +0000 (14:54 -0600)]
resmgr: add i2c resource to the resource manager

Add the i2c resource so that a remote processor can request a
i2c resource.

This is a temporally patch, we would make use of the i2c driver function
instead of pm runtime function. The i2c driver should provide function
to keep i2c running in order a remoteproc can access it and also provide
protection if it is going to be shared.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agoomap: rpmsg_resmgr: add some omap resources
Fernando Guzman Lugo [Tue, 31 Jan 2012 23:46:07 +0000 (17:46 -0600)]
omap: rpmsg_resmgr: add some omap resources

Adding OMAP resources:
-gptimer
-sdma
-auxclk

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agorpmsg_resmgr: add module to register common resources
Fernando Guzman Lugo [Thu, 26 Jan 2012 20:37:05 +0000 (14:37 -0600)]
rpmsg_resmgr: add module to register common resources

This new module is registering these resources:
-gpio
-regulator

Which have a generic driver that can be used for all architectures.

NOTE: Platform resources can be added using a platform specific module.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agorpmsg: new rpmsg driver to manage resources for remote processors
Fernando Guzman Lugo [Fri, 20 Jan 2012 01:32:07 +0000 (19:32 -0600)]
rpmsg: new rpmsg driver to manage resources for remote processors

This patch creates rpmsg-resmgr which is in charge of receiving
resource requests from remote processors.

Features:
- Use variable length messages to receive and respond requests
from a remote processor. It is using rpmsg for this messaging.

- Keep track of the resources based on connections from a remote
processor.

- When there is a disconnection or the rpmsg resmgr module is removed
all the resources are released (resource cleanup).

- Create a sysfs entry that shows the resources currently allocated and
can be seen using cat <debug fs path>/remoteproc/<rproc>/rpmsg-resmgrX
Example:

cat /debug/remoteproc/omap-rproc.1/resmgr-rpmsg4

Resource Name:gpio
Id:50

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agorpmsg: expose virtproc_info structure
Fernando Guzman Lugo [Tue, 31 Jan 2012 02:26:22 +0000 (20:26 -0600)]
rpmsg: expose virtproc_info structure

That way, rpmsg driver can have access to the rproc handle

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap: build fdif sl2if and iss omap device from hwmod
Fernando Guzman Lugo [Fri, 27 Apr 2012 20:30:56 +0000 (15:30 -0500)]
omap: build fdif sl2if and iss omap device from hwmod

build fdif, sl2if and iss devices for omap4 and omap

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoARM: OMAP4: add creation of iva sequencer devices for OMAP4
Fernando Guzman Lugo [Fri, 3 Feb 2012 03:24:36 +0000 (21:24 -0600)]
ARM: OMAP4: add creation of iva sequencer devices for OMAP4

The IVAHD has 2 sequencers in OMAP4. This patch is adding them so that
they can be turn on too.

NOTE: default latency functions does not work for iva sequencers, they
need to be under reset until the IVAHD load some valid code. So, we
are calling hwmod shutdown when they are deactivated.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoARM: OMAP: omap_device: add omap_device_shutdown_hwmods function
Fernando Guzman Lugo [Fri, 27 Apr 2012 21:32:40 +0000 (16:32 -0500)]
ARM: OMAP: omap_device: add omap_device_shutdown_hwmods function

Adding omap_device_shutdown_hwmods so that, it can be used as a
deactivate function for the devices which share the clocks
and needs to be turned on independently as iva sequencers or
each core of the ipu

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agoomap4: hwmod_data: add missing fields for sl2if
Chandra Sekhar.Anagani [Fri, 17 Feb 2012 05:05:39 +0000 (23:05 -0600)]
omap4: hwmod_data: add missing fields for sl2if

The SL2IF hwmod data for OMAP4 is missing the chip version and
the clock domain name fields. The absence of chip name caused
the hwmod to be ignored altogether during registration, and
the lack of the clock domain caused the hwmod setup to fail,
rendering ipu pretty-much non-functional, and may lead to a
boot failure.

This has been corrected.

Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap4: hwmod_data: add missing fields for fdif
Chandra Sekhar.Anagani [Fri, 17 Feb 2012 04:56:44 +0000 (22:56 -0600)]
omap4: hwmod_data: add missing fields for fdif

The FDIF hwmod data for OMAP4 is missing the chip version and
the clock domain name fields. The absence of chip name caused
the hwmod to be ignored altogether during registration, and
the lack of the clock domain caused the hwmod setup to fail,
rendering fdif use-cases non-functional.

This missing data has been added.

Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: add sl2if hwmod data
Subramaniam C.A [Thu, 2 Feb 2012 02:16:52 +0000 (03:16 +0100)]
ARM: omap5: hwmod: add sl2if hwmod data

Added hwmod data for sl2if.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: OMAP4: hwmod: add sl2if module
Miguel Vadillo [Thu, 29 Dec 2011 13:17:51 +0000 (18:47 +0530)]
ARM: OMAP4: hwmod: add sl2if module

Add sl2if module to hwmod framework.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
5 years agoARM: omap5: hwmod: add fdif hwmod data
Subramaniam C.A [Thu, 2 Feb 2012 02:00:45 +0000 (03:00 +0100)]
ARM: omap5: hwmod: add fdif hwmod data

Added hwmod data for fdif.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: OMAP4: hwmod: add fdif module
Miguel Vadillo [Fri, 17 Jun 2011 15:09:11 +0000 (10:09 -0500)]
ARM: OMAP4: hwmod: add fdif module

Add fdif module to hwmod framework.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
5 years agoARM: omap5: hwmod: correct and enable iss
Subramaniam C.A [Thu, 2 Feb 2012 02:41:39 +0000 (03:41 +0100)]
ARM: omap5: hwmod: correct and enable iss

Corrected the iss hwmod data, and enabled it.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: OMAP4: hwmod: enable iss module
Miguel Vadillo [Fri, 17 Jun 2011 15:09:12 +0000 (10:09 -0500)]
ARM: OMAP4: hwmod: enable iss module

Enabling iss module in hwmod framework.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
5 years agoomap5: clkdata: added clock data for ipu, iva, iss and sl2if
Subramaniam C.A [Wed, 4 Jan 2012 22:04:59 +0000 (16:04 -0600)]
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>
5 years agoARM: omap5: clockdomain: set iss clk domain to SWSUP
Subramaniam C.A [Wed, 4 Jan 2012 21:54:25 +0000 (15:54 -0600)]
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>
5 years agoARM: OMAP: clockdomain: set iss clk domain to just SWSUP
Miguel Vadillo [Tue, 21 Jun 2011 14:59:45 +0000 (09:59 -0500)]
ARM: OMAP: clockdomain: set iss clk domain to just SWSUP

Since CAM domain(ISS) 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 access
it for configure(sysconfig) it or use it.

Also since there is no clock in the domain managed automatically
by the hardware, there is no use 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: Miguel Vadillo <vadillo@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
5 years agorpmsg: omx: use different name for each rproc in device id_table
Juan Gutierrez [Wed, 2 May 2012 19:19:57 +0000 (14:19 -0500)]
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>
5 years agoomap: remoteproc: request a timer(s) for remoteproc usage
Miguel Vadillo [Thu, 12 Apr 2012 00:24:31 +0000 (19:24 -0500)]
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>
5 years agorpmsg: only send disconnect if omx state is connected
Miguel Vadillo [Wed, 11 Apr 2012 00:07:11 +0000 (19:07 -0500)]
rpmsg: only send disconnect if omx state is connected

otherwise just destroy the end point.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agoomap: add ipu and dsp as configurable remoteproc instances
Juan Gutierrez [Wed, 11 Apr 2012 21:55:41 +0000 (16:55 -0500)]
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>
5 years agoomap4: remoteproc: support for dsp/Tesla subsystem
Juan Gutierrez [Wed, 8 Feb 2012 21:24:16 +0000 (15:24 -0600)]
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>
5 years agoomap: remoteproc: add support for a boot register
Juan Gutierrez [Mon, 5 Mar 2012 18:57:55 +0000 (12:57 -0600)]
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>
5 years agoOMAP4: iommu: fix irq and clock name for dsp-iommu
Juan Gutierrez [Wed, 8 Feb 2012 21:18:54 +0000 (15:18 -0600)]
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>
5 years agoremoteproc: add support for smp
Fernando Guzman Lugo [Mon, 23 Apr 2012 23:33:35 +0000 (18:33 -0500)]
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>
5 years agorpmsg: add 'send' module param to client sample
Ohad Ben-Cohen [Sun, 12 Feb 2012 09:52:37 +0000 (11:52 +0200)]
rpmsg: add 'send' module param to client sample

Add a 'send' module param to the rpmsg client sample, with which users
could control the number of messages the sample will send across to the
remote service.

This is convenient when demonstrating/experimenting with the remote
processor.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
5 years agoARM: OMAP4: adapt rproc CMA base addr to 3.3 RAM truncation
Ohad Ben-Cohen [Sun, 29 Jan 2012 12:04:43 +0000 (14:04 +0200)]
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>
5 years agoARM: OMAP: add remoteproc devices for OMAP4
Ohad Ben-Cohen [Thu, 20 Oct 2011 18:25:53 +0000 (20:25 +0200)]
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>
5 years agonet: add rpmsg sockets and a userland demo app
Ohad Ben-Cohen [Sun, 6 Nov 2011 16:03:01 +0000 (18:03 +0200)]
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>
5 years agoARM: OMAP3: support a phony omap3isp device
Ohad Ben-Cohen [Thu, 20 Oct 2011 19:59:03 +0000 (21:59 +0200)]
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>
5 years agotools: /dev/rpmsg-omx demo app
Ohad Ben-Cohen [Thu, 20 Oct 2011 19:56:06 +0000 (21:56 +0200)]
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>