Hi Chris,
> When we know that we are inside the timeline mutex, or inside the
> submission flow (under active.lock or the holder's rcu lock), we know
> that the rq->hwsp is stable and we can use the simpler direct version.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem
Hi Chris,
On Mon, Dec 28, 2020 at 03:51:38PM +, Chris Wilson wrote:
> If supported by the backend, we can quickly look at the context's
> inflight engine rather than search along the active list to confirm.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shy
Hi Chris,
On Mon, Jan 04, 2021 at 11:51:40AM +, Chris Wilson wrote:
> A few missed PTR_ERR() upon create_gang() errors.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Hi Chris,
On Mon, Jan 04, 2021 at 11:51:41AM +, Chris Wilson wrote:
> Fixes: f170523a7b8e ("drm/i915/gt: Consolidate the CS timestamp clocks")
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx ma
progress(execlists));
> - GEM_BUG_ON(engine->execlists.pending[0]);
I would have split this in two patches, but it looks good anyway.
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
l/-/issues/2877
> Signed-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
s->signaler_active))
> - cpu_relax();
> }
As you are at it, you can also remove the braces, with that:
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 Mon, Jan 04, 2021 at 11:51:45AM +, Chris Wilson wrote:
> In the next patch, we remove the strict priority system and continuously
next patch?
[...]
> -static bool
> -timeslice_expired(const struct intel_engine_execlists *el,
> - const struct i915_request *rq)
> +s
lice
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
I don't know if you have answered all Tvrtko's question, but I
to me this looks good.
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/selftests/intel_memory_region.c
> b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> index 75839db63bea..59c58a276677 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.
: Chris Wilson
> Cc: Andi Shyti
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,
> +void intel_context_remove_breadcrumbs(struct intel_context *ce,
> + struct intel_breadcrumbs *b)
> +{
> + struct i915_request *rq, *rn;
> + bool release = false;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ce->signal_lock, flag
Hi Chris,
> > > > > diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > > > b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > > > index 75839db63bea..59c58a276677 100644
> > > > > --- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > > > +++ b/drivers/gpu
t; if (err)
> return err;
> @@ -2574,9 +2577,6 @@ static int eb_submit(struct i915_execbuffer *eb, struct
> i915_vma *batch)
> return err;
> }
>
> - if (intel_context_nopreempt(eb->context))
> - __set_
you've been lazy?
>
> This check is required to be under the lock, we have to be careful about
> not calling remove_signaling_context() from here and signal_irq_work.
> I put the unlocked check in the caller to avoid the function call as well.
OK...
Reviewed-by: Andi Shyti
Andi
___
Performing the same action from inside the breadcrumbs is
> intended to provide similar functionality for legacy ringbuffer
> submission.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing lis
Hi Chris,
> > > diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > index 75839db63bea..59c58a276677 100644
> > > --- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > > +++ b/drivers/gpu/drm/i915/selftests/
affect exposing a preemption capability to
> userspace, it does affect our internal decisions on whether to use
> timeslicing and semaphores between individual engines.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Carpenter
> Reviewed-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 Daniel,
> +/*
> + * This just sets wc mode for shmem helpers. vgem doesn't have any begin/end
> cpu
> + * access ioctls, there must use coherent memory or dma-buf sharing just wont
> + * work.
> + */
> +static struct drm_gem_object *vgem_gem_create_object(struct drm_device *dev,
> size_t size
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
Hi Lucas,
> > I am reproposing this patch exactly as it was proposed initially
> > where the original interfaces are kept where they have been
> > originally placed. It might generate some duplicated code but,
> > well, it's debugfs and I don't see any issue. In the future we
> > can transform the
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
Hi,
please ignore! I run the command from the history and forgot that
I had to update the patch file. :)
V3 of this patch is coming soon.
Andi
On Fri, Oct 08, 2021 at 01:22:48PM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The following interfaces:
>
>
Hi Sujaritha,
On Fri, Oct 08, 2021 at 01:44:54PM -0700, Sujaritha Sundaresan wrote:
> This patch adds the following new sysfs frequency attributes;
> - punit_req_freq_mhz
> - throttle_reason_status
> - throttle_reason_pl1
> - throttle_reason_pl2
> - throttle_reason_pl
Hi Ville,
> > + if (IS_CHERRYVIEW(i915)) {
> > + seq_printf(m, "Master Interrupt Control:\t%08x\n",
> > + intel_uncore_read(uncore, GEN8_MASTER_IRQ));
> > +
> > + for (i = 0; i < 4; i++) {
> > + seq_printf(m, "GT Interrupt IMR %d:\t%08x\
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
\-- reset
For backwards compatibility with ex
Hi Matt and Paulo,
> The first step of interrupt handling is to read a tile0 register that
> tells us in which tile the interrupt happened; we can then we read the
... we can then read the...
Andi
Hi,
sorry, just forgot to add the changelog
On Wed, Oct 13, 2021 at 12:17:38AM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The following interfaces:
>
> i915_wedged
> i915_forcewake_user
>
> are dependent on gt values. Put them inside gt/ and drop the
>
Hi Lucas,
On Wed, Oct 13, 2021 at 05:04:27PM -0700, Lucas De Marchi wrote:
> On Wed, Oct 13, 2021 at 12:17:38AM +0200, Andi Shyti wrote:
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
> >
>
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create a 'gt/' directory in sysfs which will contain gt0...gtN
directories related to each tile configured in the GPU. Move the
power management files inside tho
sting igt (and the slight
> > > > semantic difference between operating on the i915 abi entry
> > > > points and the deep gt info):
> > > >
> > > > dri/0
> > > > |
> > > > +-- i915_wedged
> > > > |
> > > > \-- i915_for
Hi Sujaritha,
[...]
> > +void intel_gt_sysfs_unregister(struct intel_gt *gt)
> > +{
> > +}
>
> Is there a reason for this function to not be populated ?
yes, there is, indeed, something missing here. There has been a
fix bout this floating around from Chris about sysfs_gt kobjects.
I will chec
's not a per-tile
> operation.
yes of course... we are writing to the master interrupt.
> We could probably simplify the dev_priv->gt.uncore parameter to just
> dev_priv->uncore to make this more obvious.
... it would be a nitpick, but nice to have.
Reviewed-by: Andi Shyti
Thanks,
Andi
; Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Matt Roper
Looks correct to me:
Reviewed-by: Andi Shyti
Andi
Hi Matt and Tvrtko,
[...]
> static int
> intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
> phys_addr)
we don't actually need 'id', it's gt->info.id. It's introduced in
patch 3 with the value '0' but it's not needed.
> {
> + struct drm_i915_private *i915 = gt->i915;
Hi Matt,
> +static int
> +intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
> phys_addr)
I have already r-b this, but, as I commented in patch 5, 'id' is
redundant. Can we remove it?
Andi
> +{
> + int ret;
> +
> + intel_uncore_init_early(gt->uncore, gt->i915);
> +
>
alize and you could
also insert it inside the for_each_gt()
Reviewed-by: Andi Shyti
Thanks,
Andi
> + unsigned int i;
>
> if (!intel_irqs_enabled(i915))
> return IRQ_NONE;
>
> - master_tile_ctl = dg1_master_intr_disable(regs);
> + ma
Hi Matt and Michal,
On Thu, Oct 28, 2021 at 08:28:16PM -0700, Matt Roper wrote:
> From: Michal Wajdeczko
>
> Update CT debug macros by including tile ID in all messages.
>
> Cc: Michał Winiarski
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Andi
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
\-- reset
Signed-of
Hi Tvrtko,
> We use GT parked status to estimate RC6 while not in use, however if RC6
> is not supported to start with that does not work very well and produces a
> false 100% RC6 readout.
>
> Fix by not advancing the estimated RC6 counter when feature is not
> supported.
>
> Signed-off-by: Tvrt
Hi Tvrtko,
> +static int
> +__i915_query(int i915, struct drm_i915_query *q)
> +{
> + if (igt_ioctl(i915, DRM_IOCTL_I915_QUERY, q))
> + return -errno;
> + return 0;
> +}
> +
> +static int
> +__i915_query_items(int i915, struct drm_i915_query_item *items, uint32_t
> n_items)
>
Hi Tvrtko,
> > > +static int
> > > +__i915_query(int i915, struct drm_i915_query *q)
> > > +{
> > > + if (igt_ioctl(i915, DRM_IOCTL_I915_QUERY, q))
> > > + return -errno;
> > > + return 0;
> > > +}
> > > +
> > > +static int
> > > +__i915_query_items(int i915, struct drm_i915_query_item *i
On Fri, May 17, 2019 at 12:25:25PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of hardcoding the VCS balancing engines, discover, both with the
> new engines query, or with the legacy get_param in the fallback case, so
> class based addressing always works.
>
> Signed-off-by:
> > > +static void query_engines(void)
> > > +{
> > > + struct i915_engine_class_instance *engines;
> > > + unsigned int num;
> > > +
> > > + if (__engines_queried)
> > > + return;
> > > +
> > > + __engines_queried = true;
> > > +
> > > + if (!has_query(fd) || !has_engine_query(fd)) {
[...
ng always works.
>
> v2:
> * Simplify has_engine_query check. (Andi)
> * Fix assert on uninitialized variable. (Andi)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Inte
Hi Tvrtko,
On Mon, May 20, 2019 at 03:47:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Test the new engine discovery query.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing
Hi Tvrtko,
On Wed, May 22, 2019 at 04:04:13PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use from_user_pointer when casting __u64 to a pointer.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi Shyti
Reviewed-by: Andi Sh
Hi Tvrtko,
On Wed, May 22, 2019 at 05:06:58PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Otherwise debug output looks messy when we trigger this.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi Shyti
Reviewed-by: Andi Sh
> Signed-off-by: Tvrtko Ursulin
Acked-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Tvrtko,
On Wed, May 22, 2019 at 02:14:17PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This enables static test enumeration to see the engine.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Thanks,
Andi
__
Chris didn't
like the boolean true/false meaning, indeed here I still check
with:
if ((flags & HANG) == 0) {
but then I forgot to update the test cases.
This means that this line needs to be
basic(i915, e, 0);
as the rest.
I'm sorry about the confusion! In an
Hi Chris,
On Thu, May 23, 2019 at 09:06:49AM +0100, Chris Wilson wrote:
> We need to keep igt working on linus and dif, or Joonas gets very upset.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Andi Shyti
> Cc: Joonas Lahtinen
looks good.
Reviewed-by: Andi Sh
engines can be addressed using the legacy
> execbuf API.)
>
> Instead extract the code into lower level __gem_class_instance_to_eb_flags
> helper which can return errors the caller can manually handle then.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi S
> - if (!gem_class_can_store_dword(fd, e->class))
> + if (!gem_class_can_store_dword(fd, e2->class))
> continue;
ops!
Reviewed-by: Andi Shyti
Thanks,
Andi
> igt_debug("Testin
On Thu, Apr 11, 2019 at 01:32:03PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-04-11 13:26:54)
> > From: Andi Shyti
> >
> > Replace the legacy for_each_engine* defines with the ones
> > implemented in the gem_engine_topology library.
>
On Thu, Apr 11, 2019 at 02:40:45PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2019-04-11 14:01:01)
> > On Thu, Apr 11, 2019 at 01:32:03PM +0100, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2019-04-11 13:26:54)
> > > > From: Andi Shyti
>
rtko Ursulin
> Cc: Lionel Landwerlin
> Cc: Dmitry Rogozhkin
> Cc: Tony Ye
> Cc: Andi Shyti
I was looking forward to a similar patch, it was also my intention
to send a similar one.
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel
Refactor the GT power management interface to work through the GT now
that it is under the control of gt/
Based on a patch by Chris Wilson.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 46
Hi Chris,
On Mon, Sep 02, 2019 at 05:15:43AM +0100, Chris Wilson wrote:
> Any use of __for_each_physical_engine breaks library use of
> for_each_physical_ring and in this case (e.g. gem_busy/close-race) leads
> to GPU hangs.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
&g
4);
> + scratch = gem_create(i915, 64<<10);
I guess this is a leftover, right?
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
> - num_threads = gem_available_fences(fd);
> + num_threads = gem_available_fences(fd) + 1;
any reason for this?
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/lis
Hi Chris,
just a few quick question from a first look,
> +/**
> + * __gem_context_set_persistence:
> + * @i915: open i915 drm file descriptor
> + * @ctx: i915 context id
> + * @state: desired persistence
> + *
> + * Like __gem_context_set_persistence(), except we assert on failure.
> + */
> +void
for the reduced mempressure (albeit we do not
> remove the swapping, the raison d'etre of the test), we increase the
> number of threads to force the system to reuse active fences, making it
> more stressful on the fence code.
Ah... OK :)
> Signed-off-by: Chris Wilson
>
Refactor the GT power management interface to work through the GT now
that it is under the control of gt/
Based on a patch by Chris Wilson.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 45
On Thu, Sep 05, 2019 at 02:34:55PM +0300, Mika Kuoppala wrote:
> From: Michel Thierry
>
> Gen12 has subtle changes in the reg state context offsets (some fields
> are gone, some are in a different location), compared to previous Gens.
>
> The simplest approach seems to be keeping Gen12 (and futu
On Thu, Sep 05, 2019 at 02:14:03PM +0300, Andi Shyti wrote:
> Refactor the GT power management interface to work through the GT now
> that it is under the control of gt/
>
> Based on a patch by Chris Wilson.
>
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
Reviewed-by
on
> Cc: Ville Syrjälä
Is Ville Cc'ed for real or just nominally?
looks straight forward,
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Sep 11, 2019 at 11:15:00AM +0100, Chris Wilson wrote:
> When using a spinner to trigger a hang, make it unpreemptable so that it
> appears like a true hang.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109661
> Signed-off-by: Chris Wilson
Reviewed-by: An
ould
> be used be directly rather than via dirtying the fb with a dummyload.
>
> Signed-off-by: Chris Wilson
looks OK,
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mail
Continuing the theme of breaking intel_pm.c up in a reasonable chunk of
powermanagement utilities, pull out the rc6 setup into its GT handler.
Based on a patch by Chris Wilson.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm
are going to provide an fd
of "some sort" :)
Reveiwed-by: Andi Shyti
Thanks,
Andi
> + test_reset_stress(i915, 0);
> + test_reset_stress(i915, TEST_WEDGE);
> + }
>
> *shared = 1;
> igt_waitchildren();
___
ika Kuoppala
> Cc: Daniele Ceraolo Spurio
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
just a nitpick, a warning that came out when I applied the
patches.
> struct i915_context_engines_load_balance balancer = {
> - { .name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE },
> + {
^
trailing whitespace
> + .next_e
Hi again,
I was thinking...
> +static void bonded(int i915, unsigned int flags)
> +#define CORK 0x1
> +{
> + struct class_instance *master_engines;
... shall we just make 'struct class_instance' generic in the
uapi? I do not expect every test that uses class and instance to
define its own st
Hi Chris,
On Fri, Mar 08, 2019 at 06:11:27PM +, Chris Wilson wrote:
> To exercise the new I915_CONTEXT_PARAM_ENGINES and interactions with
> gem_execbuf().
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Andi Shyti
> ---
I received three times this patch,
busy.busy, 1 << (e->class + 16));
> + } else {
> + igt_assert_eq(busy.busy, 0);
> + }
> +
(from the last review) this is not kernel style, not that I care
much, but I thought you did.
You can add Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
verything "but" what you say in the
commit log :)
>
> Reported-by: Petri Latvala
> Fixes: 17c77e7b0c3c ("lib/i915: add gem_engine_topology library and for_each
> loop definition")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Petri Lat
ines = { };
> uint32_t contexts[65];
> - unsigned int nengine;
> int n, qlen;
>
> - nengine = 0;
> - for_each_physical_engine(fd, e) {
> - engine[nengine] = e;
> - name[nengine] = e__->name;
> - nengine++;
> - }
> - igt_require(nengine);
> + engines = intel_init_engine_list(fd, 0);
> + igt_require(engines.nengines);
Off-topic:
This I guess can be the "flags" mapping that Chris was suggesting
once, I guess we can achieve that by just doing the above without
adding helpers (which would drive crazy people like me).
The rest of the patch I trust you it works :)
(however the devotion to whatever is legacy doesn't leave me with
a good taste after all the work done)
You can add my Reviewed-by: Andi Shyti
Thanks, this patch clarifies a few more things as well,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
formatting changes.
> """
>
> ;)
>
> File to many lines falling of 80 char so I tidied it alongside.
I'm not saying that this change is wrong, just that it's
out of the context of the patch and it should lay in a different
change (I'm
Hi,
On Thu, Jun 16, 2022 at 05:31:05PM +0530, Anshuman Gupta wrote:
> From: Tvrtko Ursulin
>
> Store a pointer to respective local memory region in intel_gt so it can be
> used when memory local to a GT needs to be allocated.
>
> Cc: Andi Shyti
> Signed-off-by: Tvrtko Urs
ned-off-by: Chris Wilson
> Cc: Fei Yang
> Cc: Andi Shyti
> Cc: sta...@vger.kernel.org
> Acked-by: Thomas Hellström
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Andi
i915: Flush TLBs before releasing backing store")
>
> Signed-off-by: Chris Wilson
> Cc: Fei Yang
> Cc: Andi Shyti
> Cc: sta...@vger.kernel.org
> Acked-by: Thomas Hellström
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Thanks,
Andi
r has access to the TLB's in each engine.
>
> Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
>
> Signed-off-by: Chris Wilson
> Cc: Fei Yang
> Cc: Andi Shyti
> Cc: sta...@vger.kernel.org
> Acked-by: Thomas Hellström
> Signed
efetch.
>
> We only need to invalidate the TLB if they are accessible by the user.
>
> Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
>
> Signed-off-by: Chris Wilson
> Cc: Fei Yang
> Cc: Andi Shyti
> Cc: sta...@vger.kernel.org
Reported-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Andi Shyti
> Cc: sta...@vger.kernel.org
> Acked-by: Thomas Hellström
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Thanks,
Andi
d-by: Thomas Hellström
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Andi Shyti
Thanks,
Andi
nment), step) -
> min_alignment;
> + hole_end > addr && hole_end - addr >= 2 * min_alignment;
Reviewed-by: Andi Shyti
Thanks,
Andi
Cc: sta...@vger.kernel.org # Up to 4.4
> Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
> Reported-by: Mauro Carvalho Chehab
> Tested-by: Mauro Carvalho Chehab
> Reviewed-by: Mauro Carvalho Chehab
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> C
off-by: Chris Wilson
> Cc: Mika Kuoppala
> Reviewed-by: Andi Shyti
> Acked-by: Thomas Hellström
> Signed-off-by: Mauro Carvalho Chehab
sorry for the delay but I wanted to understand what has been
agreed between you and Tvrtko about the Cc'ing the stable list.
Anyway, I confirm m
15/gem: Drop free_work for GEM contexts")
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Cc: # v5.12+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
drivers/gpu/drm/i915/i915_perf.c| 18 ++
lson
> Signed-off-by: Matthew Auld
Reviewed-by: Andi Shyti
Andi
Hi,
[...]
> @@ -1265,10 +1264,15 @@ static void i915_gem_context_release_work(struct
> work_struct *work)
> struct i915_gem_context *ctx = container_of(work, typeof(*ctx),
> release_work);
> struct i915_address_space *vm;
> + unsi
Hi,
[...]
> > +/*
> > + * VM_BIND feature version supported.
> > + *
> > + * The following versions of VM_BIND have been defined:
> > + *
> > + * 0: No VM_BIND support.
> > + *
> > + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings
> > created
> > + * previously with VM_BIND, t
Hi,
[...]
> > @@ -28,7 +28,6 @@ static u32 object_max_page_size(struct
> > intel_memory_region **placements,
> > max_page_size = max_t(u32, max_page_size, mr-
> > >min_page_size);
> > }
> >
> > - GEM_BUG_ON(!max_page_size);
> > return max_page_size;
> > }
Hi,
> It seems we are duplicating a lot of code from i915_execbuffer.c. Did
> you consider
yeah... while reading the code I was thinking the same then I see
that you made the same comment. Perhaps we need to group
commonalities and make common library for execbuf 2 and 3.
Andi
Hi Rodrigo, Chris and Karolina,
On Thu, Jul 07, 2022 at 01:57:52PM -0400, Rodrigo Vivi wrote:
> On Tue, Jul 05, 2022 at 12:57:17PM +0200, Karolina Drobnik wrote:
> > From: Chris Wilson
> >
> > We employ a "waitboost" heuristic to detect when userspace is stalled
> > waiting for results from earl
by: Chris Wilson
> Signed-off-by: Karolina Drobnik
Reviewed-by: Andi Shyti
Andi
> ---
> drivers/gpu/drm/i915/i915_active.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_active.c
> b/drivers/gpu/drm/i915/i915_active.c
> in
en if it's a stupid nitpick,
if it gets applied it would be very difficult to get it fixed[*].
Didn't checkpatch.pl complain about it?
If you are going to resend it, you can add my:
Reviewed-by: Andi Shyti
also here.
Thanks,
Andi
[*] Because just minor coding style patches are genera
1 - 100 of 2101 matches
Mail list logo
