14 Dec, 2020
1 commit
-
To i.MX8QM/QXP partitioned M4 case, M4 will do self recovery when
crashed. It not need Linux to reload firmware. So add a flag to indicate
there is no need to request firmware when recovery.Acked-by: Richard Zhu
Signed-off-by: Peng Fan
06 Oct, 2020
1 commit
-
Split out all the bits that are purely for dma_map_ops implementations
and related code into a new header so that they
don't get pulled into all the drivers. That also means the architecture
specific is not pulled in by
any more, which leads to a missing includes that were pulled in by the
x86 or arm versions in a few not overly portable drivers.Signed-off-by: Christoph Hellwig
18 Sep, 2020
1 commit
-
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_direct_set_offset(dev, cpu_addr, dma_addr, size).Signed-off-by: Jim Quinlan
[hch: various interface cleanups]
Signed-off-by: Christoph Hellwig
Reviewed-by: Mathieu Poirier
Tested-by: Mathieu Poirier
Tested-by: Nathan Chancellor
05 Aug, 2020
1 commit
-
Add the character device during rproc_add. This would create
a character device node at /dev/remoteproc. Userspace
applications can interact with the remote processor using this
interface.Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Signed-off-by: Rishabh Bhatnagar
Signed-off-by: Siddharth Gupta
Link: https://lore.kernel.org/r/1596044401-22083-3-git-send-email-sidgup@codeaurora.org
Signed-off-by: Bjorn Andersson
29 Jul, 2020
1 commit
-
Add a new helper function rproc_of_parse_firmware() to the remoteproc
core that can be used by various remoteproc drivers to look up the
the "firmware-name" property from a rproc device node. This property
is already being used by multiple drivers, so this helper can avoid
repeating equivalent code in remoteproc drivers.Signed-off-by: Suman Anna
Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200721223617.20312-3-s-anna@ti.com
Signed-off-by: Bjorn Andersson
22 Jul, 2020
1 commit
-
Move all coredump functionality to an individual file. This is
being done so that the current functionality can be extended
in future patchsets.Signed-off-by: Rishabh Bhatnagar
Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Reviewed-by: Sibi Sankar
Tested-by: Sibi Sankar
Link: https://lore.kernel.org/r/1594938035-7327-2-git-send-email-rishabhb@codeaurora.org
Signed-off-by: Bjorn Andersson
18 Jul, 2020
1 commit
-
Make function rproc_resource_cleanup() public so that it can be
used by platform drivers when allocating resources to be used by
a detached remote processor.Acked-by: Arnaud Pouliquen
Signed-off-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200714200445.1427257-8-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson
17 Jul, 2020
7 commits
-
This patch prevents the firmware image name from being displayed when
the remoteproc core is attaching to a remote processor. This is needed
needed since there is no guarantee about the nature of the firmware
image that is loaded by the external entity.Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-10-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
When function rproc_free_vring() clears the virtio device section
it does so on the cached resource table rather than the one
installed in the remote processor memory. When a remote processor
has been booted by another entity there is no need to use a cached
table and as such, no need to clear the virtio device section in
it.Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-9-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Refactor function rproc_trigger_auto_boot() to properly deal
with scenarios where the remoteproc core needs to attach with a
remote processor that has already been booted by an external
entity.Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-8-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Refactor function rproc_boot() to properly deal with scenarios
where the remoteproc core needs to attach with a remote
processor that has already been booted by an external entity.Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-7-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Add a new function to assert the general health of the remote
processor before handing it to the remoteproc core.Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-6-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Introduce function rproc_actuate() that provides the same
functionatlity as rproc_fw_boot(), but without the steps that
involve interaction with the firmware image. That way we can
deal with scenarios where the remoteproc core is attaching
to a remote processor that has already been started by another
entity.Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-5-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Introducing function rproc_attach() to enact the same actions as
rproc_start(), but without the steps related to the handling of
a firmware image. That way we can properly deal with scenarios
where the remoteproc core needs to attach with a remote processsor
that has been booted by another entity.Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200714195035.1426873-4-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson
16 Jul, 2020
1 commit
-
Fixes the following W=1 kernel build warning(s):
drivers/remoteproc/remoteproc_core.c: In function ‘rproc_find_carveout_by_name’:
drivers/remoteproc/remoteproc_core.c:257:2: warning: function ‘rproc_find_carveout_by_name’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
257 | vsnprintf(_name, sizeof(_name), name, args);
| ^~~~~~~~~
drivers/remoteproc/remoteproc_core.c: In function ‘rproc_mem_entry_init’:
drivers/remoteproc/remoteproc_core.c:993:2: warning: function ‘rproc_mem_entry_init’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
993 | vsnprintf(mem->name, sizeof(mem->name), name, args);
| ^~~~~~~~~
drivers/remoteproc/remoteproc_core.c: In function ‘rproc_of_resm_mem_entry_init’:
drivers/remoteproc/remoteproc_core.c:1029:2: warning: function ‘rproc_of_resm_mem_entry_init’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
1029 | vsnprintf(mem->name, sizeof(mem->name), name, args);
| ^~~~~~~~~Cc: Brian Swetland
Cc: Mark Grosen
Cc: Guzman Lugo
Cc: Suman Anna
Cc: Robert Tivy
Cc: De Leon
Signed-off-by: Lee Jones
Link: https://lore.kernel.org/r/20200715123551.4011154-1-lee.jones@linaro.org
Signed-off-by: Bjorn Andersson
02 Jul, 2020
1 commit
-
This reverts commit a99a37f6cd5a74d5b22c08544aa6c5890813c8ba.
Removing PM runtime operations from the remoteproc core in order to:
1) Keep all power management operations in platform drivers. That way we
do not loose flexibility in an area that is very HW specific.2) Avoid making the support for remote processor managed by external
entities more complex that it already is.3) Fix regression introduced for the Omap remoteproc driver.
Acked-by: Suman Anna
Tested-by: Suman Anna
Signed-off-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200630163118.3830422-3-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson
21 May, 2020
1 commit
-
The comments say that this function should return NULL on error and the
caller expects NULL returns as well so I have modified the code to match.
Returning an ERR_PTR(-ENOMEM) would lead to an OOps.Reviewed-by: Paul Cercueil
Reviewed-by: Bjorn Andersson
Fixes: 305ac5a766b1 ("remoteproc: Add device-managed variants of rproc_alloc/rproc_add")
Signed-off-by: Dan Carpenter
Link: https://lore.kernel.org/r/20200520120705.GH172354@mwanda
Signed-off-by: Bjorn Andersson
19 May, 2020
1 commit
-
Call pm_runtime_get_sync() before the firmware is loaded, and
pm_runtime_put() after the remote processor has been stopped.Even though the remoteproc device has no PM callbacks, this allows the
parent device's PM callbacks to be properly called.Signed-off-by: Paul Cercueil
Link: https://lore.kernel.org/r/20200515104340.10473-3-paul@crapouillou.net
Signed-off-by: Bjorn Andersson
13 May, 2020
2 commits
-
The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).Cc: stable@vger.kernel.org
Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna
Reviewed-by: Mathieu Poirier
Acked-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/20200420160600.10467-3-s-anna@ti.com
Signed-off-by: Bjorn Andersson -
The system might go into suspend during recovery of any remoteproc.
This will interrupt the recovery process in between increasing the
recovery time. Make the platform device as wakeup capable and
use pm_stay_wake/pm_relax APIs to avoid system from going into
suspend during recovery.Signed-off-by: Siddharth Gupta
Signed-off-by: Rishabh Bhatnagar
Acked-by: Mathieu Poirier
Link: https://lore.kernel.org/r/1588183482-21146-1-git-send-email-rishabhb@codeaurora.org
Signed-off-by: Bjorn Andersson
23 Apr, 2020
2 commits
-
On some SoC architecture, it is needed to enable HW like
clock, bus, regulator, memory region... before loading
co-processor firmware.This patch introduces prepare and unprepare ops to execute
platform specific function before firmware loading and after
stop execution.Signed-off-by: Loic Pallardy
Signed-off-by: Suman Anna
Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200417002036.24359-2-s-anna@ti.com
Signed-off-by: Bjorn Andersson -
Since checks are present in the remoteproc elf loader before calling
da_to_va, loading a elf64 will work on 32bits flavors of kernel.
Indeed, if a segment size is larger than what size_t can hold, the
loader will return an error so the functionality is equivalent to
what exists today.Acked-by: Suman Anna
Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200422093017.10985-1-cleger@kalray.eu
Signed-off-by: Bjorn Andersson
21 Apr, 2020
6 commits
-
Add API functions devm_rproc_alloc() and devm_rproc_add(), which behave
like rproc_alloc() and rproc_add() respectively, but register their
respective cleanup function to be called on driver detach.Reviewed-by: Bjorn Andersson
Signed-off-by: Paul Cercueil
Link: https://lore.kernel.org/r/20200417170040.174319-2-paul@crapouillou.net
Signed-off-by: Bjorn Andersson -
The current name field used in the remoteproc structure is simply
a pointer to a name field supplied during the rproc_alloc() call.
The pointer passed in by remoteproc drivers during registration is
typically a dev_name pointer, but it is possible that the pointer
will no longer remain valid if the devices themselves were created
at runtime like in the case of of_platform_populate(), and were
deleted upon any failures within the respective remoteproc driver
probe function.So, allocate and maintain a local copy for this name field to
keep it agnostic of the logic used in the remoteproc drivers.Reviewed-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Signed-off-by: Suman Anna
Link: https://lore.kernel.org/r/20200417002036.24359-3-s-anna@ti.com
Signed-off-by: Bjorn Andersson -
Get rid of tedious error management by moving firmware and operation
allocation after calling device_initialize(). That way we take advantage
of the automatic call to rproc_type_release() to cleanup after ourselves
when put_device() is called.Signed-off-by: Mathieu Poirier
Reviewed-by: Alex Elder
Reviewed-by: Bjorn Andersson
Acked-by: Suman Anna
Link: https://lore.kernel.org/r/20200420231601.16781-5-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Make the rproc_ops allocation a function on its own in an effort
to clean up function rproc_alloc().Signed-off-by: Mathieu Poirier
Reviewed-by: Alex Elder
Reviewed-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20200420231601.16781-4-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Improve the readability of function rproc_alloc_firmware() by using
a non-negated condition and moving the comment out of the conditional
blockSuggested-by: Alex Elder
Signed-off-by: Mathieu Poirier
Reviewed-by: Alex Elder
Reviewed-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20200420231601.16781-3-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
For cases where @firmware is declared "const char *", use function
kstrdup_const() to avoid needlessly creating another copy on the
heap.Suggested-by: Bjorn Andersson
Signed-off-by: Mathieu Poirier
Reviewed-by: Alex Elder
Reviewed-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20200420231601.16781-2-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson
20 Apr, 2020
4 commits
-
This function allows drivers to correctly setup the coredump output
elf information.Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200410102433.2672-2-cleger@kalray.eu
Signed-off-by: Bjorn Andersson -
In an effort to cleanup firmware name allocation, replace the
cumbersome mechanic used to allocate a default firmware name with
function kasprintf().Reviewed-by: Alex Elder
Reviewed-by: Bjorn Andersson
Suggested-by: Bjorn Andersson
Signed-off-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200415204858.2448-4-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
Make the firmware name allocation a function on its own in an
effort to cleanup function rproc_alloc().Reviewed-by: Alex Elder
Reviewed-by: Bjorn Andersson
Signed-off-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200415204858.2448-3-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson -
If ida_simple_get() returns an error when called in rproc_alloc(),
put_device() is called to clean things up. By this time the rproc
device type has been assigned, with rproc_type_release() as the
release function.The first thing rproc_type_release() does is call:
idr_destroy(&rproc->notifyids);But at the time the ida_simple_get() call is made, the notifyids
field in the remoteproc structure has not been initialized.I'm not actually sure this case causes an observable problem, but
it's incorrect. Fix this by initializing the notifyids field before
calling ida_simple_get() in rproc_alloc().Fixes: b5ab5e24e960 ("remoteproc: maintain a generic child device for each rproc")
Signed-off-by: Alex Elder
Reviewed-by: Mathieu Poirier
Reviewed-by: Suman Anna
Reviewed-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20200415204858.2448-2-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson
26 Mar, 2020
8 commits
-
Introduce generic support for handling kernel panics in remoteproc
drivers, in order to allow operations needed for aiding in post mortem
system debugging, such as flushing caches etc.The function can return a number of milliseconds needed by the remote to
"settle" and the core will wait the longest returned duration before
returning from the panic handler.Reviewed-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324052904.738594-3-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson -
In order to be able to traverse the mostly read-only rproc_list without
locking during panic migrate traversal to be done under rcu_read_lock().Mutual exclusion for modifications of the list continues to be handled
by the rproc_list_mutex and a synchronization point is added before
releasing objects that are popped from the list.Reviewed-by: Mathieu Poirier
Link: https://lore.kernel.org/r/20200324052904.738594-2-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson -
Two places call rproc_trigger_recovery():
- rproc_crash_handler_work() sets rproc->state to CRASHED under
protection of the mutex, then calls it if recovery is not
disabled. This function is called in workqueue context when
scheduled in rproc_report_crash().
- rproc_recovery_write() calls it in two spots, both of which
the only call it if the rproc->state is CRASHED.The mutex is taken right away in rproc_trigger_recovery(). However,
by the time the mutex is acquired, something else might have changed
rproc->state to something other than CRASHED.The work that follows that is only appropriate for a remoteproc in
CRASHED state. So check the state after acquiring the mutex, and
only proceed with the recovery work if the remoteproc is still in
CRASHED state.Delay reporting that recovering has begun until after we hold the
mutex and we know the remote processor is in CRASHED state.Signed-off-by: Alex Elder
Link: https://lore.kernel.org/r/20200228183359.16229-2-elder@linaro.org
Signed-off-by: Bjorn Andersson -
Now that remoteproc can load an elf64, coredump elf class should be
the same as the loaded elf class. In order to do that, add a
elf_class field to rproc with default values. If an elf is loaded
successfully, this field will be updated with the loaded elf class.
Then, the coredump core code has been modified to use the generic elf
macro in order to create an elf file with correct class.Reviewed-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200302093902.27849-9-cleger@kalray.eu
Signed-off-by: Bjorn Andersson -
Now that rproc_elf_sanity_check can be used by external drivers, allow
to only overwrite the sanity_check member of rproc_ops. This will allow
drivers to handle elf32 and elf64 by overwriting sanity_check with
rproc_elf_sanity_check function.Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200302093902.27849-8-cleger@kalray.eu
Signed-off-by: Bjorn Andersson -
Since this function will be modified to support both elf32 and elf64,
rename the existing one to elf32 (which is the only supported format
at the moment). This will allow not to introduce possible side effect
when adding elf64 support (ie: all backends will still support only
elf32 if not requested explicitely using rproc_elf_sanity_check).Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200302093902.27849-6-cleger@kalray.eu
Signed-off-by: Bjorn Andersson -
Now that rproc_da_to_va uses a size_t for length, use a size_t for len
field of rproc_mem_entry. Function used to create such structures now
takes a size_t instead of int to allow full size range to be handled.Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200302093902.27849-3-cleger@kalray.eu
Signed-off-by: Bjorn Andersson -
With upcoming changes in elf loader for elf64 support, section size will
be a u64. When used with da_to_va, this will potentially lead to
overflow if using the current "int" type for len argument. Change
da_to_va prototype to use a size_t for len and fix all users of this
function.Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Signed-off-by: Clement Leger
Link: https://lore.kernel.org/r/20200302093902.27849-2-cleger@kalray.eu
Signed-off-by: Bjorn Andersson
