[PATCH] accel/ivpu: Wait for CDYN de-assertion during power down sequence

[PATCH] accel/ivpu: Wait for CDYN de-assertion during power down sequence

[Karol Wachowski]

During power down, pending DVFS operations may still be in progress
when the NPU reset is asserted after CDYN=0 is set. Since the READY
bit may already be deasserted at this point, checking only the READY
bit is insufficient to ensure all transactions have completed.

Add an explicit check for CDYN de-assertion after the READY bit check
to guarantee no outstanding transactions remain before proceeding.

Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
---
 drivers/accel/ivpu/ivpu_hw_btrs.c         | 16 ++++++++++++++++
 drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/accel/ivpu/ivpu_hw_btrs.c b/drivers/accel/ivpu/ivpu_hw_btrs.c
index aa33f562d29c..2662ef364c22 100644
--- a/drivers/accel/ivpu/ivpu_hw_btrs.c
+++ b/drivers/accel/ivpu/ivpu_hw_btrs.c
@@ -321,6 +321,14 @@ static int wait_for_pll_lock(struct ivpu_device *vdev, bool enable)
 	return REGB_POLL_FLD(VPU_HW_BTRS_MTL_PLL_STATUS, LOCK, exp_val, PLL_TIMEOUT_US);
 }
 
+static int wait_for_cdyn_deassert(struct ivpu_device *vdev)
+{
+	if (ivpu_hw_btrs_gen(vdev) == IVPU_HW_BTRS_MTL)
+		return 0;
+
+	return REGB_POLL_FLD(VPU_HW_BTRS_LNL_CDYN, CDYN, 0, PLL_TIMEOUT_US);
+}
+
 int ivpu_hw_btrs_wp_drive(struct ivpu_device *vdev, bool enable)
 {
 	struct wp_request wp;
@@ -354,6 +362,14 @@ int ivpu_hw_btrs_wp_drive(struct ivpu_device *vdev, bool enable)
 		return ret;
 	}
 
+	if (!enable) {
+		ret = wait_for_cdyn_deassert(vdev);
+		if (ret) {
+			ivpu_err(vdev, "Timed out waiting for CDYN deassert\n");
+			return ret;
+		}
+	}
+
 	return 0;
 }
 
diff --git a/drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h b/drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h
index fff2ef2cada6..a81a9ba540fa 100644
--- a/drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h
+++ b/drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h
@@ -74,6 +74,9 @@
 #define VPU_HW_BTRS_LNL_PLL_FREQ				0x00000148u
 #define VPU_HW_BTRS_LNL_PLL_FREQ_RATIO_MASK			GENMASK(15, 0)
 
+#define VPU_HW_BTRS_LNL_CDYN					0x0000014cu
+#define VPU_HW_BTRS_LNL_CDYN_CDYN_MASK				GENMASK(15, 0)
+
 #define VPU_HW_BTRS_LNL_TILE_FUSE				0x00000150u
 #define VPU_HW_BTRS_LNL_TILE_FUSE_VALID_MASK			BIT_MASK(0)
 #define VPU_HW_BTRS_LNL_TILE_FUSE_CONFIG_MASK			GENMASK(6, 1)
-- 
2.43.0

Re: [PATCH] accel/ivpu: Wait for CDYN de-assertion during power down sequence

[Jeff Hugo]

On 10/28/2025 1:06 AM, Karol Wachowski wrote:
> During power down, pending DVFS operations may still be in progress
> when the NPU reset is asserted after CDYN=0 is set. Since the READY
> bit may already be deasserted at this point, checking only the READY
> bit is insufficient to ensure all transactions have completed.
> 
> Add an explicit check for CDYN de-assertion after the READY bit check
> to guarantee no outstanding transactions remain before proceeding.

Is it worthwhile to mention what can break if transactions are pending 
while we proceed? Is there something that the user will see?

I'm guessing that proceeding with active transactions is bad, but its 
unclear to me if this is just a best practice, or actually fixes some 
kind of issue that will actually impact the user.  If there is actual 
user impact that this addresses, should we consider a fixes tag?

-Jeff

Re: [PATCH] accel/ivpu: Wait for CDYN de-assertion during power down sequence

[Karol Wachowski]

On 10/29/2025 4:47 PM, Jeff Hugo wrote:
> On 10/28/2025 1:06 AM, Karol Wachowski wrote:
>> During power down, pending DVFS operations may still be in progress
>> when the NPU reset is asserted after CDYN=0 is set. Since the READY
>> bit may already be deasserted at this point, checking only the READY
>> bit is insufficient to ensure all transactions have completed.
>>
>> Add an explicit check for CDYN de-assertion after the READY bit check
>> to guarantee no outstanding transactions remain before proceeding.
>
> Is it worthwhile to mention what can break if transactions are pending
> while we proceed? Is there something that the user will see?
>
> I'm guessing that proceeding with active transactions is bad, but its
> unclear to me if this is just a best practice, or actually fixes some
> kind of issue that will actually impact the user.  If there is actual
> user impact that this addresses, should we consider a fixes tag?
>
> -Jeff 
Hi
Jeff,                                                                                                                                           

This is primarily a best practice to avoid potential issues on NPU6,
where pending transactions can cause issues with power down transition. 
While it doesn't fix user-visible bugs on existing platforms, it ensures
unified power down sequence across all platforms that support this
register, making the code clearer than conditional handling just for NPU6.

You're right about the Fixes tag, since NPU6 support is already
upstream, I'll add one.

-Karol