- May 19, 2020
-
-
Paul Cercueil authored
Inside the Video Processing Unit (VPU) of the recent JZ47xx SoCs from Ingenic is a second Xburst MIPS CPU very similar to the main core. This document describes the devicetree bindings for this auxiliary processor. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200515104340.10473-1-paul@crapouillou.net Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
- May 15, 2020
-
-
Bjorn Andersson authored
Recently qcom_add_glink_subdev() was extended to also take the glink_ssr identifier as an argument and I missed this while applying '8a226e2c ("remoteproc: wcss: add support for rpmsg communication")'. Fixes: 8a226e2c ("remoteproc: wcss: add support for rpmsg communication") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
- May 13, 2020
-
-
Suman Anna authored
The commit 086d0872 ("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: 086d0872 ("remoteproc: create vdev subdevice with specific dma memory pool") Signed-off-by:
Suman Anna <s-anna@ti.com> Reviewed-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by:
Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200420160600.10467-3-s-anna@ti.com Signed-off-by:
-
Tero Kristo authored
In some cases, like with OMAP remoteproc, we are not creating dedicated memory pool for the virtio device. Instead, we use the same memory pool for all shared memories. The current virtio memory pool handling forces a split between these two, as a separate device is created for it, causing memory to be allocated from bad location if the dedicated pool is not available. Fix this by falling back to using the parent device memory pool if dedicated is not available. Cc: stable@vger.kernel.org Reviewed-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507191943.GA16033@embeddedor Signed-off-by:
-
Sivaprakash Murugesan authored
add glink and ssr subdevices for wcss rproc to enable rpmsg communication. Signed-off-by:
Sivaprakash Murugesan <sivaprak@codeaurora.org> Link: https://lore.kernel.org/r/1588350492-4663-1-git-send-email-sivaprak@codeaurora.org Signed-off-by:
-
Rishabh Bhatnagar authored
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 <sidgup@codeaurora.org> Signed-off-by:
Rishabh Bhatnagar <rishabhb@codeaurora.org> Acked-by:
-
Sibi Sankar authored
Remove unsed q6v5_da_to_va function as the mss driver uses a per segment dump function. Tested-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200415071619.6052-2-sibis@codeaurora.org Signed-off-by:
-
Sibi Sankar authored
The application processor accessing the mpss region when the Q6 modem is running will lead to an XPU violation. Fix this by un-mapping the mpss segments post copy during mpss authentication and coredumps. Tested-by:
-
Sibi Sankar authored
7C retail devices using MSA based boot will result in a fuse combination which will prevent accesses to MSS PERPH register space where the mpss clocks and halt-nav reside. So drop all accesses to the MPSS PERPH register space. Issuing HALT NAV request and turning on the mss clocks as part of SSR will no longer be required since the modem firmware will have the necessary fixes to ensure that there are no pending NAV DMA transactions. Tested-by:
-
Sibi Sankar authored
7C retail devices using MSA based boot will result in a fuse combination which will prevent accesses to MSS PERPH register space where the mpss clocks and halt-nav reside. However accesses to conn_box_spare0 in TCSR register space is still permitted so rename the binding appropriately to qcom,spare-regs and drop all accesses to the MPSS PERPH register space. Tested-by:
-
Bjorn Andersson authored
Add audio, compute and sensor DSP compatibles to the Qualcomm PAS binding and driver. Reviewed-by:
-
Bjorn Andersson authored
Add the SM8250 audio, compute and sensor remoteprocs to the PAS DT binding. Acked-by:
-
- May 12, 2020
-
-
Sibi Sankar authored
In the absence of mba and mpss sub-child extract the mba/mpss regions from the memory-region property. Tested-by:
-
Sibi Sankar authored
Use memory-region property to reference mba and mpss memory regions. Reviewed-by:
-
Sibi Sankar authored
Add support for booting the Modem DSP found on Qualcomm's SC7180 SoCs. Tested-by:
-
Sibi Sankar authored
Add MPSS PAS support for SC7180 SoCs. Acked-by:
-
Wei Yongjun authored
sizeof() when applied to a pointer typed expression gives the size of the pointer, not that of the pointed data. Reviewed-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200509084237.36293-1-weiyongjun1@huawei.com Signed-off-by:
-
- May 08, 2020
-
-
Bjorn Andersson authored
In all but the very special case of a system with _only_ glink_rpm, GLINK is dependent on glink_ssr, so move it to rpmsg and combine it with qcom_glink_native in the new qcom_glink kernel module. Acked-by:
Chris Lew <clew@codeaurora.org> Acked-by:
-
Bjorn Andersson authored
Rather than carrying a special purpose blocking notifier for glink_ssr in remoteproc's qcom_common.c, move it into glink_ssr so allow wider reuse of the common one. The rpmsg glink header file is used in preparation for the next patch. Acked-by:
-
Bjorn Andersson authored
Pass ssr_name to glink subdevice in preparation for tying glink_ssr to the glink subdevice, rather than having its own "ssr subdevice". Acked-by:
-
- Apr 23, 2020
-
-
Christophe JAILLET authored
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. Fixes: 791c13b7 ("remoteproc: Fix NULL pointer dereference in rproc_virtio_notify") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20200411160750.32573-1-christophe.jaillet@wanadoo.fr Signed-off-by:
-
Loic Pallardy authored
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 <loic.pallardy@st.com> Signed-off-by:
-
Clement Leger authored
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:
Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200422093017.10985-1-cleger@kalray.eu Signed-off-by:
-
- Apr 21, 2020
-
-
Paul Cercueil authored
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:
-
Suman Anna authored
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 authored
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:
Alex Elder <elder@linaro.org> Reviewed-by:
-
Mathieu Poirier authored
Make the rproc_ops allocation a function on its own in an effort to clean up function rproc_alloc(). Signed-off-by:
-
Mathieu Poirier authored
Improve the readability of function rproc_alloc_firmware() by using a non-negated condition and moving the comment out of the conditional block Suggested-by:
-
Mathieu Poirier authored
For cases where @firmware is declared "const char *", use function kstrdup_const() to avoid needlessly creating another copy on the heap. Suggested-by:
-
- Apr 20, 2020
-
-
Siddharth Gupta authored
Clients/services running on a remoteproc that booted up might need to be aware of the state of already running remoteprocs. When a remoteproc boots up (fresh or after recovery) it is not aware of the remoteprocs that booted before it, i.e., the system state is incomplete. So to keep track of it we send sysmon on behalf of all 'ONLINE' remoteprocs. Acked-by:
-
Siddharth Gupta authored
Add notification for other stages of remoteproc boot and shutdown. This includes adding callback functions for the prepare and unprepare events, and fleshing out the callback function for start. Acked-by:
-
Siddharth Gupta authored
Current implementation of the sysmon driver does not support adding notifications for other remoteproc events - prepare, start, unprepare. Clients on the remoteproc side might be interested in knowing when a remoteproc boots up. This change adds the ability to send the notification type along with the name. For example, audio DSP is interested in knowing when modem has crashed so that it can perform cleanup and wait for modem to boot up before it starts processing data again. Acked-by:
-
Clement Leger authored
Modify drivers which are using remoteproc coredump functionality to use rproc_coredump_set_elf_info in order to create correct elf coredump format. Reviewed-by:
-
Clement Leger authored
This function allows drivers to correctly setup the coredump output elf information. Reviewed-by:
-
Mathieu Poirier authored
In an effort to cleanup firmware name allocation, replace the cumbersome mechanic used to allocate a default firmware name with function kasprintf(). Reviewed-by:
-
Mathieu Poirier authored
Make the firmware name allocation a function on its own in an effort to cleanup function rproc_alloc(). Reviewed-by:
-
Alex Elder authored
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: b5ab5e24 ("remoteproc: maintain a generic child device for each rproc") Signed-off-by:
-
- Apr 17, 2020
-
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Link: https://lore.kernel.org/r/20181201155838.8619-1-tiny.windzz@gmail.com Signed-off-by:
-
- Apr 13, 2020
-
-
Linus Torvalds authored
-
