Hi Tvrtko,
> > +void intel_gt_sysfs_register(struct intel_gt *gt)
> > +{
> > + struct kobject *parent =
> > kobject_get(>->i915->drm.primary->kdev->kobj);
>
> Does this needs a kobject_put to balance out somewhere?
Yes, I forgot the two kobject_put that are needed.
> > + int ret;
> > +
> >
rward progress.)
>
> Reported-by: Zbigniew Kempczyński
> Signed-off-by: Chris Wilson
> Cc: Zbigniew Kempczyński
> Cc: Joonas Lahtinen
nice!
Reviewed-by: Andi Shyti
Thanks,
Andi
> ---
> drivers/gpu/drm/drm_mm.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 delet
ed-off-by: Daniele Ceraolo Spurio
> Cc: Michal Wajdeczko
> Cc: John Harrison
> Cc: Matthew Brost
> Reviewed-by: Michal Wajdeczko
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesk
Hi Daniele,
On Tue, Feb 11, 2020 at 04:31:15PM -0800, Daniele Ceraolo Spurio wrote:
> The log struct is the only thing the function needs (apart from
> the seq_file), so we can pass just that instead of the whole dev_priv.
>
> v2: Split this change to its own patch (Michal)
>
> Signed-off-by: Da
Not a big deal though:
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ow.
I haven't spotted anything wrong (also in the patches that
follow), and I hope you tested it properly :)
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ad
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Michal Wajdeczko
> Cc: John Harrison
> Cc: Matthew Brost
> Reviewed-by: Michal Wajdeczko #v1
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Signed-off-by: Andi Shyti
---
Hi,
this version has some more substantial differences, nothing tha
Hi Tvrtko,
> > The GT has its own properties and in sysfs they should be grouped
> > in the 'gt/' directory.
> >
> > Create the 'gt/' directory in sysfs and move the power management
> > related files.
>
> Can you paste the new and legacy paths in the commit message?
sure!
> > diff --git a/dri
Hi Tvrtko,
> > > > + }
> > > > +
> > > > + intel_gt_sysfs_pm_remove(gt, root);
> > > > + kobject_put(root);
> > >
> > > Maybe stick to the same terminology regarding root and parent.
> >
> > yes.
> >
> > > Get/put on the parent looks unbalanced. Both register and unregister ta
t; very careful probes that anticipate the links being deleted and the
> fences recycled before we are able to acquire a strong reference to it.
> We do not need the signal->lock crutch anymore, nor want the contention.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Revie
Hi Chris,
On Wed, Jan 13, 2021 at 12:45:54PM +, Chris Wilson wrote:
> Take a snapshot of the ctx->engines, so we can avoid taking the
> ctx->engines_mutex for a mere read in get_engines().
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Sh
this
> we need only take a reference to the src->engines, rather than hold the
> src->engine_mutex, so long as we verify that nothing changed under the
> read.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
> + if (user_engines)
>
arrange by a pair of memory bariiers and carefully sequencing of the
> writes and reads.
>
> Signed-off-by: Chris Wilson
overall looks like a nice simplification...
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@
Hi Chris,
On Wed, Jan 13, 2021 at 12:45:55PM +, Chris Wilson wrote:
> Avoid the full blown memory barrier of test_and_set_bit() by noting the
> completed request and removing it from the lists.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
tel_engine_stats.h | 49 +++
> .../drm/i915/gt/intel_execlists_submission.c | 34 +
> 2 files changed, 50 insertions(+), 33 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h
this looks like just a copy paste...
Reviewed-by
at can be
> arrange by a pair of memory bariiers and carefully sequencing of the
> writes and reads.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fr
d-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 0b1a46a0d866..784c05ac5cca 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -276,7 +276,7 @@ static void remove_from_engine(struct i915_r
seqcount.
>
> Signed-off-by: Chris Wilson
looks correct...
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
gt;
> This holds the request->context->timeline->mutex.
>
> The locking is basically split between frontend/backend:
>
> construction/destruction - under the timeline->mutex
>
> execution - under the engine->active.lock (coordinates with
> timeline->mutex)
Hi Chris,
On Wed, Jan 20, 2021 at 12:21:59PM +, Chris Wilson wrote:
> As we do not have any internal priority levels, the priority can be set
> directed from the user values.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
t; - return;
> -
> - spin_lock_irqsave(&schedule_lock, flags);
> - __bump_priority(&rq->sched, bump);
> - spin_unlock_irqrestore(&schedule_lock, flags);
> -}
was, indeed, this function used anywhere else?
Reviewed-by: Andi Shyti
Andi
__
handle this as it will ultimately
> - * find itself trying to jump back into a context it has just
> - * completed and barf.
>*/
> + active = execlists->active;
> + while ((last = *active) && completed(last))
> + active++;
looks reasonable to me...
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
On Wed, Jan 20, 2021 at 12:21:56PM +, Chris Wilson wrote:
> Treat the dependency between bonded requests as weak and leave the
> remainder of the pair on the GPU if one hangs.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Hi Chris,
On Wed, Jan 20, 2021 at 12:22:00PM +, Chris Wilson wrote:
> Looking to the future, we want to set the scheduling attributes
> explicitly and so replace the generic engine->schedule() with the more
> direct i915_request_set_priority()
>
> What it loses in removing the 'schedule' name
Hi Chris,
> + local_bh_disable();
> + i915_request_set_priority(rq, prio);
> + local_bh_enable();
> +
> + i915_request_put(rq);
> + rq = ptr_mask_bits(rn, 1);
why are you using ptr_mask_bits here?
> + } while (rq);
> +}
> +
> +void
On Wed, Jan 20, 2021 at 12:22:03PM +, Chris Wilson wrote:
> As a topological sort, we expect it to run in linear graph time,
> O(V+E). In removing the recursion, it is no longer a DFS but rather a
> BFS, and performs as O(VE). Let's demonstrate how bad this is with a few
> examples, and build a
run for a few hundred
> milliseconds given a wide enough graph, not the microseconds as required.
>
> Signed-off-by: Chris Wilson
I have seen this patch long time ago... I'm r-b'eing starting
from the last patch :)
Reviewed-by: Andi Shyti
Andi
stead, we
> inspect the context state before submission which will alert us to any
> issues prior to execution.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
Thanks,
Andi
wn
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson
> Cc: Edward Baker
> Cc: Andi Sh
i915_ring_freq_table
> i915_context_status
> i915_llc
> i915_shrinker_info
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
And that's the statement :)
Reviewed-by: Andi Shyti
Andi
___
ERR(obj)) {
> - err = PTR_ERR(obj);
> + if (IS_ERR(obj2)) {
> + err = PTR_ERR(obj2);
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
gine =
> + (struct drm_i915_engine_info *)&engines->engines[i];
I would have liked it with one single for loop, perhaps resetting
engines individually.
But this works, as well and I'm not strong with this:
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
is Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> Cc: Andi Shyti
I don't see any issue, looks correct to me:
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
e context
> switches. A thousand context switches may be 50-100ms, causing us to
> timeout as the HW is not fast enough to complete the deep smoketests.
>
> Signed-off-by: Chris Wilson
looks all right to me:
Reviewed-by: Andi Shyti
Andi
___
I
Hi Chris,
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1f63c4a1f055..7fe1f317cd2b 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -198,6 +198,7 @@ vma_create(struct drm_i915_gem_object *obj,
> cmp
Hi Chris,
> Ta, going to send that as a patch?
mine was a suggestion, it was easier to build the diff than
explain myself :)
If you want I can send it, though.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.o
IST_HEAD(&ctx->stale.engines);
>
> @@ -35,7 +37,7 @@ mock_context(struct drm_i915_private *i915,
> RCU_INIT_POINTER(ctx->engines, e);
>
> INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
> - mutex_init(&ctx-
Since we
> don't use generally use struct_mutex, we can relax the tainting.
>
> Signed-off-by: Chris Wilson
Looks good!
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org
Hi Chris,
On Thu, Jul 02, 2020 at 10:10:15PM +0100, Chris Wilson wrote:
> Not only do we need to release the vm.ref we acquired for the vma on the
> duplicate insert branch, but also for the normal error paths, so roll
> them all into one.
>
> Reported-by: Andi Shyti
> Sugges
gt; differ with the aliasing-ppgtt.
>
> Signed-off-by: Chris Wilson
very nice!
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
> +static int gen6_fixup_ggtt(struct i915_vma *vma)
you create this function here and remove it in patch 21. This
series is a bit confusing, can we have a final version of it?
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
Hi Tianjia,
> diff --git a/drivers/gpu/drm/i915/i915_active.c
> b/drivers/gpu/drm/i915/i915_active.c
> index d960d0be5bd2..cc017e3cc9c5 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -758,7 +758,7 @@ int i915_active_acquire_preallocate_barrier(st
t;
> > > - int err;
> > > + int err = 0;
> >
> > you don't need the initialization here.
>
> But it's close enough that I can munge the patch inline.
> Reviewed-by: Chris Wilson
sure... you can also remove it before merging it and it migh
; - err = PTR_ERR(obj);
> + if (IS_ERR(obj2)) {
> + err = PTR_ERR(obj2);
> goto put1;
> }
ops...
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
On Wed, Feb 19, 2020 at 01:01:19PM +, Chris Wilson wrote:
> For dgfx, we do not need to reconfigure the IA/ring frequencies of the
> main processors as they are distinct devices.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Tvrtko Ursulin
looks
t/gt_max_freq_mhz
gt/gt_min_freq_mhz
gt/gt_RP0_freq_mhz
gt/gt_RP1_freq_mhz
gt/gt_RPn_freq_mhz
gt/rc6_enable
gt/rc6_residency_ms
The once in the root directory will be marked as deprecated, if
accessed a warning message is printed.
Signed-off-by: Andi Shyti
---
v3 -> v4:
- fixed Tvrtko's comme
> drivers/gpu/drm/i915/Makefile|4 +-
> drivers/gpu/drm/i915/gt/intel_gt.c |3 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h |1 +
> drivers/gpu/drm/i915/gt/sysfs_gt.c | 79 ++
> drivers/gpu/drm/i915/gt/sysfs_gt.h | 22 +
> drivers/gpu/drm/i915/gt/sysfs
t/gt_max_freq_mhz
gt/gt_min_freq_mhz
gt/gt_RP0_freq_mhz
gt/gt_RP1_freq_mhz
gt/gt_RPn_freq_mhz
gt/rc6_enable
gt/rc6_residency_ms
The once in the root directory will be marked as deprecated, if
accessed a warning message is printed.
Signed-off-by: Andi Shyti
---
v4 -> v5:
- removed spurious ghost &#
y: Chris Wilson
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
Thanks, Chris,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > +void intel_gt_sysfs_register(struct intel_gt *gt)
> > +{
> > + struct kobject *parent = kobject_get(gt_get_parent_obj(gt));
> > + int ret;
> > +
> > + ret = kobject_init_and_add(>->sysfs_root,
> > + &sysfs_gt_ktype,
> > + parent,
> > > > +void intel_gt_sysfs_unregister(struct intel_gt *gt)
> > > > +{
> > > > + struct kobject *parent = gt_get_parent_obj(gt);
> > > > +
> > > > + /*
> > > > +* the name gt tells us wether sysfs_root
> > > > +* object was initialized properly
> > > > +*/
> > >
> > > > > > +void intel_gt_sysfs_register(struct intel_gt *gt)
> > > > > > +{
> > > > > > + struct kobject *parent = kobject_get(gt_get_parent_obj(gt));
> > > > > > + int ret;
> > > > > > +
> >
> > and if I need to call kobject_put at the end. If for some reason
> > the files have failed to be
till
> in flight.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
signaling on the
> fence we need to double check it is a fence!
>
> Fixes: d13a31770077 ("drm/i915: Flush idle barriers when waiting")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Andi
___
gt; + spin_unlock_wait(&ref->tree_lock);
maybe one day I will stop complaining about out of context
changes... maybe one day.
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
gned-off-by: Chris Wilson
Looks good!
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
> +static int create_ext_ioctl(int i915,
> + struct drm_i915_gem_context_create_ext *arg)
> +{
> + int err;
> +
> + err = 0;
> + if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
> + err = -errno;
> + igt_assume
> > > +void dyn_sysfs_engines(int i915, int engines, const char *file,
> > > +void (*test)(int, int))
> > > +{
> > > + char buf[512];
> > > + int len;
> > > +
> > > + lseek(engines, 0, SEEK_SET);
> > > + while ((len = syscall(SYS_getdents64, engines, buf, sizeof(
On Fri, Feb 28, 2020 at 10:43:39AM +, Chris Wilson wrote:
> We [will] expose various per-engine scheduling controls. One of which,
> 'heartbeat_duration_ms', defines how often we send a heartbeat down the
> engine to check upon the health of the engine. If a heartbeat does not
> complete within
> > > > > + char buf[512];
> > > > > + int len;
> > > > > +
> > > > > + lseek(engines, 0, SEEK_SET);
> > > > > + while ((len = syscall(SYS_getdents64, engines, buf,
> > > > > sizeof(buf))) > 0) {
> > > > > + void *ptr = buf;
> > > > > +
> > > > > + while (le
Hi Daniele,
I'm sorry I missed this patch,
On Thu, Feb 27, 2020 at 06:28:42PM -0800, Daniele Ceraolo Spurio wrote:
> uC is a component of the GT, so it makes sense for the uC debugfs files
> to be in the GT folder. A subfolder has been used to keep the same
> structure we have for the code.
Can
Hi Daniele,
> > On Thu, Feb 27, 2020 at 06:28:42PM -0800, Daniele Ceraolo Spurio wrote:
> > > uC is a component of the GT, so it makes sense for the uC debugfs files
> > > to be in the GT folder. A subfolder has been used to keep the same
> > > structure we have for the code.
> >
> > Can we pleas
ate data as argument.
Still keep it simple by defining a wrapper where struct *gt is
the chosen private data to be stored.
I take the chance to rename the functions by using "intel_gt_" as
prefix instead of "debugfs_".
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/debugfs
Hi Daniele,
> > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > index 75255aaacaed..9112a8585caf 100644
> > --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > @@ -26,15 +26,14 @@ void debugfs_gt_register(s
Hi Daniele,
> > > > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > index 75255aaacaed..9112a8585caf 100644
> > > > --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > @@ -26,15 +26,14 @@ vo
From: Andi Shyti
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
There might be different needs, therefore make it generic by
adding one more argument to the "debugfs_register_files()"
function which gets the
Hi Daniele,
> > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > index 75255aaacaed..24099fb157be 100644
> > --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > @@ -26,15 +26,14 @@ void debugfs_gt_register(s
From: Andi Shyti
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
There might be different needs, therefore make it generic by
adding one more argument to the "debugfs_register_files()"
function which gets the
From: Andi Shyti
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
To be open to different usages make the new
"intel_gt_debugfs_register_files()"[*] function more generic by
converting the 'struct *gt'
Hi Chris,
On Sat, Mar 07, 2020 at 12:07:22PM +, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-06 23:03:44)
> > -void debugfs_gt_register_files(struct intel_gt *gt,
> > - struct dentry *root,
> > - const s
Hi Chris,
> > > Quoting Andi Shyti (2020-03-06 23:03:44)
> > > > -void debugfs_gt_register_files(struct intel_gt *gt,
> > > > - struct dentry *root,
> > > > -
Hi Daniele,
> > > > > Quoting Andi Shyti (2020-03-06 23:03:44)
> > > > > > -void debugfs_gt_register_files(struct intel_gt *gt,
> > > > > > - struct dentry *root,
> > > > > &g
t the consistent error value from
drm_dev_init() and embed it in the pointer return value.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_drv.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > struct intel_device_info *device_info;
> > struct drm_i915_private *i915;
> > + int err;
> >
> > i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
> > if (!i915)
> > return NULL;
>
> Ahem.
oh yes :)
Thanks,
Andi
___
t the consistent error value from
drm_dev_init() and embed it in the pointer return value.
Signed-off-by: Andi Shyti
---
Hi,
I did forget in the version 1 to return -ENOMEM in case of
kzalloc failure. Thanks Chris!
Andi
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
1 file changed, 7 insertions(
atch 2 for enabling the EMIT_FLUSH
flag.
v1 -> v2
- add a clean up preliminary patch for the existing registers
- add support for more engines
- add the Fixes tag
Andi Shyti (5):
drm/i915/gt: Cleanup aux invalidation registers
drm/i915: Add the gen12_needs_ccs_aux_inv helper
drm/i915/
on't exist and add
BCS0 and CCS0.
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 16
drivers/gpu/drm/i915/gt/intel_lrc.c
needed or not.
Currently PVC is the only exception to the above mentioned rule.
Requires: 059ae7ae2a1c ("drm/i915/gt: Cleanup aux invalidation registers")
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Jonathan Cavitt
Cc: # v5.8+
Reviewed-by: Matt Roper
Reviewed-by: Andrzej Hajda
R
er")
Signed-off-by: Jonathan Cavitt
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/dri
ently only
PIPE_CONTROL0_HDC_PIPELINE_FLUSH bit is set.
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Matt Roper
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 34 +---
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 18
gines")
Requires: 8da173db894a ("drm/i915/gt: Rename flags with bit_group_X according
to the datasheet")
Signed-off-by: Andi Shyti
Cc: Jonathan Cavitt
Cc: Nirmoy Das
Cc: # v5.8+
Reviewed-by: Matt Roper
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915
From: Jonathan Cavitt
For platforms that use Aux CCS, wait for aux invalidation to
complete by checking the aux invalidation register bit is
cleared.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt
Signed-off-by: Andi
gines")
Signed-off-by: Andi Shyti
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: # v5.8+
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 66 +---
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +-
3 files c
Hi Matt,
> +/*
> + * Wa_22011802037 requires that we (or the GuC) ensure that no command
> + * streamers are executing MI_FORCE_WAKE while an engine reset is initiated.
> + */
> +bool intel_engine_reset_needs_wa_22011802037(struct intel_gt *gt)
I've seen this format in a recent Jonathan's patch a
Hi Matt,
On Mon, Jul 24, 2023 at 05:13:15PM -0700, Matt Roper wrote:
> The currently implemented Xe_LPM+ workarounds are specific to media
> version 13.00. When new IP versions show up in the future, they'll need
> their own workaround lists.
Makes sense...
Reviewed-by: Andi
Hi Matt,
[...]
all good
[...]
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
Is this the right place to define this? Maybe in
i915/gt/intel_gt.h?
> @@ -431,6 +431,29 @@ static inline struct intel_gt *to_gt(struct
> drm_i915_private *i915)
> #define IS_GRAPHI
Hi Matt,
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -436,6 +436,9 @@ static inline struct intel_gt *to_gt(struct
> drm_i915_private *i915)
> #define __GT_VER_FULL(gt) (__IS_MEDIA_GT(gt) ? \
> MEDIA_VER_FULL((gt)->i915) : \
>
Hi Matt,
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -470,9 +470,13 @@ enum i915_map_type i915_coherent_map_type(struct
> drm_i915_private *i915,
> bool always_coherent)
> {
> /*
> - *
Quite surprised to see that around i915 there are still i915->gt0
references. Replace them with the to_gt() helper.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915
ot remembering what
> else do we use for it?
>
> It is needed because i915_flush_writes()'s point AFAIU is to make sure CPU
> writes after i915_vma_pin_iomap() have landed in RAM. All three methods the
> latter can map the buffer are WC, therefore "flushing" of the WC
Hi Andy,
On Mon, Jul 24, 2023 at 11:25:11AM +0300, Andy Shevchenko wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
>
> Signed-off-by: Andy Shevchenko
> Reviewed-by: Jiri Slaby # tty/serial
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Uwe,
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_121164v1_full, please notify your bug team to
> > allow them
> > to document this new failure mode, which will reduce false positives in
> > CI.
>
> I don't think my patch results
: Uwe Kleine-König
that's correct! Thanks for the cleanup.
Reviewed-by: Andi Shyti
Andi
Hi Jonathan,
On Fri, Jul 21, 2023 at 07:05:58AM -0700, Jonathan Cavitt wrote:
> Refactor i915_coherent_map_type to be GT-centric rather than
> device-centric. Each GT may require different coherency
> handling due to hardware workarounds.
[...]
> -enum i915_map_type i915_coherent_map_type(struc
}
> + for_each_ggtt_vma(vma, obj)
> + i915_vma_flush_writes(vma);
yes, that's some duplicated code removed here! Thanks! I believe
I'm in time to add my:
Reviewed-by: Andi Shyti
Andi
> spin_unlock(&obj->vma.lock);
>
> i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> --
> 2.39.2
Hi Uwe,
On Fri, Jul 21, 2023 at 11:21:33PM +0200, Uwe Kleine-König wrote:
> to_i915 is defined as
>
> container_of(dev, struct drm_i915_private, drm);
>
> So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify
> accordingly.
>
> Signed-off-by: Uwe Kleine-König
pushed t
t wasn't explicitly
> injected.
>
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7061
> Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Andi Shyti
Andi
Hi,
On Tue, Jul 25, 2023 at 03:41:31PM +0200, Andrzej Hajda wrote:
> On 25.07.2023 12:33, Andi Shyti wrote:
> > Quite surprised to see that around i915 there are still i915->gt0
> > references. Replace them with the to_gt() helper.
> >
> > Signed-off-by: Andi Shyti
601 - 700 of 2148 matches
Mail list logo
