24 Aug, 2020
1 commit
-
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
04 Apr, 2020
1 commit
-
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 02e6d546e3bd ("clocksource/drivers/timer-ti-dm:
Enable autoreload in set_pwm") in the clockevents tree interacting with
commit e28edc571925 ("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: c6570114316f ("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
Acked-by: Suman Anna
Signed-off-by: Linus Torvalds
26 Mar, 2020
12 commits
-
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
Signed-off-by: Suman Anna
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Link: https://lore.kernel.org/r/20200324110035.29907-15-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Subramaniam Chanderashekarapuram
Signed-off-by: Suman Anna
Signed-off-by: Tero Kristo
Reviewed-by: Bjorn Andersson
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-14-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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_msThe 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/controlSigned-off-by: Suman Anna
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-13-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-12-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-11-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Subramaniam Chanderashekarapuram
Signed-off-by: Suman Anna
Signed-off-by: Tero Kristo
Reviewed-by: Bjorn Andersson
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-10-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
[t-kristo@ti.com: moved address translation quirks to pdata]
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-8-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Tero Kristo
Reviewed-by: Bjorn Andersson
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-7-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-6-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
[t-kristo: converted to parse mem names / device addresses from pdata]
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-5-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Tero Kristo
Reviewed-by: Bjorn Andersson
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-4-t-kristo@ti.com
Signed-off-by: Bjorn Andersson -
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
Signed-off-by: Suman Anna
[t-kristo@ti.com: converted to use ti-sysc framework]
Signed-off-by: Tero Kristo
Reviewed-by: Andrew F. Davis
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324110035.29907-3-t-kristo@ti.com
Signed-off-by: Bjorn Andersson
31 May, 2019
1 commit
-
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 detailsextracted 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
Reviewed-by: Allison Randal
Reviewed-by: Kate Stewart
Reviewed-by: Richard Fontana
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de
Signed-off-by: Greg Kroah-Hartman
19 Jan, 2017
1 commit
-
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.o970 240 0 1210 4ba remoteproc/omap_remoteproc.o
1002 192 0 1194 4aa remoteproc/omap_remoteproc.o1901 240 0 2141 85d remoteproc/st_remoteproc.o
1933 192 0 2125 84d remoteproc/st_remoteproc.o1288 96 0 1384 568 remoteproc/st_slim_rproc.o
1320 64 0 1384 568 remoteproc/st_slim_rproc.o2121 240 0 2361 939 remoteproc/wkup_m3_rproc.o
2161 192 0 2353 931 remoteproc/wkup_m3_rproc.oSigned-off-by: Bhumika Goyal
Signed-off-by: Bjorn Andersson
03 Oct, 2016
1 commit
-
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
13 Aug, 2016
2 commits
-
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
Signed-off-by: Bjorn Andersson -
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 parenthesisSigned-off-by: Suman Anna
Signed-off-by: Bjorn Andersson
12 Mar, 2015
1 commit
-
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
Cc: Linus Walleij
Signed-off-by: Suman Anna
[small change in the commit title and in a single comment]
Signed-off-by: Ohad Ben-Cohen
15 Dec, 2014
1 commit
-
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__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
...
27 Nov, 2014
1 commit
-
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
Cc: Ohad Ben-Cohen
Signed-off-by: Jassi Brar
20 Oct, 2014
1 commit
-
A platform_driver does not need to set an owner, it will be populated by the
driver core.Signed-off-by: Wolfram Sang
12 Jun, 2013
1 commit
-
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
[gregkh@linuxfoundation.org: ack for staging part]
Acked-by: Greg Kroah-Hartman
Signed-off-by: Omar Ramirez Luna
Signed-off-by: Suman Anna
04 Jan, 2013
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
05 Oct, 2012
1 commit
-
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
19 Sep, 2012
1 commit
-
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
Acked-by: Mark Brown
Acked-by: Greg Kroah-Hartman
Acked-by: Nicolas Pitre
Acked-by: Tony Lindgren
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Dmitry Torokhov
Cc: David Woodhouse
Cc: Kyungmin Park
Cc: Ohad Ben-Cohen
Cc: Grant Likely
Cc: Omar Ramirez Luna
Cc: Tomi Valkeinen
Cc: Florian Tobias Schandinat
Cc: Peter Ujfalusi
Cc: Jarkko Nikula
Cc: Liam Girdwood
Cc: Artem Bityutskiy
Cc: Jean Pihet
Cc: J Keerthy
Cc: linux-omap@vger.kernel.org
11 Sep, 2012
1 commit
-
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
Signed-off-by: Suman Anna
[ohad: slight changes to the commit log]
Signed-off-by: Ohad Ben-Cohen
27 Jul, 2012
1 commit
-
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 simplificationsFix 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
06 Jul, 2012
3 commits
-
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 .
Cc: Russell King
Cc: Fernando Guzman Lugo
Cc: Sjur Brændeland
Reviewed-by: Linus Walleij
Acked-by: Stephen Boyd
Signed-off-by: Ohad Ben-Cohen -
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
Signed-off-by: Ohad Ben-Cohen -
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 for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo for trying them out
with the (upcoming) runtime PM support for remoteproc.Cc: Fernando Guzman Lugo
Reviewed-by: Stephen Boyd
Signed-off-by: Ohad Ben-Cohen
17 Jun, 2012
1 commit
-
For some reason one of the dev_err invocations is using a wrong
device so fix that.Signed-off-by: Ohad Ben-Cohen
Cc: stable@vger.kernel.org
07 Mar, 2012
1 commit
-
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
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren
09 Feb, 2012
2 commits
-
Ditch some boilerplate code by employing the module_platform_driver
helper.Signed-off-by: Ohad Ben-Cohen
-
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
and Hari Kanigeri .Designed with Brian Swetland .
Signed-off-by: Ohad Ben-Cohen
Acked-by: Tony Lindgren
Cc: Brian Swetland
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Russell King
Cc: Rusty Russell
Cc: Andrew Morton
Cc: Greg KH
Cc: Stephen Boyd