Commit Graph

37 Commits

Author SHA1 Message Date
Peng Fan 40df0a91b2 remoteproc: add is_iomem to da_to_va
Introduce an extra parameter is_iomem to da_to_va, then the caller
could take the memory as normal memory or io mapped memory.

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1615029865-23312-5-git-send-email-peng.fan@oss.nxp.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-03-11 12:02:41 -06:00
Gustavo A. R. Silva df561f6688 treewide: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
Nathan Chancellor e6d05acd57 remoteproc/omap: Fix set_load call in omap_rproc_request_timer
When building arm allyesconfig:

drivers/remoteproc/omap_remoteproc.c:174:44: error: too many arguments
to function call, expected 2, have 3
        timer->timer_ops->set_load(timer->odt, 0, 0);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~                ^
1 error generated.

This is due to commit 02e6d546e3 ("clocksource/drivers/timer-ti-dm:
Enable autoreload in set_pwm") in the clockevents tree interacting with
commit e28edc5719 ("remoteproc/omap: Request a timer(s) for remoteproc
usage") from the rpmsg tree.

This should have been fixed during the merge of the remoteproc tree
since it happened after the clockevents tree merge; however, it does not
look like my email was noticed by either maintainer and I did not pay
attention when the pull was sent since I was on CC.

Fixes: c657011431 ("Merge tag 'rproc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc")
Link: https://lore.kernel.org/lkml/20200327185055.GA22438@ubuntu-m2-xlarge-x86/
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-03 10:47:21 -07:00
Suman Anna 69591e4a0e remoteproc/omap: Add watchdog functionality for remote processors
Remote processors can be stuck in a loop, and may not be recoverable
if they do not have a built-in watchdog. The watchdog implementation
for OMAP remote processors uses external gptimers that can be used
to interrupt both the Linux host as well as the remote processor.

Each remote processor is responsible for refreshing the timer during
normal behavior - during OS task scheduling or entering the idle loop
properly. During a watchdog condition (executing a tight loop causing
no scheduling), the host processor gets interrupts and schedules a
recovery for the corresponding remote processor. The remote processor
may also get interrupted to be able to print a back trace.

A menuconfig option has also been added to enable/disable the Watchdog
functionality, with the default as disabled.

Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20200324110035.29907-15-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:51 -07:00
Suman Anna 232ba6ca00 remoteproc/omap: Report device exceptions and trigger recovery
The OMAP remote processors send a special mailbox message
(RP_MBOX_CRASH) when they crash and detect an internal device
exception.

Add support to the mailbox handling function upon detection of
this special message to report this crash to the remoteproc core.
The remoteproc core can trigger a recovery using the prevailing
recovery mechanism, already in use for MMU Fault recovery.

Co-developed-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-14-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:50 -07:00
Suman Anna 5f31b232c6 remoteproc/omap: Add support for runtime auto-suspend/resume
This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'ti,autosuspend-delay-ms' under DT or
by updating the 'autosuspend_delay_ms' field at runtime through the
sysfs interface. A negative value is equivalent to disabling the runtime
suspend.
    Eg: To use 25 seconds for IPU2 on DRA7xx,
      echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
    Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
      echo on > /sys/bus/platform/devices/55020000.ipu/power/control

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:50 -07:00
Suman Anna 9077ac1ab1 remoteproc/omap: Add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:50 -07:00
Suman Anna e28edc5719 remoteproc/omap: Request a timer(s) for remoteproc usage
The remote processors in OMAP4+ SoCs are equipped with internal
timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or
the CTM timer within Unicache in IPU & DSP. However, these timers
are gated when the processor subsystem clock is gated, making
them rather difficult to use as OS tick sources. They will not
be able to wakeup the processor from any processor-sleep induced
clock-gating states.

This can be avoided by using an external timer as the tick source,
which can be controlled independently by the OMAP remoteproc
driver code, but still allowing the processor subsystem clock to
be auto-gated when the remoteproc cores are idle.

This patch adds the support for OMAP remote processors to request
timer(s) to be used by the remoteproc. The timers are enabled and
disabled in line with the enabling/disabling of the remoteproc.
The timer data is not mandatory if the advanced device management
features are not required.

The core timer functionality is provided by the OMAP DMTimer
clocksource driver, which does not export any API. The logic is
implemented through the timer device's platform data ops. The OMAP
remoteproc driver mainly requires ops to request/free a dmtimer,
and to start/stop a timer. The split ops helps in controlling the
timer state without having to request and release a timer everytime
it needs to use the timer.

NOTE: If the gptimer is already in use by the time IPU and/or
DSP are loaded, the processors will fail to boot.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-11-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:49 -07:00
Suman Anna 8135d1d281 remoteproc/omap: Check for undefined mailbox messages
Add some checks in the mailbox callback function to limit
any processing in the mailbox callback function to only
certain currently valid messages, and drop all the remaining
messages. A debug message is added to print any such invalid
messages when the appropriate trace control is enabled.

Co-developed-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-10-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:49 -07:00
Suman Anna 0aaf191302 remoteproc/omap: Add support for DRA7xx remote processors
DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems
for offloading different computation algorithms. The IPU processor
subsystem contains dual-core ARM Cortex-M4 processors, and is very
similar to those on OMAP5. The DSP processor subsystem is based on
the TI's standard TMS320C66x DSP CorePac core.

Support has been added to the OMAP remoteproc driver through new
DRA7xx specific compatibles for properly probing and booting all
the different processor subsystem instances on DRA7xx/AM57xx
SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX
is added to enable the driver to be built in DRA7xx-only configuration.

The DSP boot address programming needed enhancement for DRA7xx as the
boot register fields are different on DRA7 compared to OMAP4 and OMAP5
SoCs. The register on DRA7xx contains additional fields within the
register and the boot address bit-field is right-shifted by 10 bits.
The internal memory parsing logic has also been updated to compute
the device addresses for the L2 RAM for DSP devices using relative
addressing logic, and to parse two additional RAMs at L1 level - L1P
and L1D. This allows the remoteproc driver to support loading into
these regions for a small subset of firmware images requiring as
such. The most common usage would be to use the L1 programmable
RAMs as L1 Caches.

The firmware lookup logic also has to be adjusted for DRA7xx as
there are (can be) more than one instance of both the IPU and DSP
remote processors for the first time in OMAP4+ SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: moved address translation quirks to pdata]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-8-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:48 -07:00
Suman Anna f4af5bd233 remoteproc/omap: Initialize and assign reserved memory node
The reserved memory nodes are not assigned to platform devices by
default in the driver core to avoid the lookup for every platform
device and incur a penalty as the real users are expected to be
only a few devices.

OMAP remoteproc devices fall into the above category and the OMAP
remoteproc driver _requires_ specific CMA pools to be assigned
for each device at the moment to align on the location of the
vrings and vring buffers in the RTOS-side firmware images. So,
use the of_reserved_mem_device_init/release() API appropriately
to assign the corresponding reserved memory region to the OMAP
remoteproc device. Note that only one region per device is
allowed by the framework.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-7-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:48 -07:00
Suman Anna 530a1b57e8 remoteproc/omap: Add the rproc ops .da_to_va() implementation
An implementation for the rproc ops .da_to_va() has been added
that provides the address translation between device addresses
to kernel virtual addresses for internal RAMs present on that
particular remote processor device. The implementation provides
the translations based on the addresses parsed and stored during
the probe.

This ops gets invoked by the exported rproc_da_to_va() function
and allows the remoteproc core's ELF loader to be able to load
program data directly into the internal memories.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-6-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:47 -07:00
Suman Anna 4a032199d3 remoteproc/omap: Add support to parse internal memories from DT
The OMAP remoteproc driver has been enhanced to parse and store
the kernel mappings for different internal RAM memories that may
be present within each remote processor IP subsystem. Different
devices have varying memories present on current SoCs. The current
support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
L2 RAM memories.

IPUs are expected to have the L2RAM at a fixed device address of
0x20000000, based on the current limitations on Attribute MMU
configurations.

NOTE:
The current logic doesn't handle the parsing of memories for DRA7
remoteproc devices, and will be added alongside the DRA7 support.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo: converted to parse mem names / device addresses from pdata]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-5-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:47 -07:00
Suman Anna feae030053 remoteproc/omap: Add a sanity check for DSP boot address alignment
The DSP remote processors on OMAP SoCs require a boot register to
be programmed with a boot address, and this boot address needs to
be on a 1KB boundary. The current code is simply masking the boot
address appropriately without performing any sanity checks before
releasing the resets. An unaligned boot address results in an
undefined execution behavior and can result in various bus errors
like MMU Faults or L3 NoC errors. Such errors are hard to debug and
can be easily avoided by adding a sanity check for the alignment
before booting a DSP remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-4-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:47 -07:00
Suman Anna 7524292701 remoteproc/omap: Add device tree support
OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
driver is enhanced to support remoteproc devices created through
Device Tree, support for legacy platform devices has been
deprecated. The current DT support handles the IPU and DSP
processor subsystems on OMAP4 and OMAP5 SoCs.

The OMAP remoteproc driver relies on the ti-sysc, reset, and
syscon layers for performing clock, reset and boot vector
management (DSP remoteprocs only) of the devices, but some of
these are limited only to the machine-specific layers
in arch/arm. The dependency against control module API for boot
vector management of the DSP remoteprocs has now been removed
with added logic to parse the boot register from the DT node
and program it appropriately directly within the driver.

The OMAP remoteproc driver expects the firmware names to be
provided via device tree entries (firmware-name.) These are used
to load the proper firmware during boot of the remote processor.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc framework]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324110035.29907-3-t-kristo@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25 22:29:46 -07:00
Thomas Gleixner 1802d0beec treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 655 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-30 11:26:41 -07:00
Bhumika Goyal c008fad264 drivers: remoteproc: constify rproc_ops structures
Declare rproc_ops structures as const as they are only passed as an
argument to the function rproc_alloc. This argument is of type const, so
rproc_ops structures having this property can be declared const too.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct rproc_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
@@
rproc_alloc(...,&i@p,...)

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct rproc_ops i;

File size details:

Size of the file remoteproc/da8xx_remoteproc.o remains the same before and
after applying the changes.

   text	   data	    bss	    dec	    hex	filename
   1312	    100	      4	   1416	    588 remoteproc/da8xx_remoteproc.o
   1312	    100	      4	   1416	    588 remoteproc/da8xx_remoteproc.o

    970	    240	      0	   1210	    4ba remoteproc/omap_remoteproc.o
   1002	    192	      0	   1194	    4aa remoteproc/omap_remoteproc.o

   1901	    240	      0	   2141	    85d remoteproc/st_remoteproc.o
   1933	    192	      0	   2125	    84d remoteproc/st_remoteproc.o

   1288	     96	      0	   1384	    568 remoteproc/st_slim_rproc.o
   1320	     64	      0	   1384	    568 remoteproc/st_slim_rproc.o

   2121	    240	      0	   2361	    939 remoteproc/wkup_m3_rproc.o
   2161	    192	      0	   2353	    931 remoteproc/wkup_m3_rproc.o

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-01-18 10:46:50 -08:00
Bjorn Andersson 433c0e04bc remoteproc: Split driver and consumer dereferencing
In order to be able to lock a rproc driver implementations only when
used by a client, we must differ between the dereference operation of a
client and the implementation itself.

This patch brings no functional change.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-10-02 22:50:21 -07:00
Anna, Suman 14096c13ef remoteproc/omap: revise a minor error trace message
The omap_mbox_msg_send() is the legacy API for sending a mailbox
message. It has been replaced with the mbox_send_message() from
the mailbox framework. Revise the failure trace to print a generic
failure message instead of referencing the actual function name.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-12 21:27:50 -07:00
Anna, Suman 334765f45b remoteproc/omap: fix various code formatting issues
This patch fixes some of the existing checkpatch warnings in OMAP
remoteproc code. The fixes are to the following warnings:
1. WARNING: missing space after return type
2. WARNING: Unnecessary space after function pointer name
3. CHECK: Alignment should match open parenthesis

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-12 21:27:50 -07:00
Suman Anna 315491e5d6 remoteproc: add IOMMU hardware capability flag
The remoteproc framework currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.

This issue is seen on OMAP platforms when trying to add a remoteproc
driver for a small Cortex M3 called the WkupM3 used for suspend /
resume management on TI AM335/AM437x SoCs. This processor does not
have an MMU. Same is the case with another processor subsystem
PRU-ICSS on AM335/AM437x. All these are platform devices, and the
current iommu_present check will not scale for the same kernel image
to support OMAP4/OMAP5 and AM335/AM437x.

The existing platform implementation drivers - OMAP remoteproc, STE
Modem remoteproc and DA8xx remoteproc, are updated as well to properly
configure the newly added rproc field.

Cc: Robert Tivy <rtivy@ti.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
[small change in the commit title and in a single comment]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2015-03-12 10:43:26 +02:00
Linus Torvalds e6b5be2be4 Driver core patches for 3.19-rc1
Here's the set of driver core patches for 3.19-rc1.
 
 They are dominated by the removal of the .owner field in platform
 drivers.  They touch a lot of files, but they are "simple" changes, just
 removing a line in a structure.
 
 Other than that, a few minor driver core and debugfs changes.  There are
 some ath9k patches coming in through this tree that have been acked by
 the wireless maintainers as they relied on the debugfs changes.
 
 Everything has been in linux-next for a while.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iEYEABECAAYFAlSOD20ACgkQMUfUDdst+ylLPACg2QrW1oHhdTMT9WI8jihlHVRM
 53kAoLeteByQ3iVwWurwwseRPiWa8+MI
 =OVRS
 -----END PGP SIGNATURE-----

Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core update from Greg KH:
 "Here's the set of driver core patches for 3.19-rc1.

  They are dominated by the removal of the .owner field in platform
  drivers.  They touch a lot of files, but they are "simple" changes,
  just removing a line in a structure.

  Other than that, a few minor driver core and debugfs changes.  There
  are some ath9k patches coming in through this tree that have been
  acked by the wireless maintainers as they relied on the debugfs
  changes.

  Everything has been in linux-next for a while"

* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
  Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
  fs: debugfs: add forward declaration for struct device type
  firmware class: Deletion of an unnecessary check before the function call "vunmap"
  firmware loader: fix hung task warning dump
  devcoredump: provide a one-way disable function
  device: Add dev_<level>_once variants
  ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
  ath: use seq_file api for ath9k debugfs files
  debugfs: add helper function to create device related seq_file
  drivers/base: cacheinfo: remove noisy error boot message
  Revert "core: platform: add warning if driver has no owner"
  drivers: base: support cpu cache information interface to userspace via sysfs
  drivers: base: add cpu_device_create to support per-cpu devices
  topology: replace custom attribute macros with standard DEVICE_ATTR*
  cpumask: factor out show_cpumap into separate helper function
  driver core: Fix unbalanced device reference in drivers_probe
  driver core: fix race with userland in device_add()
  sysfs/kernfs: make read requests on pre-alloc files use the buffer.
  sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
  fs: sysfs: return EGBIG on write if offset is larger than file size
  ...
2014-12-14 16:10:09 -08:00
Suman Anna 8841a66aaa mailbox/omap: adapt to the new mailbox framework
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.

The main changes for the adaptation are:
  - The tasklet used for Tx is replaced with the state machine from
    the generic mailbox framework. The workqueue used for processing
    the received messages stays intact for minimizing the effects on
    the OMAP mailbox clients.
  - The existing exported client API, omap_mbox_get, omap_mbox_put and
    omap_mbox_send_msg are deleted, as the framework provides equivalent
    functionality. A OMAP-specific omap_mbox_request_channel is added
    though to support non-DT way of requesting mailboxes.
  - The OMAP mailbox driver is integrated with the mailbox framework
    through the proper implementations of mbox_chan_ops, except for
    .last_tx_done and .peek_data. The OMAP mailbox driver does not need
    these ops, as it is completely interrupt driven.
  - The OMAP mailbox driver uses a custom of_xlate controller ops that
    allows phandles for the pargs specifier instead of indexing to avoid
    any channel registration order dependencies.
  - The new framework does not support multiple clients operating on a
    single channel, so the reference counting logic is simplified.
  - The remoteproc driver (current client) is adapted to use the new API.
    The notifier callbacks used within this client is replaced with the
    regular callbacks from the newer framework.
  - The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
    omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
    with the signature modified to take in the new mbox_chan handle instead
    of the OMAP specific omap_mbox handle. The first 2 will be removed when
    the OMAP mailbox driver is adapted to runtime_pm. The other exported
    API omap_mbox_request_channel will be removed once existing legacy
    users are converted to DT.

Signed-off-by: Suman Anna <s-anna@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2014-11-27 12:51:04 +05:30
Wolfram Sang 51aa31b49f remoteproc: drop owner assignment from platform_drivers
A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-10-20 16:21:29 +02:00
Suman Anna c869c75c16 mailbox/omap: move the OMAP mailbox framework to drivers
The mailbox hardware (in OMAP) uses a queued mailbox interrupt
mechanism that provides a communication channel between processors
through a set of registers and their associated interrupt signals
by sending and receiving messages.

The OMAP mailbox framework/driver code is moved to be under
drivers/mailbox, in preparation for adapting to a common mailbox
driver framework. This allows the build for OMAP mailbox to be
enabled (it was disabled during the multi-platform support).

As part of the migration from plat and mach code:
- Kconfig symbols have been renamed to build OMAP1 or OMAP2+ drivers.
- mailbox.h under plat-omap/plat/include has been split into a public
  and private header files. The public header has only the API related
  functions and types.
- The module name mailbox.ko from plat-omap is changed to
  omap-mailbox.ko
- The module name mailbox_mach.ko from mach-omapX is changed as
    mailbox_omap1.ko for OMAP1
    mailbox_omap2.ko for OMAP2+

Cc: Tony Lindgren <tony@atomide.com>
[gregkh@linuxfoundation.org: ack for staging part]
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Omar Ramirez Luna <omar.ramirez@copitl.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2013-06-11 11:41:51 -05:00
Greg Kroah-Hartman 0fe763c570 Drivers: misc: remove __dev* attributes.
CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-03 15:57:16 -08:00
Linus Torvalds 4d6d367232 - Remoteproc Recovery - by Fernando Guzman Lugo - when a remote processor
crash is detected, this mechanism will remove all virtio children
   devices, wait until their drivers let go, hard reset the remote
   processor and reload the firmware (resulting in the relevant virtio
   children devices re-added). Essentially the entire software stack
   is reset, together with the relevant hardware, so users don't have
   to reset the entire phone.
 - STE Modem driver is added - by Sjur Brændeland
 - OMAP DSP boot address support is added - by Juan Gutierrez
 - A handful of fixes/cleanups - Sjur Brændeland, Dan Carpenter, Emil Goode
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJQbU3JAAoJELLolMlTRIoMJn4QANjLHhYw/BdfMF9E2DRQe0ew
 HFD/siXpQKXMwJ+xDCP9RfGm88tHdn8l/q6NFCOL/hr6TywnY3RrYfijL7O8qQOQ
 coIMaigOwWr9b55YBGD17ahNDsPGFdfAblWVyJBPfFf/kgVYb2NBNgTCMbGisqrK
 g83t85ULZeGXeWHZxCOxGEQ1cai4HXpsPOGRxDQFeZKU7qM2fVbY+3zeQIymdZ7v
 dByifhkwexjqD3n4n2TYRKQo1nC6dSBIaoF5rhRfdKk7L4rmf5J5oII66iRYIuDD
 vCPblfnrLjd6nwOp/fKqEQlno8uDV8Ryjx90YyWp+IpLJO9RbQko3TDwojgjN6e/
 Edg+08nmck1mfE3qKNROCmwK3Dr3j/MOkqwKfS3l7U6VMsBebwdk5me4RBTexSiH
 QZzFK3Q2q5K9U+GPOgb3uBI8dHfW4/Q2rkIcM9fGEuSRUzRBPO7OwCU85KTEQxxy
 PxhAYvXWzJM4lk8dUqCq0+z0Wj35RolEK/TsrwSKL/D8NxgFEgRSkAVR0TlFihEy
 VOqtuGQ30OqAHByggfbtJyYVC67BIeFJPMACxKL5682cJRiZ4wCRXwMmtged/K0p
 2BI3Gmz7j22mrTV2ziixNIX7fT6FoTO5KSmbJGJwbHWgctDHHFcWqSmcia6MxWzY
 GxJkH+jEd3qos08kcWaZ
 =cpBc
 -----END PGP SIGNATURE-----

Merge tag 'remoteproc-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc

Pull remoteproc update from Ohad Ben-Cohen:

 - Remoteproc Recovery - by Fernando Guzman Lugo

   When a remote processor crash is detected, this mechanism will remove
   all virtio children devices, wait until their drivers let go, hard
   reset the remote processor and reload the firmware (resulting in the
   relevant virtio children devices re-added).  Essentially the entire
   software stack is reset, together with the relevant hardware, so
   users don't have to reset the entire phone.

 - STE Modem driver is added - by Sjur Brændeland

 - OMAP DSP boot address support is added - by Juan Gutierrez

 - A handful of fixes/cleanups - Sjur Brændeland, Dan Carpenter, Emil
   Goode

* tag 'remoteproc-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
  remoteproc: Fix use of format specifyer
  remoteproc: fix a potential NULL-dereference on cleanup
  remoteproc: select VIRTIO to avoid build breakage
  remoteproc: return -EFAULT on copy_from_user failure
  remoteproc: snprintf() can return more than was printed
  remoteproc: Add STE modem driver
  remtoteproc: maintain max notifyid
  remoteproc: create a 'recovery' debugfs entry
  remoteproc: add actual recovery implementation
  remoteproc: add rproc_report_crash function to notify rproc crashes
  remoteproc: Add dependency to HAS_DMA
  remoteproc/omap: set bootaddr support
2012-10-04 09:11:57 -07:00
Arnd Bergmann 2203747c97 ARM: omap: move platform_data definitions
Platform data for device drivers should be defined in
include/linux/platform_data/*.h, not in the architecture
and platform specific directories.

This moves such data out of the omap include directories

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Jean Pihet <j-pihet@ti.com>
Cc: J Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
2012-09-19 17:39:52 +02:00
Juan Gutierrez 4980f465d2 remoteproc/omap: set bootaddr support
Some remote processors (like OMAP4's DSP) require we explicitly
set a boot address from which they'd start executing code when
taken out of reset.

Support for this is now being added to the omap-specific remoteproc
driver through a set_bootaddr function in the platform data which,
if needed, must be set according to the backend remote processor.

For OMAP4's dsp we can use the following control function:

  .set_bootaddr  = omap_ctrl_write_dsp_boot_addr

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
[ohad: slight changes to the commit log]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-11 15:24:14 +03:00
Linus Torvalds a9197f903f A batch of remoteproc patches for 3.6:
- custom binary format support from Sjur Brændeland
 - groundwork for recovery and runtime pm support
 - some cleanups and API simplifications
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJQD75aAAoJELLolMlTRIoMM84P/RfnGhFl/mzKmDssFtwkajIb
 HRrZ1/YWjAjnSOvD5FF+LrS4TtxPgx9747I1Xh49Uk7DHb6siNTDUNbFJNifWo7g
 TbKo3LgLllfNXnwbunIfiGqOW2HzaCVo6vhk59fL3QAsdtCDlROegt1NbOrV8T2S
 +XZlgYhhUSlIQQCgsRBVJWbwP4k5PtAYmwL1VN7ONgj2ILJDP7MhAasDMl+KeGSG
 128g+aCoIkfc9vC+ghDNAfE6DsHHeVyXAWPoWHoyjiteZ1NDkGxUBdTbsrtMYM2K
 ZguEISfVNcMSk10HhoYWtqYZfZUTEM18kOt/182CEwpRVRE34Z7fhcQCiCGX6u6v
 E+7tNj/0qow+dcj2OtS3NEePIHKcuvjBQ09b6GED+qsmC8lENo2Ly364T6JfriNl
 tv1PShvmodrBlLFusAikJKuzYFI9xgQawpL3oV0pMrEiujHqgNhuqrCQJkIWnA8d
 9At2RZAMdFBFa7gd90lPicVqPR9HcGipVk7bKRyFAoqmpPLI85Nm1r9l4TPqEXpC
 Otb373gX30yqWNRD9Hmmxx/+40S2odELEDN4wrPRF+cCAbmWtFey415gdoaqBESn
 BiTRrHxNy2+dKsCgSUQMyn59rF552qrCb31REYAyMMImpftAaWP35OREFNn6oqj2
 vzxsc4wcWZaLflrqQGj6
 =vBgg
 -----END PGP SIGNATURE-----

Merge tag 'remoteproc-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc

Pull remoteproc update from Ohad Ben-Cohen:
 - custom binary format support from Sjur Brændeland
 - groundwork for recovery and runtime pm support
 - some cleanups and API simplifications

Fix up conflicts in drivers/remoteproc/remoteproc_core.c due to clashes
with earlier cleanups by Sjur Brændeland (with part of the cleanups
moved into the new remoteproc_elf_loader.c file).

* tag 'remoteproc-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
  MAINTAINERS: add remoteproc's git
  remoteproc: Support custom firmware handlers
  remoteproc: Move Elf related functions to separate file
  remoteproc: Add function rproc_get_boot_addr
  remoteproc: Pass struct fw to load_segments and find_rsc_table.
  remoteproc: adopt the driver core's alloc/add/del/put naming
  remoteproc: remove the get_by_name/put API
  remoteproc: support non-iommu carveout assignment
  remoteproc: simplify unregister/free interfaces
  remoteproc: remove the now-redundant kref
  remoteproc: maintain a generic child device for each rproc
  remoteproc: allocate vrings on demand, free when not needed
2012-07-26 16:19:08 -07:00
Ohad Ben-Cohen 160e7c840f remoteproc: adopt the driver core's alloc/add/del/put naming
To make remoteproc's API more intuitive for developers, we adopt
the driver core's naming, i.e. alloc -> add -> del -> put. We'll also
add register/unregister when their first user shows up.

Otherwise - there's no functional change here.

Suggested by Russell King <linux@arm.linux.org.uk>.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06 00:53:27 +03:00
Ohad Ben-Cohen c6b5a27628 remoteproc: simplify unregister/free interfaces
Simplify the unregister/free interfaces, and make them easier
to understand and use, by moving to a symmetric and consistent
alloc() -> register() -> unregister() -> free() flow.

To create and register an rproc instance, one needed to invoke
rproc_alloc() followed by rproc_register().

To unregister and free an rproc instance, one now needs to invoke
rproc_unregister() followed by rproc_free().

Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06 00:53:25 +03:00
Ohad Ben-Cohen b5ab5e24e9 remoteproc: maintain a generic child device for each rproc
For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).

With this in hand, the resulting device hierarchy might then look like:

omap-rproc.0
 |
 - remoteproc0  <---- new !
    |
    - virtio0
    |
    - virtio1
       |
       - rpmsg0
       |
       - rpmsg1
       |
       - rpmsg2

Where:
- omap-rproc.0 is the low level device that's bound to the
  driver which invokes rproc_register()
- remoteproc0 is the result of this patch, and will be added by the
  remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
  when it realizes that they are supported by the firmware
  of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
  channels, and are registerd by the rpmsg bus when it gets notified
  about their existence

Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new "remoteproc" type, to which this new generic remoteproc.x
  device belong to.
- adds a super simple enumeration method for the indices of the
  remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
  instead of the low level platform-specific device
- updates all dma_* allocations to use the parent of remoteproc.x (where
  the platform-specific memory pools, most commonly CMA, are to be found)

Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
  new "remoteproc" type
- all remoteproc log messages will now carry a common name prefix
  instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
  refcounting (see subsequent patch)

Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
with the (upcoming) runtime PM support for remoteproc.

Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06 00:53:03 +03:00
Ohad Ben-Cohen 6b03976288 remoteproc/omap: fix dev_err typo
For some reason one of the dev_err invocations is using a wrong
device so fix that.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: stable@vger.kernel.org
2012-06-17 10:31:03 +03:00
Ohad Ben-Cohen 55f34080d9 remoteproc/omap: remove the mbox_callback limitation
Now that remoteproc supports any number of virtio devices,
the previous sanity check in omap_rproc_mbox_callback
doesn't make sense anymore.

Remove that so we can start supporting multiple vdevs.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Iliyan Malchev <malchev@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: John Williams <john.williams@petalogix.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
Cc: Anna Suman <s-anna@ti.com>
Cc: Clark Rob <rob@ti.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Saravana Kannan <skannan@codeaurora.org>
Cc: David Brown <davidb@codeaurora.org>
Cc: Kieran Bingham <kieranbingham@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
2012-03-06 19:14:23 +02:00
Ohad Ben-Cohen 63d667bf53 remoteproc/omap: utilize module_platform_driver
Ditch some boilerplate code by employing the module_platform_driver
helper.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-02-08 22:54:30 +02:00
Ohad Ben-Cohen 34ed5a33b1 remoteproc/omap: add a remoteproc driver for OMAP4
Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and
and DSP subsystems.

Use the omap_device_* API to control the hardware state, and utilize
the OMAP mailbox to interrupt the remote processor when a new message
is pending (the mailbox payload is used to tell it which virtqueue was
the message placed in).

Conversely, when an inbound mailbox message arrives, tell the remoteproc
core which virtqueue is triggered.

Later we will also use the mailbox payload to signal omap-specific
events like remote crashes (which will be used to trigger remoteproc
recovery) and power management transitions. At that point we will also
extend the remoteproc core to support this.

Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@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>
2012-02-08 22:53:47 +02:00