From: Andi Shyti <andi.shyti@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: "Intel GFX" <intel-gfx@lists.freedesktop.org>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"DRI Devel" <dri-devel@lists.freedesktop.org>,
"Chris Wilson" <chris@chris-wilson.co.uk>,
"Michał Winiarski" <michal.winiarski@intel.com>
Subject: Re: [Intel-gfx] [PATCH v9 2/6] drm/i915: Use to_gt() helper for GGTT accesses
Date: Tue, 21 Dec 2021 21:46:29 +0200 [thread overview]
Message-ID: <YcIvFYDuY2uM5hCr@intel.intel> (raw)
In-Reply-To: <YcIIf4wmvNdM09ZS@mdroper-desk1.amr.corp.intel.com>
Hi Matt,
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> > index 170bba913c30..128315aec517 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1630,7 +1630,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
> > struct drm_i915_gem_object *bo;
> > struct i915_vma *vma;
> > const u64 delay_ticks = 0xffffffffffffffff -
> > - intel_gt_ns_to_clock_interval(stream->perf->i915->ggtt.vm.gt,
> > + intel_gt_ns_to_clock_interval(to_gt(stream->perf->i915)->ggtt->vm.gt,
>
> I'm not too familiar with the perf code, but this looks a bit roundabout
> since we're ultimately trying to get to a GT...do we even need to go
> through the ggtt structure here or can we just pass
> "to_gt(stream->perf->i915)" as the first parameter?
>
> > atomic64_read(&stream->perf->noa_programming_delay));
> > const u32 base = stream->engine->mmio_base;
> > #define CS_GPR(x) GEN8_RING_CS_GPR(base, x)
> > @@ -3542,7 +3542,7 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
> >
> > static u64 oa_exponent_to_ns(struct i915_perf *perf, int exponent)
> > {
> > - return intel_gt_clock_interval_to_ns(perf->i915->ggtt.vm.gt,
> > + return intel_gt_clock_interval_to_ns(to_gt(perf->i915)->ggtt->vm.gt,
>
> Ditto; this looks like "to_gt(perf->i915)" might be all we need?
I think this function is looking for the GT coming from the VM,
otherwise originally it could have taken it from &i915->gt. In my
first version I proposed a wrapper around this but it was
rejected by Lucas.
Besides, as we discussed earlier when I was proposed the static
allocation, the ggtt might not always be linked to the same gt,
so that I assumed that sometimes:
to_gt(perf->i915)->ggtt->vm.gt != to_gt(perf->i915)
if two GTs are sharing the same ggtt, what would the ggtt->vm.gt
link be?
Thanks,
Andi
WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: "Sujaritha Sundaresan" <sujaritha.sundaresan@intel.com>,
"Andi Shyti" <andi@etezian.org>,
"Intel GFX" <intel-gfx@lists.freedesktop.org>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"DRI Devel" <dri-devel@lists.freedesktop.org>,
"Chris Wilson" <chris@chris-wilson.co.uk>,
"Andi Shyti" <andi.shyti@linux.intel.com>,
"Michał Winiarski" <michal.winiarski@intel.com>
Subject: Re: [PATCH v9 2/6] drm/i915: Use to_gt() helper for GGTT accesses
Date: Tue, 21 Dec 2021 21:46:29 +0200 [thread overview]
Message-ID: <YcIvFYDuY2uM5hCr@intel.intel> (raw)
In-Reply-To: <YcIIf4wmvNdM09ZS@mdroper-desk1.amr.corp.intel.com>
Hi Matt,
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> > index 170bba913c30..128315aec517 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1630,7 +1630,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
> > struct drm_i915_gem_object *bo;
> > struct i915_vma *vma;
> > const u64 delay_ticks = 0xffffffffffffffff -
> > - intel_gt_ns_to_clock_interval(stream->perf->i915->ggtt.vm.gt,
> > + intel_gt_ns_to_clock_interval(to_gt(stream->perf->i915)->ggtt->vm.gt,
>
> I'm not too familiar with the perf code, but this looks a bit roundabout
> since we're ultimately trying to get to a GT...do we even need to go
> through the ggtt structure here or can we just pass
> "to_gt(stream->perf->i915)" as the first parameter?
>
> > atomic64_read(&stream->perf->noa_programming_delay));
> > const u32 base = stream->engine->mmio_base;
> > #define CS_GPR(x) GEN8_RING_CS_GPR(base, x)
> > @@ -3542,7 +3542,7 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
> >
> > static u64 oa_exponent_to_ns(struct i915_perf *perf, int exponent)
> > {
> > - return intel_gt_clock_interval_to_ns(perf->i915->ggtt.vm.gt,
> > + return intel_gt_clock_interval_to_ns(to_gt(perf->i915)->ggtt->vm.gt,
>
> Ditto; this looks like "to_gt(perf->i915)" might be all we need?
I think this function is looking for the GT coming from the VM,
otherwise originally it could have taken it from &i915->gt. In my
first version I proposed a wrapper around this but it was
rejected by Lucas.
Besides, as we discussed earlier when I was proposed the static
allocation, the ggtt might not always be linked to the same gt,
so that I assumed that sometimes:
to_gt(perf->i915)->ggtt->vm.gt != to_gt(perf->i915)
if two GTs are sharing the same ggtt, what would the ggtt->vm.gt
link be?
Thanks,
Andi
next prev parent reply other threads:[~2021-12-21 19:46 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-19 21:24 [Intel-gfx] [PATCH v9 0/6] More preparation for multi gt patches Andi Shyti
2021-12-19 21:24 ` Andi Shyti
2021-12-19 21:24 ` [Intel-gfx] [PATCH v9 1/6] drm/i915/gt: Use to_gt() helper for GGTT accesses Andi Shyti
2021-12-19 21:24 ` Andi Shyti
2021-12-21 16:47 ` [Intel-gfx] " Matt Roper
2021-12-21 16:47 ` Matt Roper
2021-12-21 19:59 ` [Intel-gfx] [PATCH v10 " Andi Shyti
2021-12-21 19:59 ` Andi Shyti
2021-12-19 21:24 ` [Intel-gfx] [PATCH v9 2/6] drm/i915: " Andi Shyti
2021-12-19 21:24 ` Andi Shyti
2021-12-21 17:01 ` [Intel-gfx] " Matt Roper
2021-12-21 17:01 ` Matt Roper
2021-12-21 19:46 ` Andi Shyti [this message]
2021-12-21 19:46 ` Andi Shyti
2022-01-03 21:17 ` [Intel-gfx] " Matt Roper
2022-01-03 21:17 ` Matt Roper
2022-01-04 17:52 ` [Intel-gfx] " Umesh Nerlige Ramappa
2022-01-04 17:52 ` Umesh Nerlige Ramappa
2022-01-04 22:27 ` [Intel-gfx] " Andi Shyti
2022-01-04 22:27 ` Andi Shyti
2022-01-04 22:35 ` [Intel-gfx] [PATCH v10 " Andi Shyti
2022-01-04 22:35 ` Andi Shyti
2022-01-05 5:31 ` [Intel-gfx] " Matt Roper
2022-01-05 5:31 ` Matt Roper
2021-12-19 21:24 ` [Intel-gfx] [PATCH v9 3/6] drm/i915/gem: " Andi Shyti
2021-12-19 21:24 ` Andi Shyti
2021-12-19 21:24 ` [Intel-gfx] [PATCH v9 4/6] drm/i915/display: " Andi Shyti
2021-12-19 21:24 ` Andi Shyti
2021-12-19 21:24 ` [Intel-gfx] [PATCH v9 5/6] drm/i915/selftests: " Andi Shyti
2021-12-19 21:24 ` Andi Shyti
2021-12-19 21:25 ` [Intel-gfx] [PATCH v9 6/6] drm/i915: Remove unused i915->ggtt Andi Shyti
2021-12-19 21:25 ` Andi Shyti
2021-12-19 21:54 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More preparation for multi gt patches Patchwork
2021-12-19 21:56 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-12-19 22:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-12-19 23:24 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-12-21 22:09 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More preparation for multi gt patches (rev2) Patchwork
2021-12-21 22:10 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-12-21 22:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-12-22 2:47 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-01-04 23:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More preparation for multi gt patches (rev3) Patchwork
2022-01-04 23:08 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-04 23:34 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-01-05 5:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More preparation for multi gt patches (rev4) Patchwork
2022-01-05 5:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-05 6:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-05 7:15 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-01-05 19:08 ` Matt Roper
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=YcIvFYDuY2uM5hCr@intel.intel \
--to=andi.shyti@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.winiarski@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.