From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Dikshita Agarwal <quic_dikshita@quicinc.com>,
Vikash Garodia <quic_vgarodia@quicinc.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Neil Armstrong <neil.armstrong@linaro.org>
Subject: Re: [PATCH v2] media: iris: vpu3x: Add MNoC low power handshake during hardware power-off
Date: Wed, 13 Aug 2025 11:42:44 +0200 [thread overview]
Message-ID: <b58b583f-8910-4b93-86d8-bbfc865bce3a@oss.qualcomm.com> (raw)
In-Reply-To: <20250813-sm8650-power-sequence-fix-v2-1-9ed0fc2c45cb@quicinc.com>
On 8/13/25 9:53 AM, Dikshita Agarwal wrote:
> Add the missing write to AON_WRAPPER_MVP_NOC_LPI_CONTROL before
> reading the LPI status register. Introduce a handshake loop to ensure
> MNoC enters low power mode reliably during VPU3 hardware power-off with
> timeout handling.
>
> Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
> ---
> Changes in v2:
> - Restructured loop for readability (Jorge)
> - Used defines for bits (Konrad, Jorge)
> - Used udelay for short waits (Konrad)
> - Link to v1: https://lore.kernel.org/r/20250812-sm8650-power-sequence-fix-v1-1-a51e7f99c56c@quicinc.com
>
> Please note that I have not added "Tested-by" tag from Neil in this update,
> as the NOC handshake loop has been restructured.
> ---
> drivers/media/platform/qcom/iris/iris_vpu3x.c | 30 +++++++++++++++++++++++++--
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> index 9b7c9a1495ee2f51c60b1142b2ed4680ff798f0a..a621878f02f7196de29c9e290a6c5acea34eba8c 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> @@ -19,6 +19,9 @@
> #define WRAPPER_IRIS_CPU_NOC_LPI_CONTROL (WRAPPER_BASE_OFFS + 0x5C)
> #define REQ_POWER_DOWN_PREP BIT(0)
> #define WRAPPER_IRIS_CPU_NOC_LPI_STATUS (WRAPPER_BASE_OFFS + 0x60)
> +#define NOC_LPI_STATUS_DONE BIT(0) /* Indicates the NOC handshake is complete */
> +#define NOC_LPI_STATUS_DENY BIT(1) /* Indicates the NOC handshake is denied */
> +#define NOC_LPI_STATUS_ACTIVE BIT(2) /* Indicates the NOC is active */
> #define WRAPPER_CORE_CLOCK_CONFIG (WRAPPER_BASE_OFFS + 0x88)
> #define CORE_CLK_RUN 0x0
>
> @@ -109,7 +112,9 @@ static void iris_vpu3_power_off_hardware(struct iris_core *core)
>
> static void iris_vpu33_power_off_hardware(struct iris_core *core)
> {
> + bool handshake_done = false, handshake_busy = false;
> u32 reg_val = 0, value, i;
> + u32 count = 0;
> int ret;
>
> if (iris_vpu3x_hw_power_collapsed(core))
> @@ -128,13 +133,34 @@ static void iris_vpu33_power_off_hardware(struct iris_core *core)
> goto disable_power;
> }
>
> + /* set MNoC to low power */
> + writel(REQ_POWER_DOWN_PREP, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
> +
> + do {
> + value = readl(core->reg_base + AON_WRAPPER_MVP_NOC_LPI_STATUS);
> +
> + handshake_done = value & NOC_LPI_STATUS_DONE;
> + handshake_busy = value & (NOC_LPI_STATUS_DENY | NOC_LPI_STATUS_ACTIVE);
> +
> + if (handshake_done || !handshake_busy)
> + break;
> +
> + writel(0, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
I'm still concerned about the lack of readback here, since the writes aren't
guaranteed to have a delay between them (from the VPU's perspective)
> +
> + udelay(15);
> +
> + writel(REQ_POWER_DOWN_PREP, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
> + } while (++count < 1000);
> +
> + if (!handshake_done && handshake_busy)
> + dev_err(core->dev, "LPI handshake timeout\n");
> +
> ret = readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_LPI_STATUS,
> reg_val, reg_val & BIT(0), 200, 2000);
> if (ret)
> goto disable_power;
>
> - /* set MNoC to low power, set PD_NOC_QREQ (bit 0) */
> - writel(BIT(0), core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
> + writel(0, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
>
> writel(CORE_BRIDGE_SW_RESET | CORE_BRIDGE_HW_RESET_DISABLE,
> core->reg_base + CPU_CS_AHB_BRIDGE_SYNC_RESET);
Just for context, is my understanding correct that we skip these writes
when the handshake fails, because they cut power to the bus (which just
failed to enter low power mode, meaning there's likely some data flowing
through it)?
Konrad
next prev parent reply other threads:[~2025-08-13 9:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 7:53 Dikshita Agarwal
2025-08-13 8:26 ` Neil Armstrong
2025-08-13 9:42 ` Konrad Dybcio [this message]
2025-08-13 20:20 ` Bryan O'Donoghue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b58b583f-8910-4b93-86d8-bbfc865bce3a@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=bryan.odonoghue@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_dikshita@quicinc.com \
--cc=quic_vgarodia@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®