mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Karunika Choo <karunika.choo@arm.com>
To: Steven Price <steven.price@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 07/10] drm/panthor: Implement soft and fast reset via PWR_CONTROL
Date: Thu, 23 Oct 2025 23:31:26 +0100	[thread overview]
Message-ID: <42dd4e0f-0ac8-411d-bfdc-754fe3e8ab67@arm.com> (raw)
In-Reply-To: <7be294e2-e6fe-4c47-8bf3-507443e3b1d5@arm.com>

On 20/10/2025 12:24, Steven Price wrote:
> On 14/10/2025 10:43, Karunika Choo wrote:
>> Add helpers to issue reset commands through the PWR_CONTROL interface
>> and wait for reset completion using IRQ signaling. This enables support
>> for both RESET_SOFT and RESET_FAST operations with timeout handling and
>> status verification.
>>
>> Signed-off-by: Karunika Choo <karunika.choo@arm.com>
>> ---
>>  drivers/gpu/drm/panthor/panthor_pwr.c | 62 ++++++++++++++++++++++++++-
>>  drivers/gpu/drm/panthor/panthor_pwr.h |  2 +
>>  2 files changed, 63 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/panthor/panthor_pwr.c b/drivers/gpu/drm/panthor/panthor_pwr.c
>> index 594181aba847..ecb278824d06 100644
>> --- a/drivers/gpu/drm/panthor/panthor_pwr.c
>> +++ b/drivers/gpu/drm/panthor/panthor_pwr.c
>> @@ -3,6 +3,7 @@
>>  
>>  #include <linux/platform_device.h>
>>  #include <linux/interrupt.h>
>> +#include <linux/cleanup.h>
>>  #include <linux/iopoll.h>
>>  #include <linux/wait.h>
>>  
>> @@ -31,6 +32,8 @@
>>  
>>  #define PWR_RETRACT_TIMEOUT_US		2000
>>  
>> +#define PWR_RESET_TIMEOUT_MS		500
>> +
>>  /**
>>   * struct panthor_pwr - PWR_CONTROL block management data.
>>   */
>> @@ -80,6 +83,42 @@ static void panthor_pwr_write_command(struct panthor_device *ptdev, u32 command,
>>  	gpu_write(ptdev, PWR_COMMAND, command);
>>  }
>>  
>> +static bool reset_irq_raised(struct panthor_device *ptdev)
>> +{
>> +	return gpu_read(ptdev, PWR_INT_RAWSTAT) & PWR_IRQ_RESET_COMPLETED;
>> +}
>> +
>> +static bool reset_completed(struct panthor_device *ptdev)
>> +{
>> +	return (ptdev->pwr->pending_reqs & PWR_IRQ_RESET_COMPLETED);
>> +}
>> +
>> +static int panthor_pwr_reset(struct panthor_device *ptdev, u32 reset_cmd)
>> +{
>> +	scoped_guard(spinlock_irqsave, &ptdev->pwr->reqs_lock) {
>> +		if (!drm_WARN_ON(&ptdev->base, !reset_completed(ptdev))) {
>> +			ptdev->pwr->pending_reqs |= PWR_IRQ_RESET_COMPLETED;
>> +			gpu_write(ptdev, PWR_INT_CLEAR, PWR_IRQ_RESET_COMPLETED);
>> +			panthor_pwr_write_command(ptdev, reset_cmd, 0);
>> +		}
> 
> This would be easier to read as:
> 
> if (reset_completed(ptdev)) {
> 	....
> } else {
> 	drm_WARN(&ptdev->base, 1, "Hey, we're already resetting?");
> }
> 
> [Message modified to taste ;) ]
> 
> I'm also wondering if things would be easier to read if you switched
> from reset_completed() to reset_pending(). Certainly here it's the
> 'pending' test you are trying to do.
> 

Oops. I might have made a mistake with the logic. Let me fix this in v2.
Thanks for spotting it

>> +	}
>> +
>> +	if (!wait_event_timeout(ptdev->pwr->reqs_acked, reset_completed(ptdev),
>> +				msecs_to_jiffies(PWR_RESET_TIMEOUT_MS))) {
>> +		guard(spinlock_irqsave)(&ptdev->pwr->reqs_lock);
>> +
>> +		if (!reset_completed(ptdev) && !reset_irq_raised(ptdev)) {
>> +			drm_err(&ptdev->base, "RESET_%s timed out",
>> +				reset_cmd == PWR_COMMAND_RESET_SOFT ? "SOFT" : "FAST");
>> +			return -ETIMEDOUT;
>> +		}
>> +
>> +		ptdev->pwr->pending_reqs &= ~PWR_IRQ_RESET_COMPLETED;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>  static const char *get_domain_name(u8 domain)
>>  {
>>  	switch (domain) {
>> @@ -407,9 +446,30 @@ int panthor_pwr_init(struct panthor_device *ptdev)
>>  	return 0;
>>  }
>>  
>> +int panthor_pwr_reset_fast(struct panthor_device *ptdev)
>> +{
>> +	if (!ptdev->pwr)
>> +		return 0;
>> +
>> +	if (!(panthor_pwr_read_status(ptdev) & PWR_STATUS_ALLOW_FAST_RESET)) {
>> +		drm_err(&ptdev->base, "RESET_SOFT not allowed");
> 
> Copy/paste mistake on the error message.
> 
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	return panthor_pwr_reset(ptdev, PWR_COMMAND_RESET_FAST);
>> +}
> 
> I can't actually find a caller of this function within the series.
> 

I will remove the fast reset option entirely in v2 as there is currently
no use for this function. We can reimplement this in the future, should
it be something that is desired.

>> +
>>  int panthor_pwr_reset_soft(struct panthor_device *ptdev)
>>  {
>> -	return 0;
>> +	if (!ptdev->pwr)
>> +		return 0;
> 
> When would this happen? Is this not a programming error?
> 

I will remove this. Thanks.

Kind regards,
Karunika Choo

> Thanks,
> Steve
> 
>> +
>> +	if (!(panthor_pwr_read_status(ptdev) & PWR_STATUS_ALLOW_SOFT_RESET)) {
>> +		drm_err(&ptdev->base, "RESET_SOFT not allowed");
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	return panthor_pwr_reset(ptdev, PWR_COMMAND_RESET_SOFT);
>>  }
>>  
>>  int panthor_pwr_l2_power_off(struct panthor_device *ptdev)
>> diff --git a/drivers/gpu/drm/panthor/panthor_pwr.h b/drivers/gpu/drm/panthor/panthor_pwr.h
>> index a4042c125448..2301c26dab86 100644
>> --- a/drivers/gpu/drm/panthor/panthor_pwr.h
>> +++ b/drivers/gpu/drm/panthor/panthor_pwr.h
>> @@ -10,6 +10,8 @@ void panthor_pwr_unplug(struct panthor_device *ptdev);
>>  
>>  int panthor_pwr_init(struct panthor_device *ptdev);
>>  
>> +int panthor_pwr_reset_fast(struct panthor_device *ptdev);
>> +
>>  int panthor_pwr_reset_soft(struct panthor_device *ptdev);
>>  
>>  int panthor_pwr_l2_power_on(struct panthor_device *ptdev);
> 


  reply	other threads:[~2025-10-23 22:32 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
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 [this message]
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=42dd4e0f-0ac8-411d-bfdc-754fe3e8ab67@arm.com \
    --to=karunika.choo@arm.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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=steven.price@arm.com \
    --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®