All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Francois Dugast <francois.dugast@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [RFC PATCH v2 1/3] drm/xe: Introduce function pointers in xe_gt.c with local structure
Date: Wed, 15 Mar 2023 11:52:23 +0200	[thread overview]
Message-ID: <87ttym5oko.fsf@intel.com> (raw)
In-Reply-To: <20230314155111.1546283-2-francois.dugast@intel.com>

On Tue, 14 Mar 2023, Francois Dugast <francois.dugast@intel.com> wrote:
> A local structure of function pointers is used as a minimal
> hardware abstraction layer to split between common and platform
> specific code. This structure is initialized once with the
> functions matching the platform, then it is used in the common
> code with no need for switch or if/else to detect the platform.
> For now only the function setup_private_ppat() is refactored.
>
> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_device_types.h |  1 +
>  drivers/gpu/drm/xe/xe_gt.c           | 46 +++++++++++++++++++---------
>  2 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
> index 034e0956f4ea..411e7a62d28a 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -311,6 +311,7 @@ struct xe_device {
>  		u32 lvds_channel_mode;
>  	} params;
>  #endif
> +	struct xe_gt_platform_funcs *gt_funcs;

IMO this should be a const pointer.

>  };
>  
>  /**
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index daa433d0f2f5..3b092f951378 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -42,6 +42,10 @@
>  #include "xe_wa.h"
>  #include "xe_wopcm.h"
>  
> +struct xe_gt_platform_funcs {
> +	void (*setup_private_ppat)(struct xe_gt *gt);
> +};
> +
>  struct xe_gt *xe_find_full_gt(struct xe_gt *gt)
>  {
>  	struct xe_gt *search;
> @@ -157,18 +161,6 @@ static void mtl_setup_private_ppat(struct xe_gt *gt)
>  			MTL_PPAT_0_WB | MTL_3_COH_2W);
>  }
>  
> -static void setup_private_ppat(struct xe_gt *gt)
> -{
> -	struct xe_device *xe = gt_to_xe(gt);
> -
> -	if (xe->info.platform == XE_METEORLAKE)
> -		mtl_setup_private_ppat(gt);
> -	else if (xe->info.platform == XE_PVC)
> -		pvc_setup_private_ppat(gt);
> -	else
> -		tgl_setup_private_ppat(gt);
> -}

IMO keep this as a wrapper that calls the function pointer.

> -
>  static int gt_ttm_mgr_init(struct xe_gt *gt)
>  {
>  	struct xe_device *xe = gt_to_xe(gt);
> @@ -380,6 +372,28 @@ int xe_gt_record_default_lrcs(struct xe_gt *gt)
>  int xe_gt_init_early(struct xe_gt *gt)
>  {
>  	int err;
> +	struct xe_device *xe = gt_to_xe(gt);
> +
> +	xe->gt_funcs = kzalloc(sizeof(*xe->gt_funcs), GFP_KERNEL);
> +	switch (xe->info.platform) {
> +	case XE_METEORLAKE:
> +		xe->gt_funcs->setup_private_ppat = mtl_setup_private_ppat;
> +		break;
> +	case XE_PVC:
> +		xe->gt_funcs->setup_private_ppat = pvc_setup_private_ppat;
> +		break;
> +	case XE_ROCKETLAKE:
> +	case XE_DG1:
> +	case XE_DG2:
> +	case XE_ALDERLAKE_S:
> +	case XE_ALDERLAKE_P:
> +	case XE_TIGERLAKE:
> +		xe->gt_funcs->setup_private_ppat = tgl_setup_private_ppat;
> +		break;
> +	default:
> +		DRM_ERROR("Unsupported platform\n");
> +		break;
> +	}

IMO you should always aim to have static const initialized structs with
the function pointers, assign the const pointer to the struct, and avoid
assigning individual function pointers members.

It's a bad practise to allocate the function pointer struct.

>  
>  	xe_force_wake_init_gt(gt, gt_to_fw(gt));
>  
> @@ -441,13 +455,15 @@ int xe_gt_init_noalloc(struct xe_gt *gt)
>  static int gt_fw_domain_init(struct xe_gt *gt)
>  {
>  	int err, i;
> +	struct xe_device *xe = gt_to_xe(gt);
>  
>  	xe_device_mem_access_get(gt_to_xe(gt));
>  	err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
>  	if (err)
>  		goto err_hw_fence_irq;
>  
> -	setup_private_ppat(gt);
> +	if (xe->gt_funcs->setup_private_ppat)
> +		xe->gt_funcs->setup_private_ppat(gt);

IME it's better to keep functions like setup_private_ppat() as wrappers
to the function calls. The caller does not need to know the
implementation details i.e. whether it's a function pointer or not.

BR,
Jani.

>  
>  	if (!xe_gt_is_media_type(gt)) {
>  		err = xe_ggtt_init(gt, gt->mem.ggtt);
> @@ -630,8 +646,10 @@ static int do_gt_restart(struct xe_gt *gt)
>  	struct xe_hw_engine *hwe;
>  	enum xe_hw_engine_id id;
>  	int err;
> +	struct xe_device *xe = gt_to_xe(gt);
>  
> -	setup_private_ppat(gt);
> +	if (xe->gt_funcs->setup_private_ppat)
> +		xe->gt_funcs->setup_private_ppat(gt);
>  
>  	xe_gt_mcr_set_implicit_defaults(gt);
>  	xe_reg_sr_apply_mmio(&gt->reg_sr, gt);

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-03-15  9:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 15:51 [Intel-xe] [RFC PATCH v2 0/3] Split code between common and platform specific Francois Dugast
2023-03-14 15:51 ` [Intel-xe] [RFC PATCH v2 1/3] drm/xe: Introduce function pointers in xe_gt.c with local structure Francois Dugast
2023-03-15  9:52   ` Jani Nikula [this message]
2023-03-14 15:51 ` [Intel-xe] [RFC PATCH v2 2/3] drm/xe: Introduce function pointers in xe_guc_pc.c " Francois Dugast
2023-03-14 15:51 ` [Intel-xe] [RFC PATCH v2 3/3] drm/xe: Add platform specific functions for a new platform Francois Dugast
2023-03-14 20:58 ` [Intel-xe] ✓ CI.Patch_applied: success for Split code between common and platform specific (rev2) Patchwork
2023-03-14 20:59 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-03-14 21:03 ` [Intel-xe] ✓ CI.Build: " Patchwork

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=87ttym5oko.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.