[PATCH v2] accel/ivpu: Improve IVPU_TEST_MODE_FW_TEST handling

[PATCH v2] accel/ivpu: Improve IVPU_TEST_MODE_FW_TEST handling

[Andrzej Kacprowski]

In IVPU_TEST_MODE_FW_TEST mode the driver triggers a firmware boot but
does not wait for boot completion. Because it never waits for the boot
to finish, it cannot send a message and expect a response from the
firmware.

Exit ivpu_boot() early in this mode, bypassing ivpu_hw_sched_init() and
the rest of the post-boot initialization. ivpu_hw_sched_init() was
sending a message that timed out and failed the boot sequence.

Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
---
 drivers/accel/ivpu/ivpu_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 8c1c87e69f91..538179dcd316 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -485,6 +485,9 @@ int ivpu_boot(struct ivpu_device *vdev)
 	ivpu_ipc_enable(vdev);
 
 	if (!ivpu_fw_is_warm_boot(vdev)) {
+		if (ivpu_test_mode & IVPU_TEST_MODE_FW_TEST)
+			return 0;
+
 		ret = ivpu_pm_dct_init(vdev);
 		if (ret)
 			goto err_disable_ipc;
-- 
2.43.0

Re: [PATCH v2] accel/ivpu: Improve IVPU_TEST_MODE_FW_TEST handling

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] accel/ivpu: PM runtime autosuspend loop in FW_TEST mode
--

commit e12f731149f041dc1d9f11e61a8bd4c155f14399
Author: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>

accel/ivpu: Improve IVPU_TEST_MODE_FW_TEST handling

This commit modifies ivpu_boot() to exit early when IVPU_TEST_MODE_FW_TEST
is enabled, bypassing post-boot initialization. This avoids sending an IPC
message that was timing out since the firmware boot is not fully waited for
in this mode.

> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
> index 0f215392d42de..fee1dde0b7467 100644
> --- a/drivers/accel/ivpu/ivpu_drv.c
> +++ b/drivers/accel/ivpu/ivpu_drv.c
> @@ -498,6 +498,9 @@ int ivpu_boot(struct ivpu_device *vdev)
>  	ivpu_ipc_enable(vdev);
>  
>  	if (!ivpu_fw_is_warm_boot(vdev)) {
> +		if (ivpu_test_mode & IVPU_TEST_MODE_FW_TEST)
> +			return 0;
> +

[Severity: High]
Does this early return shift the IPC timeout into the runtime PM autosuspend
path?

If driver probe succeeds because of this early return, PM runtime autosuspend
will be enabled. After the autosuspend delay, won't
ivpu_pm_runtime_suspend_cb() unconditionally attempt to send an IPC message?

drivers/accel/ivpu/ivpu_pm.c:ivpu_pm_runtime_suspend_cb() {
    ...
	ret_d0i3 = ivpu_jsm_pwr_d0i3_enter(vdev);
	if (ret_d0i3)
		ivpu_err(vdev, "Failed to prepare for d0i3: %d\n", ret_d0i3);
    ...
	if (!is_idle || ret_d0i3) {
		ivpu_err(vdev, "Forcing cold boot due to previous errors\n");
		atomic_inc(&vdev->pm->reset_counter);
		ivpu_dev_coredump(vdev);
		ivpu_pm_prepare_cold_boot(vdev);
	}
    ...
}

Since the firmware is unresponsive in IVPU_TEST_MODE_FW_TEST mode, this
IPC message will inevitably time out. Could this lead to an inescapable
background loop of timeouts, coredumps, and resets?

>  		ret = ivpu_pm_dct_init(vdev);
>  		if (ret)
>  			goto err_disable_ipc;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007161323.2737682-1-andrzej.kacprowski@linux.intel.com?part=1