From: Boris Brezillon <boris.brezillon@collabora.com>
To: Karunika Choo <karunika.choo@arm.com>
Cc: dri-devel@lists.freedesktop.org, nd@arm.com,
Steven Price <steven.price@arm.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 v2 5/9] drm/panthor: Make getting GPU model name simple and extensible
Date: Thu, 10 Apr 2025 15:37:29 +0200 [thread overview]
Message-ID: <20250410153729.1fb0444c@collabora.com> (raw)
In-Reply-To: <a661ba42-9393-4070-9e52-dd19df2d6880@arm.com>
On Thu, 10 Apr 2025 14:20:59 +0100
Karunika Choo <karunika.choo@arm.com> wrote:
> On 21/03/2025 08:02, Boris Brezillon wrote:
> > On Thu, 20 Mar 2025 11:17:37 +0000
> > Karunika Choo <karunika.choo@arm.com> wrote:
> >
> >> This patch replaces the previous panthor_model structure with a simple
> >> switch case based on the product_id, which is in the format of:
> >> ((arch_major << 24) | product_major)
> >>
> >> This not only simplifies the comparison, but also allows extending the
> >> function to accommodate naming differences based on GPU features.
> >>
> >> Signed-off-by: Karunika Choo <karunika.choo@arm.com>
> >> ---
> >> drivers/gpu/drm/panthor/panthor_hw.c | 63 +++++++-------------------
> >> drivers/gpu/drm/panthor/panthor_regs.h | 1 +
> >> 2 files changed, 18 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/panthor/panthor_hw.c b/drivers/gpu/drm/panthor/panthor_hw.c
> >> index 4cc4b0d5382c..12183c04cd21 100644
> >> --- a/drivers/gpu/drm/panthor/panthor_hw.c
> >> +++ b/drivers/gpu/drm/panthor/panthor_hw.c
> >> @@ -5,40 +5,6 @@
> >> #include "panthor_hw.h"
> >> #include "panthor_regs.h"
> >>
> >> -/**
> >> - * struct panthor_model - GPU model description
> >> - */
> >> -struct panthor_model {
> >> - /** @name: Model name. */
> >> - const char *name;
> >> -
> >> - /** @arch_major: Major version number of architecture. */
> >> - u8 arch_major;
> >> -
> >> - /** @product_major: Major version number of product. */
> >> - u8 product_major;
> >> -};
> >> -
> >> -/**
> >> - * GPU_MODEL() - Define a GPU model. A GPU product can be uniquely identified
> >> - * by a combination of the major architecture version and the major product
> >> - * version.
> >> - * @_name: Name for the GPU model.
> >> - * @_arch_major: Architecture major.
> >> - * @_product_major: Product major.
> >> - */
> >> -#define GPU_MODEL(_name, _arch_major, _product_major) \
> >> -{\
> >> - .name = __stringify(_name), \
> >> - .arch_major = _arch_major, \
> >> - .product_major = _product_major, \
> >> -}
> >> -
> >> -static const struct panthor_model gpu_models[] = {
> >> - GPU_MODEL(g610, 10, 7),
> >> - {},
> >> -};
> >> -
> >> static void arch_10_8_gpu_info_init(struct panthor_device *ptdev)
> >> {
> >> unsigned int i;
> >> @@ -66,29 +32,34 @@ static void arch_10_8_gpu_info_init(struct panthor_device *ptdev)
> >> ptdev->gpu_info.l2_present = gpu_read64(ptdev, GPU_L2_PRESENT_LO);
> >> }
> >>
> >> +static char *get_gpu_model_name(struct panthor_device *ptdev)
> >> +{
> >> + const u32 gpu_id = ptdev->gpu_info.gpu_id;
> >> + const u32 product_id = GPU_PROD_ID_MAKE(GPU_ARCH_MAJOR(gpu_id),
> >> + GPU_PROD_MAJOR(gpu_id));
> >> +
> >> + switch (product_id) {
> >> + case GPU_PROD_ID_MAKE(10, 7):
> >> + return "Mali-G610";
> >> + }
> >
> > I a big fan of these ever growing switch statements with nested
> > conditionals. Could we instead add an optional ::get_variant() callback
> > in panthor_model and have the following formatting:
> >
> > "Mali-%s%s%s", model->name,
> > model->get_variant ? "-" : "",
> > model->get_variant ? model->get_variant() : ""
> >
>
> While that’s certainly an option, I wonder if it’s better to avoid
> additional string formatting when it’s not strictly necessary. The
> switch cases provide a straightforward GPU name without needing to
> handle conditional "-" separators or similar.
>
> Also, with the current approach, if a GPU is misconfigured with an
> incorrect product_major for its core count, the switch’s fallthrough
> helps ensure the correct name is still returned. A model->get_variant()
> callback wouldn’t give us that same flexibility to adjust the name based
> on such mismatches.
Fair enough. I guess we can live with this sort of switch statement for
the name selection. Hopefully the variants are rare enough that it
doesn't go too wild.
next prev parent reply other threads:[~2025-04-10 13:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 11:17 [PATCH v2 0/9] drm/panthor: Add GPU specific initialization framework to support new Mali GPUs Karunika Choo
2025-03-20 11:17 ` [PATCH v2 1/9] drm/panthor: Add 64-bit and poll register accessors Karunika Choo
2025-03-21 7:48 ` Boris Brezillon
2025-04-09 13:00 ` Karunika Choo
2025-04-10 13:28 ` Boris Brezillon
2025-04-10 16:49 ` Karunika Choo
2025-03-20 11:17 ` [PATCH v2 2/9] drm/panthor: Use " Karunika Choo
2025-03-21 7:53 ` Boris Brezillon
2025-04-09 13:07 ` Karunika Choo
2025-04-10 13:29 ` Boris Brezillon
2025-03-20 11:17 ` [PATCH v2 3/9] drm/panthor: Add GPU specific initialization framework Karunika Choo
2025-03-21 8:28 ` Boris Brezillon
2025-03-20 11:17 ` [PATCH v2 4/9] drm/panthor: Move GPU info initialization into panthor_hw.c Karunika Choo
2025-03-21 8:16 ` Boris Brezillon
2025-03-21 8:43 ` Boris Brezillon
2025-03-20 11:17 ` [PATCH v2 5/9] drm/panthor: Make getting GPU model name simple and extensible Karunika Choo
2025-03-21 8:02 ` Boris Brezillon
2025-04-10 13:20 ` Karunika Choo
2025-04-10 13:37 ` Boris Brezillon [this message]
2025-03-20 11:17 ` [PATCH v2 6/9] drm/panthor: Add support for Mali-G715 family of GPUs Karunika Choo
2025-03-21 8:34 ` Boris Brezillon
2025-03-20 11:17 ` [PATCH v2 7/9] drm/panthor: Support GPU_CONTROL cache flush based on feature bit Karunika Choo
2025-03-21 8:41 ` Boris Brezillon
2025-03-20 11:17 ` [PATCH v2 8/9] drm/panthor: Add support for Mali-G720 and Mali-G725 GPUs Karunika Choo
2025-03-20 11:17 ` [PATCH v2 9/9] drm/panthor: Add support for Mali-G710, Mali-G510, and Mali-G310 Karunika Choo
2025-03-20 19:03 ` Liviu Dudau
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=20250410153729.1fb0444c@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.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=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;
as well as URLs for NNTP newsgroup(s).