- 14 Apr, 2021 1 commit
-
-
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:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210408170457.91409-15-manivannan.sadhasivam@linaro.orgSigned-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
- 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:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210319094100.4185044-1-weiyongjun1@huawei.comSigned-off-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:
Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: c75c9fda ("remoteproc: pru: Add support for PRU specific interrupt configuration") Reported-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:
Peng Fan <peng.fan@nxp.com> Reviewed-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 10 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:
-
Peng Fan authored
Add i.MX8MQ dev/sys addr map and configuration data structure i.MX8MM share i.MX8MQ settings. Reviewed-by:
-
Peng Fan authored
The hook is used to parse memory-regions and load resource table from the address the remote processor published. Reviewed-by:
-
Peng Fan authored
We might need to map an region multiple times, becaue the region might be shared between remote processors, such i.MX8QM with dual M4 cores. So use devm_ioremap, not devm_ioremap_resource. Reviewed-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
-
Peng Fan authored
It is using devm_ioremap, so not devm_ioremap_resource. Correct the error message and print out sa/size. Reviewed-by:
-
Peng Fan authored
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:
-
Peng Fan authored
Introduce is_iomem to indicate this piece memory is iomem or not. Reviewed-by:
-
Peng Fan authored
Add i.MX8MQ/M support, also include mailbox for rpmsg/virtio usage. Reviewed-by:
-
Peng Fan authored
Convert the imx rproc binding to DT schema format using json-schema. Reviewed-by:
-
