kernel.git/drivers/remoteproc/mtk_scp.c, branch master

remoteproc: mediatek: Unprepare SCP clock during system suspend

2026-03-05T17:14:36Z

Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock"), `scp->clk` was prepared and enabled only when it needs to communicate with the SCP. The commit d935187cfb27 moved the prepare operation to remoteproc's prepare(), keeping the clock prepared as long as the SCP is running. The power consumption due to the prolonged clock preparation can be negligible when the system is running, as SCP is designed to be a very power efficient processor. However, the clock remains prepared even when the system enters system suspend. This prevents the underlying clock controller (and potentially the parent PLLs) from shutting down, which increases power consumption and may block the system from entering deep sleep states. Add suspend and resume callbacks. Unprepare the clock in suspend() if it was active and re-prepare it in resume() to ensure the clock is properly disabled during system suspend, while maintaining the "always prepared" semantics while the system is active. The driver doesn't implement .attach() callback, hence it only checks for RPROC_RUNNING. Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier

remoteproc: mediatek: Break lock dependency to `prepare_lock`

2026-01-26T15:45:49Z

A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier

remoteproc: mtk_scp: Simplify with scoped for each OF child loop

2026-01-05T21:28:33Z

Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260102124827.64355-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mathieu Poirier

remoteproc: mediatek: Change the snprintf() checking

2025-11-10T17:40:44Z

The snprintf() calls here work but they have several minor style issues: 1) It uses ARRAY_SIZE() which is the number of elements in an array. Since were talking about char that works, but it's more common to use sizeof() which is the number of bytes. 2) The printf format is "%1d". The "1" ensures we always print at least 1 character but since numbers all have at least 1 digit this can be removed. 3) The kernel implementation of snprintf() cannot return negative error codes. Also these particular calls to snprintf() can't return zero and the code to handle that zero return is sort of questionable. 4) In the current kernel the only "core_id" we print is "0" but if it was more than 9 then the output would be truncated so GCC complains. Add an "a >= sizeof(scp_fw_file)" check for output which is too long. Signed-off-by: Dan Carpenter Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/aP8agyKj73bLZrTQ@stanley.mountain Signed-off-by: Mathieu Poirier

remoteproc: mtk_scp: Construct FW path if firmware-name not present

2025-10-20T15:16:11Z

After a reply on the mailing lists [1] it emerged that the DT property "firmware-name" should not be relied on because of possible issues with firmware versions. For MediaTek SCP, there has never been any firmware version vs driver version desync issue but, regardless, the firmwares are always using the same name and they're always located in a path with a specific pattern. Instead of unconditionally always relying on the firmware-name devicetree property to get a path to the SCP FW file, drivers should construct a name based on what firmware it knows and what hardware it is running on. In order to do that, add a `scp_get_default_fw_path()` function that constructs the path and filename based on two of the infos that the driver can get: 1. The compatible string with the highest priority (so, the first one at index 0); and 2. The type of SCP HW - single-core or multi-core. This means that the default firmware path is generated as: - Single core SCP: mediatek/(soc_model)/scp.img for example: mediatek/mt8183/scp.img; - Multi core SCP: mediatek/(soc_model)/scp_c(core_number).img for example: mediatek/mt8188/scp_c0.img for Core 0, and mediatek/mt8188/scp_c1.img for Core 1. Note that the generated firmware path is being used only if the "firmware-name" devicetree property is not present in the SCP node or in the SCP Core node(s). [1 - Reply regarding firmware-name property] Link: https://lore.kernel.org/all/7e8718b0-df78-44a6-a102-89529d6abcce@app.fastmail.com/ Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20251015084103.10737-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier

remoteproc: mtk_scp: Only populate devices for SCP cores

2024-12-16T16:31:33Z

When multi-core SCP support was added, the driver was made to populate platform devices for all the sub-nodes. This ended up adding platform devices for the rpmsg sub-nodes as well, which never actually get used, since rpmsg devices are registered through the rpmsg interface. Limit of_platform_populate() to just populating the SCP cores with a compatible string match list. Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") Cc: Tinghan Shen Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20241211072009.120511-1-wenst@chromium.org Signed-off-by: Mathieu Poirier

remoteproc: Switch back to struct platform_driver::remove()

2024-10-29T17:27:37Z

After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/remoteproc to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20241025131340.258233-2-u.kleine-koenig@baylibre.com Signed-off-by: Mathieu Poirier

remoteproc: mediatek: Increase MT8188/MT8195 SCP core0 DRAM size

2024-07-08T15:57:16Z

The current DRAM size is insufficient for the HEVC feature, which requires more memory for proper functionality. This change ensures the feature has the necessary resources. Signed-off-by: Jason Chen Reviewed-by: AngeloGioacchino Del Regno Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240703034409.698-1-Jason-ch.Chen@mediatek.com Signed-off-by: Mathieu Poirier

remoteproc: mediatek: Don't attempt to remap l1tcm memory if missing

2024-06-28T17:56:24Z

The current code doesn't check whether platform_get_resource_byname() succeeded to get the l1tcm memory, which is optional, before attempting to map it. This results in the following error message when it is missing: mtk-scp 10500000.scp: error -EINVAL: invalid resource (null) Add a check so that the remapping is only attempted if the memory region exists. This also allows to simplify the logic handling failure to remap, since a failure then is always a failure. Fixes: ca23ecfdbd44 ("remoteproc/mediatek: support L1TCM") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Tzung-Bi Shih Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240627-scp-invalid-resource-l1tcm-v1-1-7d221e6c495a@collabora.com Signed-off-by: Mathieu Poirier

remoteproc: mediatek: Zero out only remaining bytes of IPI buffer

2024-05-28T18:49:46Z

In scp_ipi_handler(), instead of zeroing out the entire shared buffer, which may be as large as 600 bytes, overwrite it with the received data, then zero out only the remaining bytes. Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240520112724.139945-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier