All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Brost <matthew.brost@intel.com>
Cc: daniel.vetter@intel.com, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [v3 PATCH 2/2] drm/i915/guc: Update sizes of CTB buffers
Date: Fri, 4 Jun 2021 10:20:05 +0200	[thread overview]
Message-ID: <YLniNZjpBz6E24cK@phenom.ffwll.local> (raw)
In-Reply-To: <20210603230408.54856-2-matthew.brost@intel.com>

On Thu, Jun 03, 2021 at 04:04:08PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> 
> Future GuC will require CTB buffers sizes to be multiple of 4K.
> Make these changes now as this shouldn't impact us too much.
> 
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> Cc: John Harrison <john.c.harrison@intel.com>

Assuming this was just rebased?

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 60 ++++++++++++-----------
>  1 file changed, 32 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index ec795d7c3a7d..8d1173032431 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -38,6 +38,32 @@ static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
>  #define CT_PROBE_ERROR(_ct, _fmt, ...) \
>  	i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
>  
> +/**
> + * DOC: CTB Blob

These are supposed to be pulled into the kerneldoc builds, but that's not
happening in this patch?

Now I think the GuC docs in general are fairly outdated, so is the DOC
review coming later, or is the DOC: header here simply cargo-culted :-)

If it's not coming later we need to do a JIRA to clean this all up and
link all the new/changed kerneldoc into our GuC doc structure.
-Daniel

> + *
> + * We allocate single blob to hold both CTB descriptors and buffers:
> + *
> + *      +--------+-----------------------------------------------+------+
> + *      | offset | contents                                      | size |
> + *      +========+===============================================+======+
> + *      | 0x0000 | H2G `CTB Descriptor`_ (send)                  |      |
> + *      +--------+-----------------------------------------------+  4K  |
> + *      | 0x0800 | G2H `CTB Descriptor`_ (recv)                  |      |
> + *      +--------+-----------------------------------------------+------+
> + *      | 0x1000 | H2G `CT Buffer`_ (send)                       | n*4K |
> + *      |        |                                               |      |
> + *      +--------+-----------------------------------------------+------+
> + *      | 0x1000 | G2H `CT Buffer`_ (recv)                       | m*4K |
> + *      | + n*4K |                                               |      |
> + *      +--------+-----------------------------------------------+------+
> + *
> + * Size of each `CT Buffer`_ must be multiple of 4K.
> + * As we don't expect too many messages, for now use minimum sizes.
> + */
> +#define CTB_DESC_SIZE		ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
> +#define CTB_H2G_BUFFER_SIZE	(SZ_4K)
> +#define CTB_G2H_BUFFER_SIZE	(SZ_4K)
> +
>  struct ct_request {
>  	struct list_head link;
>  	u32 fence;
> @@ -175,29 +201,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
>  
>  	GEM_BUG_ON(ct->vma);
>  
> -	/* We allocate 1 page to hold both descriptors and both buffers.
> -	 *       ___________.....................
> -	 *      |desc (SEND)|                   :
> -	 *      |___________|                   PAGE/4
> -	 *      :___________....................:
> -	 *      |desc (RECV)|                   :
> -	 *      |___________|                   PAGE/4
> -	 *      :_______________________________:
> -	 *      |cmds (SEND)                    |
> -	 *      |                               PAGE/4
> -	 *      |_______________________________|
> -	 *      |cmds (RECV)                    |
> -	 *      |                               PAGE/4
> -	 *      |_______________________________|
> -	 *
> -	 * Each message can use a maximum of 32 dwords and we don't expect to
> -	 * have more than 1 in flight at any time, so we have enough space.
> -	 * Some logic further ahead will rely on the fact that there is only 1
> -	 * page and that it is always mapped, so if the size is changed the
> -	 * other code will need updating as well.
> -	 */
> -
> -	blob_size = PAGE_SIZE;
> +	blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE + CTB_G2H_BUFFER_SIZE;
>  	err = intel_guc_allocate_and_map_vma(guc, blob_size, &ct->vma, &blob);
>  	if (unlikely(err)) {
>  		CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
> @@ -209,17 +213,17 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
>  
>  	/* store pointers to desc and cmds for send ctb */
>  	desc = blob;
> -	cmds = blob + PAGE_SIZE / 2;
> -	cmds_size = PAGE_SIZE / 4;
> +	cmds = blob + 2 * CTB_DESC_SIZE;
> +	cmds_size = CTB_H2G_BUFFER_SIZE;
>  	CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "send",
>  		 ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
>  
>  	guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size);
>  
>  	/* store pointers to desc and cmds for recv ctb */
> -	desc = blob + PAGE_SIZE / 4;
> -	cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
> -	cmds_size = PAGE_SIZE / 4;
> +	desc = blob + CTB_DESC_SIZE;
> +	cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
> +	cmds_size = CTB_G2H_BUFFER_SIZE;
>  	CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "recv",
>  		 ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
>  
> -- 
> 2.28.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Brost <matthew.brost@intel.com>
Cc: daniel.vetter@intel.com, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [v3 PATCH 2/2] drm/i915/guc: Update sizes of CTB buffers
Date: Fri, 4 Jun 2021 10:20:05 +0200	[thread overview]
Message-ID: <YLniNZjpBz6E24cK@phenom.ffwll.local> (raw)
In-Reply-To: <20210603230408.54856-2-matthew.brost@intel.com>

On Thu, Jun 03, 2021 at 04:04:08PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> 
> Future GuC will require CTB buffers sizes to be multiple of 4K.
> Make these changes now as this shouldn't impact us too much.
> 
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> Cc: John Harrison <john.c.harrison@intel.com>

Assuming this was just rebased?

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 60 ++++++++++++-----------
>  1 file changed, 32 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index ec795d7c3a7d..8d1173032431 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -38,6 +38,32 @@ static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
>  #define CT_PROBE_ERROR(_ct, _fmt, ...) \
>  	i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
>  
> +/**
> + * DOC: CTB Blob

These are supposed to be pulled into the kerneldoc builds, but that's not
happening in this patch?

Now I think the GuC docs in general are fairly outdated, so is the DOC
review coming later, or is the DOC: header here simply cargo-culted :-)

If it's not coming later we need to do a JIRA to clean this all up and
link all the new/changed kerneldoc into our GuC doc structure.
-Daniel

> + *
> + * We allocate single blob to hold both CTB descriptors and buffers:
> + *
> + *      +--------+-----------------------------------------------+------+
> + *      | offset | contents                                      | size |
> + *      +========+===============================================+======+
> + *      | 0x0000 | H2G `CTB Descriptor`_ (send)                  |      |
> + *      +--------+-----------------------------------------------+  4K  |
> + *      | 0x0800 | G2H `CTB Descriptor`_ (recv)                  |      |
> + *      +--------+-----------------------------------------------+------+
> + *      | 0x1000 | H2G `CT Buffer`_ (send)                       | n*4K |
> + *      |        |                                               |      |
> + *      +--------+-----------------------------------------------+------+
> + *      | 0x1000 | G2H `CT Buffer`_ (recv)                       | m*4K |
> + *      | + n*4K |                                               |      |
> + *      +--------+-----------------------------------------------+------+
> + *
> + * Size of each `CT Buffer`_ must be multiple of 4K.
> + * As we don't expect too many messages, for now use minimum sizes.
> + */
> +#define CTB_DESC_SIZE		ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
> +#define CTB_H2G_BUFFER_SIZE	(SZ_4K)
> +#define CTB_G2H_BUFFER_SIZE	(SZ_4K)
> +
>  struct ct_request {
>  	struct list_head link;
>  	u32 fence;
> @@ -175,29 +201,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
>  
>  	GEM_BUG_ON(ct->vma);
>  
> -	/* We allocate 1 page to hold both descriptors and both buffers.
> -	 *       ___________.....................
> -	 *      |desc (SEND)|                   :
> -	 *      |___________|                   PAGE/4
> -	 *      :___________....................:
> -	 *      |desc (RECV)|                   :
> -	 *      |___________|                   PAGE/4
> -	 *      :_______________________________:
> -	 *      |cmds (SEND)                    |
> -	 *      |                               PAGE/4
> -	 *      |_______________________________|
> -	 *      |cmds (RECV)                    |
> -	 *      |                               PAGE/4
> -	 *      |_______________________________|
> -	 *
> -	 * Each message can use a maximum of 32 dwords and we don't expect to
> -	 * have more than 1 in flight at any time, so we have enough space.
> -	 * Some logic further ahead will rely on the fact that there is only 1
> -	 * page and that it is always mapped, so if the size is changed the
> -	 * other code will need updating as well.
> -	 */
> -
> -	blob_size = PAGE_SIZE;
> +	blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE + CTB_G2H_BUFFER_SIZE;
>  	err = intel_guc_allocate_and_map_vma(guc, blob_size, &ct->vma, &blob);
>  	if (unlikely(err)) {
>  		CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
> @@ -209,17 +213,17 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
>  
>  	/* store pointers to desc and cmds for send ctb */
>  	desc = blob;
> -	cmds = blob + PAGE_SIZE / 2;
> -	cmds_size = PAGE_SIZE / 4;
> +	cmds = blob + 2 * CTB_DESC_SIZE;
> +	cmds_size = CTB_H2G_BUFFER_SIZE;
>  	CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "send",
>  		 ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
>  
>  	guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size);
>  
>  	/* store pointers to desc and cmds for recv ctb */
> -	desc = blob + PAGE_SIZE / 4;
> -	cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
> -	cmds_size = PAGE_SIZE / 4;
> +	desc = blob + CTB_DESC_SIZE;
> +	cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
> +	cmds_size = CTB_G2H_BUFFER_SIZE;
>  	CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "recv",
>  		 ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
>  
> -- 
> 2.28.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-06-04  8:20 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03  5:16 [PATCH 00/20] GuC CTBs changes + a few misc patches Matthew Brost
2021-06-03  5:16 ` [Intel-gfx] " Matthew Brost
2021-06-03  5:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-06-03  5:11 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-03  5:16 ` [PATCH 01/20] drm/i915/guc: skip disabling CTBs before sanitizing the GuC Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 02/20] drm/i915/guc: use probe_error log for CT enablement failure Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 03/20] drm/i915/guc: enable only the user interrupt when using GuC submission Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 04/20] drm/i915/guc: Remove sample_forcewake h2g action Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 05/20] drm/i915/guc: Keep strict GuC ABI definitions Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 06/20] drm/i915/guc: Drop guc->interrupts.enabled Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 07/20] drm/i915/guc: Stop using fence/status from CTB descriptor Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 08/20] drm/i915: Promote ptrdiff() to i915_utils.h Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03 21:35   ` Daniel Vetter
2021-06-03 21:35     ` [Intel-gfx] " Daniel Vetter
2021-06-04  2:02     ` Matthew Brost
2021-06-04  2:02       ` [Intel-gfx] " Matthew Brost
2021-06-04  8:11       ` Daniel Vetter
2021-06-04  8:11         ` [Intel-gfx] " Daniel Vetter
2021-06-03  5:16 ` [PATCH 09/20] drm/i915/guc: Only rely on own CTB size Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 10/20] drm/i915/guc: Don't repeat CTB layout calculations Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 11/20] drm/i915/guc: Replace CTB array with explicit members Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  7:25   ` kernel test robot
2021-06-03  7:25     ` kernel test robot
2021-06-03  7:25     ` [Intel-gfx] " kernel test robot
2021-06-03 21:37     ` Daniel Vetter
2021-06-03 21:37       ` Daniel Vetter
2021-06-03 21:37       ` Daniel Vetter
2021-06-03 22:44       ` [PATCH 1/2] " Matthew Brost
2021-06-03 22:44         ` [Intel-gfx] " Matthew Brost
2021-06-03 22:44         ` [PATCH 2/2] drm/i915/guc: Update sizes of CTB buffers Matthew Brost
2021-06-03 22:44           ` [Intel-gfx] " Matthew Brost
2021-06-03 23:04       ` [v3 PATCH 1/2] drm/i915/guc: Replace CTB array with explicit members Matthew Brost
2021-06-03 23:04         ` [Intel-gfx] " Matthew Brost
2021-06-03 23:04         ` [v3 PATCH 2/2] drm/i915/guc: Update sizes of CTB buffers Matthew Brost
2021-06-03 23:04           ` [Intel-gfx] " Matthew Brost
2021-06-04  8:20           ` Daniel Vetter [this message]
2021-06-04  8:20             ` Daniel Vetter
2021-06-04  8:49             ` Michal Wajdeczko
2021-06-04  8:49               ` [Intel-gfx] " Michal Wajdeczko
2021-06-03  5:16 ` [PATCH 12/20] " Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 13/20] drm/i915/guc: Relax CTB response timeout Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-04  8:33   ` Daniel Vetter
2021-06-04  8:33     ` Daniel Vetter
2021-06-04 18:35     ` Matthew Brost
2021-06-04 18:35       ` Matthew Brost
2021-06-09 13:24       ` Daniel Vetter
2021-06-09 13:24         ` Daniel Vetter
2021-06-03  5:16 ` [PATCH 14/20] drm/i915/guc: Start protecting access to CTB descriptors Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-04  8:35   ` Daniel Vetter
2021-06-04  8:35     ` [Intel-gfx] " Daniel Vetter
2021-06-03  5:16 ` [PATCH 15/20] drm/i915/guc: Ensure H2G buffer updates visible before tail update Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  9:44   ` Michal Wajdeczko
2021-06-03  9:44     ` Michal Wajdeczko
2021-06-03 16:10     ` Matthew Brost
2021-06-03 16:10       ` Matthew Brost
2021-06-04  8:39       ` Daniel Vetter
2021-06-04  8:39         ` Daniel Vetter
2021-06-03  5:16 ` [PATCH 16/20] drm/i915/guc: Stop using mutex while sending CTB messages Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 17/20] drm/i915/guc: Don't receive all G2H messages in irq handler Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 18/20] drm/i915/guc: Always copy CT message to new allocation Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 19/20] drm/i915/guc: Early initialization of GuC send registers Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-03  5:16 ` [PATCH 20/20] drm/i915/guc: Use guc_class instead of engine_class in fw interface Matthew Brost
2021-06-03  5:16   ` [Intel-gfx] " Matthew Brost
2021-06-04  8:44   ` Daniel Vetter
2021-06-04  8:44     ` [Intel-gfx] " Daniel Vetter
2021-06-04 18:12     ` Matthew Brost
2021-06-04 18:12       ` [Intel-gfx] " Matthew Brost
2021-06-03  5:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success for GuC CTBs changes + a few misc patches Patchwork
2021-06-03  6:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=YLniNZjpBz6E24cK@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    /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.