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
next prev parent 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: linkBe 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.