From: Steven Price <steven.price@arm.com>
To: Karunika Choo <karunika.choo@arm.com>, dri-devel@lists.freedesktop.org
Cc: nd@arm.com, Boris Brezillon <boris.brezillon@collabora.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 06/10] drm/panthor: Implement L2 power on/off via PWR_CONTROL
Date: Fri, 24 Oct 2025 10:43:08 +0100 [thread overview]
Message-ID: <e74ec0b1-4975-4fd5-bb1a-4839c45987f7@arm.com> (raw)
In-Reply-To: <a9cd1999-12d9-41cf-aef6-a6c3f1f23e4c@arm.com>
On 23/10/2025 23:16, Karunika Choo wrote:
> On 20/10/2025 11:50, Steven Price wrote:
>> On 14/10/2025 10:43, Karunika Choo wrote:
>>> This patch adds common helpers to issue power commands, poll
>>> transitions, and validate domain state, then wires them into the L2
>>> on/off paths.
>>>
>>> The L2 power-on sequence now delegates control of the SHADER and TILER
>>> domains to the MCU when allowed, while the L2 itself is never delegated.
>>> On power-off, dependent domains beneath the L2 are checked, and if
>>> necessary, retracted and powered down to maintain proper domain
>>> ordering.
>>>
>>> Signed-off-by: Karunika Choo <karunika.choo@arm.com>
>>> ---
[...]
>>> + u64 domain_ready = gpu_read64(ptdev, get_domain_ready_reg(child_domain));
>>> +
>>> + if (domain_ready && (pwr_status & PWR_STATUS_DOMAIN_DELEGATED(child_domain))) {
>>> + drm_warn(&ptdev->base,
>>> + "L2 power off: Delegated %s domain not powered down by MCU",
>>> + get_domain_name(child_domain));
>>> + ret = retract_domain(ptdev, child_domain);
>>> + if (ret) {
>>> + drm_err(&ptdev->base, "Failed to retract %s domain",
>>> + get_domain_name(child_domain));
>>> + panthor_pwr_info_show(ptdev);
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + ret = panthor_pwr_domain_power_off(ptdev, child_domain, domain_ready,
>>> + PWR_TRANSITION_TIMEOUT_US);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + return panthor_pwr_domain_power_off(ptdev, PWR_COMMAND_DOMAIN_L2,
>>> + ptdev->gpu_info.l2_present,
>>> + PWR_TRANSITION_TIMEOUT_US);
>>
>> Does this implicitly 'retract' the shader/tiler power domains? If so I
>> think it's worth a comment. Otherwise it looks like we don't actually
>> know the status of whether the shader/tiler power domains are retracted
>> or not.
>>
>
> panthor_pwr_l2_power_off() will only retract the shader/tiler domains if
> they have not been powered down by the MCU. In cases where the MCU did
> power down these child domains, delegate_domain() will exit early as
> they would already be delegated. I understand the ambiguity here,
> hopefully it is somewhat acceptable.
So my question was really how does the driver know whether the domains
are delegated or not when this function returns?
I couldn't quite get my head around whether turning the L2 power domain
off would implicitly 'retract' the shader/tiler power domains -
obviously it forces them off which means the MCU doesn't have control.
So retracting would make sense, but I couldn't see anything in the spec.
It would be good to have a comment explaining what the expected state is
after this function (panthor_pwr_l2_power_off) returns. Is it unknown
whether the shader/tiler are retracted, or is there something in the
hardware which does this automatically so we know but don't have to
manually retract? Presumably if we end up fully powering down the GPU
that must effectively retract all domains (the GPU hardware is reset so
it goes back to reset conditions).
Sorry, it's a bit of a basic question but the spec is somewhat unhelpful
on this point! (Or at least I haven't found a relevant statement).
Thanks,
Steve
next prev parent reply other threads:[~2025-10-24 9:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 9:43 [PATCH v1 00/10] drm/panthor: Add support for Mali-G1 GPUs Karunika Choo
2025-10-14 9:43 ` [PATCH v1 01/10] drm/panthor: Factor out GPU_ID register read into separate function Karunika Choo
2025-10-20 8:57 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 02/10] drm/panthor: Add arch-specific panthor_hw binding Karunika Choo
2025-10-20 8:57 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 03/10] drm/panthor: Introduce framework for architecture-specific features Karunika Choo
2025-10-20 9:06 ` Steven Price
2025-10-24 6:43 ` Boris Brezillon
2025-10-24 9:26 ` Karunika Choo
2025-10-24 10:49 ` Boris Brezillon
2025-10-14 9:43 ` [PATCH v1 04/10] drm/panthor: Add architecture-specific function operations Karunika Choo
2025-10-20 9:10 ` Steven Price
2025-10-23 20:59 ` Karunika Choo
2025-10-24 9:34 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 05/10] drm/panthor: Introduce panthor_pwr API and power control framework Karunika Choo
2025-10-20 9:40 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 06/10] drm/panthor: Implement L2 power on/off via PWR_CONTROL Karunika Choo
2025-10-15 5:01 ` kernel test robot
2025-10-16 8:29 ` kernel test robot
2025-10-20 10:50 ` Steven Price
2025-10-23 22:16 ` Karunika Choo
2025-10-24 9:43 ` Steven Price [this message]
2025-10-24 11:51 ` Karunika Choo
2025-10-24 13:02 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 07/10] drm/panthor: Implement soft and fast reset " Karunika Choo
2025-10-20 11:24 ` Steven Price
2025-10-23 22:31 ` Karunika Choo
2025-10-14 9:43 ` [PATCH v1 08/10] drm/panthor: Support GLB_REQ.STATE field for Mali-G1 GPUs Karunika Choo
2025-10-20 11:39 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 09/10] drm/panthor: Support 64-bit endpoint_req register for Mali-G1 Karunika Choo
2025-10-20 13:12 ` Steven Price
2025-10-14 9:43 ` [PATCH v1 10/10] drm/panthor: Add support for Mali-G1 GPUs Karunika Choo
2025-10-20 13:18 ` Steven Price
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=e74ec0b1-4975-4fd5-bb1a-4839c45987f7@arm.com \
--to=steven.price@arm.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=karunika.choo@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nd@arm.com \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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®