_gem_active_get_unlocked()
> (Starting to get too unwieldy.)
It's less confusing.
I assume you intend to extend the rcu_read_lock() section?
Regards, Joonas
> -Chris
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
__
27;t be interrupted */
> WARN_ON(i915_gem_object_unbind(obj));
> WARN_ON(i915_gem_object_put_pages(obj));
> -
> - dev_priv->mm.interruptible = was_interruptible;
> }
>
> i915_gem_object_put(obj);
--
Joonas Lahtinen
Open
On ke, 2016-08-03 at 14:36 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 04:23:16PM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > /**
> > > @@ -1647,6 +1629,15 @@ int i915_gem_fault
probing for the hardware location (part of the PCI BAR) and
> later establishing the kernel resources for it.
>
> Signed-off-by: Chris Wilson
The whole probing should be removed and just relayed from the early
quirks code to the driver, but that's going to be after these series.
Re
44
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -365,8 +365,6 @@ struct i915_ggtt {
> bool do_idle_maps;
>
> int mtrr;
> -
> - int (*probe)(struct i915_ggtt *ggtt);
> };
>
> struct i915_hw_ppgtt {
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
the norm in function parameters.
>
> Signed-off-by: Chris Wilson
Pretty mechanical, so unless you hid an easter egg;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx
On ke, 2016-08-03 at 14:42 +0100, Chris Wilson wrote:
> - BUG_ON(mappable_end > end);
This gets lost, with that restored somewhere or explained in commit
message.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corpo
ONFIG_DRM_I915_WERROR) := -Werror
> +subdir-ccflags-$(CONFIG_DRM_I915_KCOV) := $(CFLAGS_KCOV)
> subdir-ccflags-y += \
> $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
the norm in function parameters.
>
> v2: Include all the probe functions
>
> Signed-off-by: Chris Wilson
Mechanical.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Inte
ecific probe.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
ggtt->size can be added back when there's need for it, so;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
i915_gem_shrinker_lock(&dev_priv->drm, &slu->unlock))
> + break;
> +
> schedule_timeout_killable(1);
> if (fatal_signal_pending(current))
> return false;
> +
> if (--timeout == 0) {
>
is brings us into line with the other
> delayed checks (and madvise in general).
>
> Signed-off-by: Chris Wilson
Don't necessarily agree with all the "== 0", because it's in the
minority but;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas
On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> After removing the user of this wart, we can remove the wart entirely.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
--
Joonas Lahtinen
Open Source Technology Center
Intel Co
> + if (ret)
> + goto out_unlocked;
> +
> + intel_runtime_pm_get(dev_priv);
>
As discussed in IRC, pread_ioctl does not take RPM for the fallback
path, it should.
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> +
out_ns : NULL,
> + to_rps_client(file));
Long line.
This and explanation touched up,
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
m/i915: Support for pread/pwrite ...")
> Reported-by: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> Signed-off-by: Chris Wilson
> Cc: Ankitprasad Sharma
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: drm-intel-fi...@lists.freedesktop.org
> ---
> drivers/gpu/
after we lookup the engine's id, we double check that
This double check is nowhere to be seen, time to update this comment
too?
The code itself is quite OK, but the comments mislead my understanding
of the code again.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Inte
mutex_unlock(&dev->struct_mutex);
> + } else {
> + ret = 0;
> +unref:
No, nope, nein, ei, njet, inte, nack; this shall not pass.
Most inappropriate use of goto I've seen shortly.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3853,11 +3853,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> *data,
> goto unlock;
> }
>
> - if (i915_gem_obj_is_pinned(obj)) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
Does not this
ol over the flags
> field was too noisy for a simple patch. Note, that we can use the lower
s/, / /,s/can/could/
With that,
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> With all callers now not playing tricks with dropping the struct_mutex
> between waiting and retiring, we can assert that the request is ready to
> be retired.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
&
modifier[0] == I915_FORMAT_MOD_X_TILED)) {
> DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
> return -EINVAL;
> }
> } else {
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On to, 2016-08-04 at 12:34 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 02:17:22PM +0300, Joonas Lahtinen wrote:
> >
> > >
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2465,9 +2
On to, 2016-08-04 at 11:42 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 01:36:24PM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > We don't need to incur the overhead of checking whether the ob
On to, 2016-08-04 at 07:30 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 09:12:07AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-08-03 at 20:38 +0100, Chris Wilson wrote:
> > >
> > > In the next merge, we can build support for kcov at the individual
importantly, accessing
> dev_priv->mm.interruptible not under any controlling lock. That takes
> passing around bool interruptible and suddenly we have a bigger patch.
> :|
Not sure what to do with this information, will you send a new
revision?
Regards, Joonas
&
On ke, 2016-08-03 at 14:43 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 04:30:35PM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-08-03 at 13:04 +0100, Chris Wilson wrote:
> > >
> > > On Wed, Aug 03, 2016 at 12:56:39PM +0100, Chris Wilson wrote:
> &
On ke, 2016-08-03 at 14:49 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 04:43:38PM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > Inside the kthread context, we can't be interrupted by signals
On to, 2016-08-04 at 08:30 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 10:25:42AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > If we make the observation that mmap-offsets are only released whe
On to, 2016-08-04 at 11:02 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 11:26:04AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > With a bit of care (and leniency) we can iterate over the o
On to, 2016-08-04 at 12:41 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 02:17:22PM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers
that we gain further contention reduction, and overall the code
> become simpler due to the reduced mutex dancing.
>
> v2: Move i915_gem_fault tracepoint to start of function, before the
> unlocked wait.
"Move i915_gem_fault tracepoint *back* to start of ..." to be exact :)
R
again.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ret |= !list_empty(&engine->request_list);
> + ret |= intel_engine_is_active(engine);
|= always makes me think of bitfields because, well -- it is bitwise
operation :P
if (intel_engine_is_active(engine))
ret = true;
But I can l
dle() takes the interruptible status as the other
> action, dma_map_sg(), is independent of i915.ko)
>
> Signed-off-by: Chris Wilson
Looks far less hackish, good;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology
ut detection should be more robust too;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
pts to set a tiling mode other than NONE, X or Y.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.
ce for compiler hints (or not as it is a bitfield)
> v3: READ_ONCE, obj->pin_display is not a bitfield anymore
> v4: Don't be creative with goto.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
This is readable, and it wasn't that hard.
Reviewed-by: Joonas Lahtinen
eqno.
> + *
> + * So after we lookup the engine's id, we double check that
> + * the active request is the same and only then do we add it
> + * into the busy set.
> + */
> + rcu_re
et(dev_priv);
> +
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + goto err_rpm;
> +
> + trace_i915_gem_object_pwrite(obj, args->offset, args->size);
This trace is still moved, maybe add your reasoning to commit message.
With those addressed (a
On pe, 2016-08-05 at 07:51 +0100, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 09:16:21AM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote:
> > >
> > > @@ -486,7 +486,8 @@ void __i915_add_request(struct drm
On pe, 2016-08-05 at 08:34 +0100, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 10:05:38AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > >
> > > By applying the same logic as for wait-ioctl, we can query whet
Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190125023005.1007-1-ch...@chris-wilson.
Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> Hi all,
>
> I would like to have some Acked-by's from you, the distro media
> folks Cc'd here, to document your intent to start using Intel's
> new media driver[1]. So if you recognize yourself (or are otherwise
Quoting Stéphane Marchesin (2019-02-05 06:16:48)
> On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter wrote:
> >
> > On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote:
> > > Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> > > > Hi all,
> > > &
compare function
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings
for objects")
Reported-by: Adam Zabrocki
Suggested-by: Linus Torvalds
Signed-off-by: Joonas Lahtinen
Cc: # v4.0+
Cc: Akash Goel
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Adam Zabrocki
R
Add err goto label and use it when VMA can't be established or changes
underneath.
v2:
- Dropping Fixes: as it's indeed impossible to race an object to the
error address. (Chris)
v3:
- Use IS_ERR_VALUE (Chris)
Reported-by: Adam Zabrocki
Signed-off-by: Joonas Lahtinen
Cc: Chris
compare function
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings
for objects")
Reported-by: Adam Zabrocki
Suggested-by: Linus Torvalds
Signed-off-by: Joonas Lahtinen
Cc: # v4.0+
Cc: Akash Goel
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Adam Zabrocki
R
Quoting Joonas Lahtinen (2019-01-07 10:56:55)
> Make sure the underlying VMA in the process address space is the
> same as it was during vm_mmap to avoid applying WC to wrong VMA.
>
> A more long-term solution would be to have vm_mmap_locked variant
> in linux/mmap.h for when calle
ory) or any other global resources, see above for the long term
> goal.
Code checks out.
Some Testcase: links and some relative perf numbers might be in place.
It's pretty arbitarily tuned algorithm, after all :)
Reviewed-by: Joonas Lahtinen
Regards, Joonas
>
> Signed-off-by
onable for super low SKUs.
But the SIGALRM handler should be inherted, so that's a red herring.
With the commit message and title adjusted for warming up the context:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> tests/i915/gem_exec_schedule.c | 19 +--
> 1
+ Petri for the fact that igt_fork is actually igt_forkoontula and
messes up set up signal handlers when transitioning to child.
Quoting Chris Wilson (2019-02-08 11:01:55)
> Quoting Joonas Lahtinen (2019-02-08 08:59:53)
> > Quoting Chris Wilson (2019-02-07 23:03:08)
> > >
eek like broken libc.
The patch below is just next level of paranoia, so:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
>
> References https://bugs.freedesktop.org/show_bug.cgi?id=109584
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> tests/i915/gem_exec_sche
Quoting Rodrigo Vivi (2019-02-12 01:51:18)
> On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> > Hi all,
> >
> > Here's the typed component topic branch.
> >
> > drm-intel maintainers: Please pull, I need this for the mei hdcp work from
> > Ram.
>
> I'm about to handle dinq to Jo
: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Jani Nikula
Yeah, makes sense as I've had to bring this up on multiple
occasions.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> include/uapi/drm/i915_drm.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --gi
+ dri-devel mailing list, especially for the buddy allocator part
Quoting Dave Airlie (2019-02-15 02:47:07)
> On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote:
> >
> > In preparation for upcoming devices with device local memory, introduce the
> > concept of different memory regions, and a simple
Quoting Daniel Vetter (2019-02-19 09:55:27)
> Hi all,
>
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
> Plus one small stati
Quoting Lionel Landwerlin (2019-02-04 17:30:12)
> On 22/01/2019 16:25, Joonas Lahtinen wrote:
> > Quoting Lionel Landwerlin (2019-01-16 17:36:22)
> >> With the currently available parameters for the i915-perf stream,
> >> there are still situations that are not wel
Quoting Dave Airlie (2019-02-25 12:24:48)
> On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
> wrote:
> >
> > + dri-devel mailing list, especially for the buddy allocator part
> >
> > Quoting Dave Airlie (2019-02-15 02:47:07)
> > > On Fri, 15
Quoting Alex Deucher (2019-02-25 21:31:43)
> On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
> wrote:
> >
> > Quoting Dave Airlie (2019-02-25 12:24:48)
> > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
> > > wrote:
> > > >
> > > >
Quoting Christian König (2019-02-27 04:17:01)
> Am 27.02.19 um 00:04 schrieb Dave Airlie:
> >>> At the end of the day, I don't really care that much. I get it, we
> >>> all have large projects with scarce resources. I just think a few
> >>> years down the road we'll all regret it as a community.
I take it that both instances are supposed to call bitmap_zalloc?
If you can send a v2 that compiles, I can merge it after it passes the
CI.
Regards, Joonas
Quoting Andy Shevchenko (2019-03-04 11:03:20)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns
27;s also update the "workaround" naming.
> >
> > Yeah, in Mesa we are not implementing the SIP, so we can't do
> > thread-level preemption yet and need the granularity to be no higher
> > than thread group level.
> >
> > Acked-by: Rafael Antog
Quoting Ho, Kenny (2018-11-27 17:41:17)
> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
> wrote:
> > I think a more abstract property "% of GPU (processing power)" might
> > be a more universal approach. One can then implement that through
> > subdividing
Quoting Jani Nikula (2018-11-28 10:02:22)
> On Tue, 06 Nov 2018, Lucas De Marchi wrote:
> > From: Rodrigo Vivi
> >
> > RANGE makes it longer, but clear. We are also going to add a check for
> > the display part, so make rename to GT.
>
> I also still have my doubts about this patch I'm afraid. I
drm/i915/gvt: ensure gpu is powered before do i915_gem_gtt_insert
Joonas Lahtinen (1):
Merge tag 'gvt-fixes-2018-11-26' of https://github.com/intel/gvt-linux
into drm-intel-fixes
Xinyun Liu (1):
drm/i915/gvt: not to touch undefined MOCS registers
drivers/gpu/drm/i915/gv
Quoting Zhenyu Wang (2018-12-04 07:06:33)
>
> Hi,
>
> Just one BDW regression fix for tiling mode format return
> on vfio gfx dmabuf.
Pulled.
Regards, Joonas
>
> Thanks
> --
> The following changes since commit 7513edbc096a006f967eaf39088091442e623b83:
>
> drm/i915/gvt: Avoid use-after-fre
Quoting Kuehling, Felix (2018-12-03 22:55:16)
>
> On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> > Quoting Ho, Kenny (2018-11-27 17:41:17)
> >> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
> >> wrote:
> >>> I think a more abstract property &quo
1:47 +0200)
- Fix for system crash after GPU hang (Bugzilla #107945)
- GVT fix for guest graphics corruption
(https://github.com/intel/gvt-linux/issues/61)
--------
Joonas Lahtinen (1):
Merg
e GPU relocs harder with gen3")
> Testcase: igt/gem_tiled_fence_blits # blb/pnv
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
As we're not going to be adding read-only scratch pages for Gen2 (I
think it's a few generations too old to have it :P), this is:
Reviewed-by
sible to bisect
which commit fixed it, and backport that. On the other hand, if it's
still reproducible, we know we're not spending time on something we
already fixed, and the priority gets a bump.
> If you think it is useful, I can try to update my machine to
> linux-next.
linux-next is closer to drm-tip, so it's better. Do you have some
specific reason for not wanting to run drm-tip (but linux-next is still
ok)?
Regards, Joonas
>
> Best regards,
> Pavel
>
--
Joonas Lahtinen
Open Source Graphics Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#5
> [31850.668487] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET74WW
> (1.44 ) 03/13/2018
>
> Dmesg and /sys/class/drm/card0/error are attached.
>
> Best regards,
> Pavel
--
Joonas Lahtinen
Open Source
l and Gen3)
Chris Wilson (3):
drm/i915/execlists: Apply a full mb before execution for Braswell
drm/i915: Allocate a common scratch page
drm/i915: Flush GPU relocs harder for gen3
Joonas Lahtinen (1):
Merge tag 'gvt-fixes-2018-12-04' of https://github.com/i
Should be fixed already with an updated -fixes.
Regards, Joonas
Quoting kbuild test robot (2018-12-12 10:31:58)
> tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
> head: eeb139ca4b24d515265ad75f668333431896b1aa
> commit: eeb139ca4b24d515265ad75f668333431896b1aa [5/5] drm/i9
Quoting Pavel Machek (2018-12-12 20:29:02)
> Hi!
>
> > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like
> > > > > > > > a genuine
> > > > > > > > memory corruption (1 bit flipped):
> > > > > > > >
> > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > >
emoved definitions of reserved entries. (Michal)
> > Increased limit of entries sent to the hardware on gen11+.
> >
> > BSpec: 34007
> > BSpec: 560
> > Signed-off-by: Tomasz Lis
> > Reviewed-by: Daniele Ceraolo Spurio (v4)
>
> R-b upgrade needed here as well.
&g
Quoting Ankit Navik (2018-12-11 12:14:17)
> drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel
>
> Current GPU configuration code for i915 does not allow us to change
> EU/Slice/Sub-slice configuration dynamically. Its done only once while context
> is created.
>
> Whi
on trigger functions to one. (Chris)
> > Fixed conyext state tonot assume COMPLETED_MASK after preemption,
> > since idle-to-idle case will not have it set.
> >
> > v4: Simplified needs_preempt_context() change. (Daniele)
> > Removed clearing HWACK flag
+ Adding Linus, Dave and Daniel
(because by my knowledge, we're beating a dead horse here)
Quoting Steven Rostedt (2018-12-18 04:14:17)
> On Mon, 17 Dec 2018 18:26:03 -0700
> Michael Sartain wrote:
>
> > Ftrace and perf are fantastic, stable, very well known, and documented with
> > ecosystems b
Quoting Pierre-Loup A. Griffais (2018-12-18 20:14:49)
>
> On 12/18/18 3:33 AM, Chris Wilson wrote:
> > Quoting Michael Sartain (2018-12-18 01:26:03)
> >> I'm writing to try and make a case for Tvrtko's "Remove
> >> DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig" patch:
> >>
> >>https://lists.freedeskt
Quoting Zhenyu Wang (2018-11-26 08:05:53)
> This trys to export all required i915 functions for GVT.
We have couple of __ prefixed functions proposed here. That'd mostly
mean whoever wrote the function intended it to be used only at file
scope for its nature (or with special caution outside of fil
e just copied
> register list. So GVT will use initial dump instead when load.
As discussed in IRC, lets try to get the golden MMIO concept going, so
we could completely get rid of intel_gvt.c.
Regards, Joonas
>
> Cc: Joonas Lahtinen
> Signed-off-by: Zhenyu Wang
> ---
> driver
en MMIO state (instead of capturing at boot).
With those This should both expedite the i915 driver loading on DOM0,
when GVT can be loaded as secondary module. And the golden MMIO state
instead of capturing from host would avoid leaking any changes in host
configuration (say, due to BIOS updat
Quoting Steven Rostedt (2018-12-19 21:22:57)
> On Wed, 19 Dec 2018 12:08:18 +0200
> Joonas Lahtinen wrote:
>
> > To me, it seems almost as if folks are too preoccupied with thinking if
> > we somehow can do this through tracepoints, to stop and actually think
> > if we
Quoting Michael Sartain (2018-12-20 20:27:19)
> On Wed, Dec 19, 2018, at 12:22 PM, Steven Rostedt wrote:
> > On Wed, 19 Dec 2018 12:08:18 +0200
> > Joonas Lahtinen wrote:
> >·
> > > To me, it seems almost as if folks are too preoccupied with thinking if
> &
Quoting Pavel Machek (2018-12-27 10:34:39)
> Hi!
>
> > > > > If you think it is useful, I can try to update my machine to
> > > > > linux-next.
> > > >
> > > > linux-next is closer to drm-tip, so it's better. Do you have some
> > > > specific reason for not wanting to run drm-tip (but linux-next
Quoting Eric Wong (2018-12-27 13:49:48)
> I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> chipset) and hit some kernel panics while trying to view
> image/animation-intensive stuff in Firefox (X11) unless I use
> "iommu_intel=igfx_off".
>
> With Debian stable backport kernels, "linux-
Quoting Eric Wong (2019-01-04 03:06:26)
> Joonas Lahtinen wrote:
> > Quoting Eric Wong (2018-12-27 13:49:48)
> > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > > chipset) and hit some kernel panics while trying to view
> > > image/anima
Add err goto label and use it when VMA can't be established or changes
underneath.
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings
for objects")
Reported-by: Adam Zabrocki
Signed-off-by: Joonas Lahtinen
Cc: # v4.0+
Cc: Akash Goel
Cc: Chris Wil
("drm/i915: Support creation of unbound wc user mappings
for objects")
Reported-by: Adam Zabrocki
Suggested-by: Linus Torvalds
Signed-off-by: Joonas Lahtinen
Cc: # v4.0+
Cc: Akash Goel
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Adam Zabrocki
---
drivers/gpu/drm/i915/i915_
drm/i915/intel_device_info.c:727: warning: Excess function
> parameter 'info' description in 'intel_device_info_runtime_init'
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Regards, Joonas
_
Quoting José Roberto de Souza (2019-01-04 19:37:00)
> According to Workaround database ICL also needs
> WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> fine-granularity preemptions per-context.
I must wonder where is the userspace component that needs this, and why
it hasn't
Indent GuC/WOPCM documentation correctly to reside under
"Memory Management and Command Submission" section to avoid
it escaping to the upper level navigation.
Signed-off-by: Joonas Lahtinen
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
Documentation/gpu/i91
The referenced documentation section has been removed. Remove the
link to avoid warning when building the documentation.
Signed-off-by: Joonas Lahtinen
Cc: Chris Wilson
Cc: Matthew Auld
---
Documentation/gpu/i915.rst | 9 -
1 file changed, 9 deletions(-)
diff --git a/Documentation
To ensure cross-driver locking compatibility, document the expected
guidelines for implementing the GEM locking in i915. Note that this
is a description of how things should end up after being reworked,
and does not reflect the current state of things.
Signed-off-by: Joonas Lahtinen
Signed-off
Quoting Jani Nikula (2019-09-02 21:29:16)
> Add a helper instead of open coding the plurals in debug logs. Also
> fixes the case for "0 display pipes available."
>
> Signed-off-by: Jani Nikula
>
> ---
>
> I stumbled upon the pipes one while working on ->num_pipes. I honestly
> thought we'd have
Quoting Chris Wilson (2019-09-01 14:04:31)
> This function was never used and probably will never be used, so remove
> it.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing li
Quoting Prathap Kumar Valsan (2019-08-26 01:48:01)
> To provide shared last-level-cache isolation to cpu workloads running
> concurrently with gpu workloads, the gpu allocation of cache lines needs
> to be restricted to certain ways. Currently GPU hardware supports four
> class-of-service(CLOS) lev
Quoting Dave Airlie (2019-08-13 22:20:52)
> On Sat, 10 Aug 2019 at 08:26, Matthew Auld wrote:
> >
> > In preparation for upcoming devices with device local memory, introduce the
> > concept of different memory regions, and a simple buddy allocator to manage
> > them in i915.
> >
> > One of the con
Quoting Maarten Lankhorst (2019-03-07 11:48:24)
> Hi Sean and Joonas,
>
> Here's a pull request for HDR format enabling in i915. Can this be pulled to
> drm-misc-next and dinq?
I was travelling on Fri, so sorry for delay. This is now pulled to dinq,
too.
Regards, Joonas
>
> Cheers,
> Maarten
301 - 400 of 2919 matches
Mail list logo
