Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
To: Bryan O'Donoghue <bod@kernel.org>,
	Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Subject: Re: [PATCH v3 6/6] media: iris: Introduce vpu ops for vpu4 with necessary hooks
Date: Tue, 9 Dec 2025 14:32:29 +0530	[thread overview]
Message-ID: <157a3960-0110-4026-8ef5-e3378c8db693@oss.qualcomm.com> (raw)
In-Reply-To: <5a5908db-aa96-4cfa-a908-d393dd2d79c0@kernel.org>


On 12/7/2025 4:34 AM, Bryan O'Donoghue wrote:
> On 07/11/2025 09:49, Vikash Garodia wrote:
>> Add power sequence for vpu4 by reusing from previous generation wherever
>> possible. Hook up vpu4 op with vpu4 specific implemtation or resue from
>> earlier generation wherever feasible, like clock calculation in this
>> case.
>>
>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
> 
>> +static void iris_vpu4x_power_off_hardware(struct iris_core *core)
>> +{
>> +    u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
>> +    bool handshake_done, handshake_busy;
>> +    u32 value, count = 0;
>> +
>> +    iris_vpu4x_genpd_set_hwmode(core, false, efuse_value);
>> +
>> +    if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
>> +        iris_vpu4x_power_off_apv(core);
>> +
>> +    value = readl(core->reg_base + WRAPPER_CORE_POWER_STATUS);
>> +
>> +    if (!(value & CORE_PWR_ON))
>> +        goto disable_clocks_and_power;
>> +
>> +    value = readl(core->reg_base + WRAPPER_CORE_CLOCK_CONFIG);
>> +
>> +    if (value & CORE_CLK_HALT)
>> +        writel(0x0, core->reg_base + WRAPPER_CORE_CLOCK_CONFIG);
>> +
>> +    readl_poll_timeout(core->reg_base + VCODEC_SS_IDLE_STATUSN, value,
>> +               value & VPU_IDLE_BITS, 2000, 20000);
>> +
>> +    do {
>> +        writel(REQ_POWER_DOWN_PREP, core->reg_base + 
>> AON_WRAPPER_MVP_NOC_LPI_CONTROL);
>> +        usleep_range(10, 20);
>> +        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(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
>> +        usleep_range(10, 20);
>> +
>> +    } while (++count < 1000);
>> +
>> +    if (!handshake_done && handshake_busy)
>> +        dev_err(core->dev, "LPI handshake timeout\n");
>> +
>> +    writel(MVP_NOC_RESET_REQ_MASK, core->reg_base + 
>> AON_WRAPPER_MVP_NOC_RESET_REQ);
>> +    readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_RESET_ACK,
>> +               value, value == MVP_NOC_RESET_REQ_MASK, 200, 2000);
> 
> I realise it replicates what we already have upstream but...
> 
> if (!handshake_done && etc) is true then how does it make sense to 
> continue on with the routine at all ?

Yes, LPI (low power..) is an optional "good to have" routine before 
resetting the NOC and powering down.

> 
> We would expect the poll_timeout to timeout .. ?

during good times, it would not, and when it times out, it is always 
good to force reset the NOC before the GDSCs/clocks are turned off.

> 
> If the documentation states loop 1000 times trying this then does it 
> also say continue to try to power things off if that 1000 retries fails ?

Thats correct.

> 
> I realise its a nit-pick but the logic seems a bit fluffy here. Could 
> you tidy it up ?
> 
> Also now that I look at it - vpu2 and vpu3 both trap the timeout and 
> jump to some kind of cleanup routine.
> 
> goto disable_power;
> 
> Why is that logic not being followed here ?
> 
>> +    writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_SYNCRST);
>> +    writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_REQ);
>> +    readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_RESET_ACK,
>> +               value, value == 0x0, 200, 2000);
> 
> Feels like there is little point in having a poll timeout if we throw 
> away a timeout result code..
> 
> Not sure why you're changing up the logic from previous versions ?
> 

Given the NOC reset/ack is recommended, even if LPI times out, we can 
move to disable_power i.e power off clocks/GDSCs, once NOC reset times out.

Regards,
Vikash

  reply	other threads:[~2025-12-09  9:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07  9:49 [PATCH v3 0/6] media: iris: prepare support for video codecs on Qcom vpu4 platform Vikash Garodia
2025-11-07  9:49 ` [PATCH v3 1/6] media: iris: Add support for multiple clock sources Vikash Garodia
2025-11-07  9:49 ` [PATCH v3 2/6] media: iris: Add support for multiple TZ content protection(CP) configs Vikash Garodia
2025-11-07  9:49 ` [PATCH v3 3/6] media: iris: Introduce buffer size calculations for vpu4 Vikash Garodia
2025-11-07  9:49 ` [PATCH v3 4/6] media: iris: Move vpu register defines to common header file Vikash Garodia
2025-11-07  9:49 ` [PATCH v3 5/6] media: iris: Move vpu35 specific api to common to use for vpu4 Vikash Garodia
2025-11-07  9:49 ` [PATCH v3 6/6] media: iris: Introduce vpu ops for vpu4 with necessary hooks Vikash Garodia
2025-12-06 23:04   ` Bryan O'Donoghue
2025-12-09  9:02     ` Vikash Garodia [this message]
2025-11-11 10:38 ` [PATCH v3 0/6] media: iris: prepare support for video codecs on Qcom vpu4 platform Dmitry Baryshkov
2025-11-11 12:43   ` Vikash Garodia
2025-11-11 13:39     ` Dmitry Baryshkov
2025-11-12  5:09       ` Vikash Garodia
2025-11-19  9:08         ` Dmitry Baryshkov
2025-11-20  9:49         ` Bryan O'Donoghue
2025-11-21 11:03           ` Vikash Garodia

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=157a3960-0110-4026-8ef5-e3378c8db693@oss.qualcomm.com \
    --to=vikash.garodia@oss.qualcomm.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=bod@kernel.org \
    --cc=busanna.reddy@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dikshita.agarwal@oss.qualcomm.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=krzk+dt@kernel.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=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    /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