mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 04/10] drm/panthor: Add architecture-specific function operations
Date: Fri, 24 Oct 2025 10:34:19 +0100	[thread overview]
Message-ID: <79f23e43-c345-4277-8b05-97d7dacbc1d4@arm.com> (raw)
In-Reply-To: <6a469d39-0136-4f8c-a171-7b98db9eed10@arm.com>

On 23/10/2025 21:59, Karunika Choo wrote:
> On 20/10/2025 10:10, Steven Price wrote:
>> On 14/10/2025 10:43, Karunika Choo wrote:
>>> Introduce architecture-specific function pointers to support
>>> architecture-dependent behaviours. This patch adds the following
>>> function pointers and updates their usage accordingly:
>>>
>>> - soft_reset
>>> - l2_power_on
>>> - l2_power_off
>>>
>>> Signed-off-by: Karunika Choo <karunika.choo@arm.com>
>>> ---
>>>  drivers/gpu/drm/panthor/panthor_device.c |  4 ++--
>>>  drivers/gpu/drm/panthor/panthor_fw.c     |  5 +++--
>>>  drivers/gpu/drm/panthor/panthor_gpu.c    | 13 ++++++++++---
>>>  drivers/gpu/drm/panthor/panthor_gpu.h    |  1 +
>>>  drivers/gpu/drm/panthor/panthor_hw.c     |  9 ++++++++-
>>>  drivers/gpu/drm/panthor/panthor_hw.h     | 23 +++++++++++++++++++++++
>>>  6 files changed, 47 insertions(+), 8 deletions(-)
>>>
>> <snip>
>>> diff --git a/drivers/gpu/drm/panthor/panthor_hw.h b/drivers/gpu/drm/panthor/panthor_hw.h
>>> index 7a191e76aeec..5a4e4aad9099 100644
>>> --- a/drivers/gpu/drm/panthor/panthor_hw.h
>>> +++ b/drivers/gpu/drm/panthor/panthor_hw.h
>>> @@ -20,12 +20,35 @@ enum panthor_hw_feature {
>>>  };
>>>  
>>>  
>>> +/**
>>> + * struct panthor_hw_ops - HW operations that are specific to a GPU
>>> + */
>>> +struct panthor_hw_ops {
>>> +	/** @soft_reset: Soft reset function pointer */
>>> +	int (*soft_reset)(struct panthor_device *ptdev);
>>> +#define panthor_hw_soft_reset(__ptdev) \
>>> +	((__ptdev)->hw->ops.soft_reset ? (__ptdev)->hw->ops.soft_reset(__ptdev) : 0)
>>> +
>>> +	/** @l2_power_off: L2 power off function pointer */
>>> +	int (*l2_power_off)(struct panthor_device *ptdev);
>>> +#define panthor_hw_l2_power_off(__ptdev) \
>>> +	((__ptdev)->hw->ops.l2_power_off ? (__ptdev)->hw->ops.l2_power_off(__ptdev) : 0)
>>> +
>>> +	/** @l2_power_on: L2 power on function pointer */
>>> +	int (*l2_power_on)(struct panthor_device *ptdev);
>>> +#define panthor_hw_l2_power_on(__ptdev) \
>>> +	((__ptdev)->hw->ops.l2_power_on ? (__ptdev)->hw->ops.l2_power_on(__ptdev) : 0)
>>> +};
>>
>> Minor comments:
>>
>>  * You are defining these to have a return value, but you haven't
>> updated any of the call-sites to deal with a failure (the return value
>> is ignored). This is actually an existing problem, but AFAICT the new
>> _pwr_ versions have more error codes which are simply getting thrown away.
>>
> 
> Hi Steve,
> 
> While I agree that there is an existing problem, I'd argue that most of
> these are called from void functions where there really isn't much
> benefit in handling the return value apart from printing a "whoops"
> (which the called functions themselves mostly already do) and
> continuing. In fact, in the one place it isn't called from a void
> function, we do handle the return value.
> 
> Still, I do think that it is an issue, biggest of which probably is the
> soft reset work. Perhaps we can revisit this topic when we want to have
> another go at the soft reset handling in the future?

I agree it's not making things worse. But if we're adding another
backend it's worth stopping to think about the API. Does it make sense
to return an error code if the call sites cannot handle the error?
Should any of these function be void return? Specifically the power off
call as I'm not sure what the caller can usefully do if that fails.

I'm happy for the soft reset to be left for now, it would be good to
handle errors properly in that path but it's an orthogonal problem to
this series.

Thanks,
Steve

>>  * Is there a good reason why we need to support these functions being
>> NULL? It seems unlikely to be useful, and TBH I'd prefer to just assign
>> a dummy (empty) function in those cases.
>>
>>  * A static inline function would be neater and would avoid any
>> potential issues from the multiple evaluation of __ptdev.
>>
>> Thanks,
>> Steve
>>
> 
> Thanks for pointing this out + the suggestion, I will change this in v2.
> 
> Kind regards,
> Karunika
> 
>>> +
>>>  /**
>>>   * struct panthor_hw - GPU specific register mapping and functions
>>>   */
>>>  struct panthor_hw {
>>>  	/** @features: Bitmap containing panthor_hw_feature */
>>>  	DECLARE_BITMAP(features, PANTHOR_HW_FEATURES_END);
>>> +
>>> +	/** @ops: Panthor HW specific operations */
>>> +	struct panthor_hw_ops ops;
>>>  };
>>>  
>>>  int panthor_hw_init(struct panthor_device *ptdev);
>>
> 


  reply	other threads:[~2025-10-24  9:34 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 [this message]
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
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=79f23e43-c345-4277-8b05-97d7dacbc1d4@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®