- 14 Apr, 2021 9 commits
-
-
Peng Fan authored
- When remote cores are kicked before Linux Kernel, we are not able to get resource table from the firmware elf file, so we need to add rsc_table to hold the resource table published by remote cores and imx_rproc_get_loaded_rsc_table is to get the resource table. - Per remoteproc framework, add attach hook for processor in a detached state. - Add imx_rproc_detect_mode to detect remote cores' working mode to set the state which is required by remoteproc framework. Reviewed-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1617846289-13496-5-git-send-email-peng.fan@oss.nxp.comSigned-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
Peng Fan authored
Use the rproc_ops::prepare() hook for doing memory resources reallocation when reattaching a remote procesor. Suggested-by:
-
Peng Fan authored
8 is not enough when we need more, such as resource table for remote cores that booted before Linux Kernel, so enlarge IMX7D_RPROC_MEM_MAX to 32. And also rename it to IMX_RPROC_MEM_MAX which make more sense. Signed-off-by:
-
Peng Fan authored
After of_parse_phandle, we need of_node_put to decrease the refcount of the device_node. Reported-by:
-
Wei Yongjun authored
Fix build error when CONFIG_MAILBOX is not set: arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_kick': imx_rproc.c:(.text+0x328): undefined reference to `mbox_send_message' arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_probe': imx_rproc.c:(.text+0x52c): undefined reference to `mbox_request_channel_byname' arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x548): undefined reference to `mbox_request_channel_byname' arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x76c): undefined reference to `mbox_free_channel' arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x774): undefined reference to `mbox_free_channel' arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x7c4): undefined reference to `mbox_free_channel' arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_remove': imx_rproc.c:(.text+0x86c): undefined reference to `mbox_free_channel' arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x874): undefined reference to `mbox_free_channel' make: *** [Makefile:1292: vmlinux] Error 1 Reviewed-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210331122709.3935521-1-weiyongjun1@huawei.comSigned-off-by:
-
Junlin Yang authored
Remove unnecessary PTR_ERR(), it has been assigned to ret before, so return ret directly. Signed-off-by:
Junlin Yang <yangjunlin@yulong.com> Link: https://lore.kernel.org/r/20210408143322.1647-1-angkery@163.comSigned-off-by:
-
Wei Yongjun authored
PTR_ERR should access the value just tested by IS_ERR, otherwise the wrong error code will be returned. This commit fix it by return 'ret' directly. Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 0af65b9b ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Reported-by:
-
Manivannan Sadhasivam authored
Add remoteproc support for Hexagon modem found on the Qualcomm SDX55 platform. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210408171211.92141-1-manivannan.sadhasivam@linaro.orgSigned-off-by:
-
Manivannan Sadhasivam authored
Add devicetree binding for SDX55 remoteproc. Acked-by:
Rob Herring <robh@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by:
-
- 13 Apr, 2021 4 commits
-
-
Wei Yongjun authored
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 0af65b9b ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Reported-by:
-
Suman Anna authored
The PRU firmware interrupt mappings are configured and unconfigured in .start() and .stop() callbacks respectively using the variables 'evt_count' and a 'mapped_irq' pointer. These variables are modified only during these callbacks but are not re-initialized/reset properly during unwind or failure paths. These stale values caused a kernel crash while stopping a PRU remoteproc running a different firmware with no events on a subsequent run after a previous run that was running a firmware with events. Fix this crash by ensuring that the evt_count is 0 and the mapped_irq pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these variables properly during any failures in the .start() callback. While at this, the pru_dispose_irq_mapping() callsites are all made to look the same, moving any conditional logic to inside the function. Reviewed-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210407155641.5501-4-s-anna@ti.comSigned-off-by:
-
Suman Anna authored
The irq_create_fwspec_mapping() returns a proper virq value on success and 0 upon any failure. The pru_handle_intrmap() treats this as an error and disposes all firmware event mappings correctly, but is returning this incorrect value as is, letting the pru_rproc_start() interpret it as a success and boot the PRU. Fix this by returning an error value back upon any such failure. While at this, revise the error trace to print some meaningful info about the failed event. Fixes: c75c9fda ("remoteproc: pru: Add support for PRU specific interrupt configuration") Signed-off-by:
-
Suman Anna authored
The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses of_irq_find_parent() with PRU device node to get a handle to the PRUSS Interrupt Controller at present. This logic however requires that the PRU nodes always define a interrupt-parent property. This property is neither a required/defined property as per the PRU remoteproc binding, nor is relevant from a DT node point of view without any associated interrupts. The current logic finds a wrong interrupt controller and fails to perform proper mapping without any interrupt-parent property in the PRU nodes. Fix this logic to always find and use the sibling interrupt controller. Also, while at this, fix the acquired interrupt controller device node reference properly. Fixes: c75c9fda ("remoteproc: pru: Add support for PRU specific interrupt configuration") Signed-off-by:
-
- 18 Mar, 2021 24 commits
-
-
Bjorn Andersson authored
Introduce a firmware-name property, in order to be able to support device/platform specific firmware for the wireless connectivity subsystem; in line with other Qualcomm remoteproc drivers. Acked-by:
-
Govind Singh authored
Use request exclusive reset control for wcss reset controls. Signed-off-by:
Govind Singh <govinds@codeaurora.org> Signed-off-by:
Gokul Sriram Palanisamy <gokulsri@codeaurora.org> Link: https://lore.kernel.org/r/1611859695-11824-5-git-send-email-gokulsri@codeaurora.orgSigned-off-by:
-
Govind Singh authored
Add non PAS WCSS remoteproc driver support for QCS404 SOC. Add WCSS q6 bootup and shutdown sequence handled from Application Processor SubSystem(APSS). Signed-off-by:
-
Govind Singh authored
Add a new modem compatible string for Qualcomm QCS404 SoCs Signed-off-by:
-
Govind Singh authored
Q6 based WiFi fw loading is supported across different targets, ex: IPQ8074/QCS404. In order to support different fw names/pas id etc, populate hardcoded param using driver data. Signed-off-by:
-
Mathieu Poirier authored
Refactor function rproc_cdev_release() to take into account the current state of the remote processor when choosing the state to transition to. Signed-off-by:
-
Mathieu Poirier authored
This patch introduces the capability to detach a remote processor that has been attached to by the remoteproc core. For that to happen a rproc::ops::detach() operation needs to be available. Signed-off-by:
Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20210312162453.1234145-17-mathieu.poirier@linaro.orgSigned-off-by:
-
Mathieu Poirier authored
Allow a remote processor that was started by another entity to be switched off by the remoteproc core. For that to happen a rproc::ops::stop() operation needs to be available. Signed-off-by:
-
Mathieu Poirier authored
This patch takes into account scenarios where a remote processor has been attached to when receiving a "start" command from sysfs. As with the case with the running state, the command can't be carried out if the remote processor is already in operation. Signed-off-by:
-
Mathieu Poirier authored
The panic handler operation of registered remote processors should also be called when remote processors have been attached to. Signed-off-by:
-
Mathieu Poirier authored
When a remote processor that was attached to is stopped, special care must be taken to make sure the shutdown process is similar to what it would be had it been started by the remoteproc core. This patch takes care of that by making a copy of the resource table currently used by the remote processor. From that point on the copy is used, as if the remote processor had been started by the remoteproc core. Signed-off-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20210312162453.1234145-13-mathieu.poirier@linaro.orgSigned-off-by:
-
Mathieu Poirier authored
If it is possible to detach the remote processor, keep an untouched copy of the resource table. That way we can start from the same resource table without having to worry about original values or what elements the startup code has changed when re-attaching to the remote processor. Signed-off-by:
-
Mathieu Poirier authored
Introduce function rproc_detach() to enable the remoteproc core to release the resources associated with a remote processor without stopping its operation. Signed-off-by:
-
Mathieu Poirier authored
Introduce function __rproc_detach() to perform the same kind of operation as rproc_stop(), but instead of switching off the remote processor using rproc->ops->stop(), it uses rproc->ops->detach(). That way it is possible for the core to release the resources associated with a remote processor while the latter is kept operating. Signed-off-by:
-
Mathieu Poirier authored
Add an new detach() operation in order to support scenarios where the remoteproc core is going away but the remote processor is kept operating. This could be the case when the system is rebooted or when the platform driver is removed. Signed-off-by:
-
Arnaud POULIQUEN authored
Some actions such as memory resources reallocation are needed when trying to reattach a co-processor. Use the prepare() operation for these actions. Co-developed-by:
Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20210312162453.1234145-8-mathieu.poirier@linaro.orgSigned-off-by:
-
Mathieu Poirier authored
Move the setting of the resource table installed by an external entity to rproc_ops::get_loaded_rsc_table(). This is to support scenarios where a remote processor has been attached to but is detached at a later stage. To re-attach the remote processor, the address of the resource table needs to be available at a later time than the platform driver's probe() function. Signed-off-by:
-
Mathieu Poirier authored
Add a new get_loaded_rsc_table() operation in order to support scenarios where the remoteproc core has booted a remote processor and detaches from it. When re-attaching to the remote processor, the core needs to know where the resource table has been placed in memory. Signed-off-by:
-
Mathieu Poirier authored
There is a need to know when a remote processor has been attached to rather than booted by the remoteproc core. In order to avoid manipulating two variables, i.e rproc::autonomous and rproc::state, get rid of the former and simply use the newly introduced RPROC_ATTACHED state. Signed-off-by:
-
Mathieu Poirier authored
Add a new RPROC_ATTACHED state to take into account scenarios where the remoteproc core needs to attach to a remote processor that is booted by another entity. Signed-off-by:
-
Mathieu Poirier authored
Rename function rproc_actuate() to rproc_attach(). That way it is easy to understand that it does the opposite of rproc_detach(). Signed-off-by:
-
Mathieu Poirier authored
Whether started at probe() time or thereafter from the command line, a remote processor needs to be shut down before the final cleanup phases can happen. Otherwise the system may be left in an unpredictable state where the remote processor is expecting the remoteproc core to be providing services when in fact it no longer exist. Invariably calling rproc_shutdown() is fine since it will return immediately if the remote processor has already been switched off. Signed-off-by:
-
Bjorn Andersson authored
Analog to the issue in the common mdt_loader code the MSS ELF loader does not validate that p_filesz bytes will fit in the memory region and that the loaded segments are not truncated. Fix this in the same way as proposed for the mdt_loader. Reviewed-by:
-
Bjorn Andersson authored
Failing to read the "firmware-name" DT property without informing the developer is annoying, add some helpful debug prints. Reviewed-by:
-
- 13 Mar, 2021 1 commit
-
-
Wei Yongjun authored
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: ecadcc47 ("remoteproc: imx_rproc: use devm_ioremap") Reported-by:
-
- 11 Mar, 2021 2 commits
-
-
Peng Fan authored
Use virtio/mailbox to build connection between Remote Proccessors and Linux. Add work queue to handle incoming messages. Reviewed-by:
Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by:
Mathieu Poirier <mathieu.poirer@linaro.org> Signed-off-by:
-
Peng Fan authored
vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar. They are handled by remoteproc common code, no need to map in imx rproc driver. Signed-off-by:
-
