Re: [Intel-gfx] [PATCH 20/24] drm/i915: Group all the global context information together

On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > Create a substruct to hold all the global context state under > drm_i915_private. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen

Re: [Intel-gfx] [PATCH 12/24] drm/i915: Store a persistent reference for an object in the execbuffer cache

On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > If we take a reference to the object/vma when it is first used in an > execbuf, we can keep that reference until the object's file-local handle > is closed. Thereby saving a frequent ref/unref pair. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Move engine HWS setup into one shared function

On ke, 2017-05-17 at 18:42 +, Michal Wajdeczko wrote: > Similar code was duplicated in ringbuffer.c and lrc.c > Lets share the code and move it to engine_cs.c > While around, move execlist enabling into separate inline > function, as this will make future patches simpler. > > Suggested-by:

Re: [Intel-gfx] [PATCH] drm/i915: Use a cached mapping for the physical HWS

On Fri, May 19, 2017 at 11:53:17AM +0300, Joonas Lahtinen wrote: > On ke, 2017-05-17 at 14:02 +0100, Chris Wilson wrote: > > Older gen use a physical address for the hardware status page, for which > > we use cache-coherent writes. As the writes are into the cpu cache, we use > > a normal WB

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/g4x: Improve gpu reset reliability

== Series Details == Series: drm/i915/g4x: Improve gpu reset reliability URL : https://patchwork.freedesktop.org/series/24680/ State : failure == Summary == Series 24680v1 drm/i915/g4x: Improve gpu reset reliability https://patchwork.freedesktop.org/api/1.0/series/24680/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: Remove last submission result from debugfs

On Fri, May 19, 2017 at 11:38:29AM +0300, Joonas Lahtinen wrote: > On to, 2017-05-18 at 11:31 +, Michal Wajdeczko wrote: > > Debugfs does not seems to be a right place to display transient data. > > If we want to capture errors, we should log them. > > > > Signed-off-by: Michal Wajdeczko

Re: [Intel-gfx] Call trace on 4.12.0-rc1

Hi, On Thu, May 18, 2017 at 12:08:23PM +0200, Hans de Goede wrote: > Hi, > > On 17-05-17 11:36, Ville Syrjälä wrote: > >On Tue, May 16, 2017 at 10:43:39PM +0200, Hans de Goede wrote: > >>Hi, > >> > >>On 05/16/2017 09:55 PM, FKr wrote: > >>>Hi, > >>>I'm using 4.12.0-rc1 from

Re: [Intel-gfx] [PATCH 14/17] drm/i915/debugfs: include some gtt_page_size metrics

On Tue, May 16, 2017 at 09:29:45AM +0100, Matthew Auld wrote: > Good to know, mostly for debugging purposes. Can we also get similar information into the error state. Copying obj->mm.page_sizes across is easy enough, recording whether gtt was using huge pages, I leave as an exercise to the

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/g4x: Improve gpu reset reliability

Patchwork writes: > == Series Details == > > Series: drm/i915/g4x: Improve gpu reset reliability > URL : https://patchwork.freedesktop.org/series/24680/ > State : failure > > == Summary == > > Series 24680v1 drm/i915/g4x: Improve gpu reset reliability >

Re: [Intel-gfx] [PATCH 03/24] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

On Thu, May 18, 2017 at 10:46:17AM +0100, Chris Wilson wrote: > For ease of use (i.e. avoiding a few checks and function calls), store > the object's cache coherency next to the cache is dirty bit. > > Signed-off-by: Chris Wilson > Cc: Dongwon Kim

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: Remove last submission result from debugfs

On Thu, May 18, 2017 at 11:31:04AM +, Michal Wajdeczko wrote: > Debugfs does not seems to be a right place to display transient data. > If we want to capture errors, we should log them. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 10/24] drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations

On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > If we write a relocation into the buffer, we require our own implicit > synchronisation added after the start of the execbuf, outside of the > user's control. As we may end up clflushing, or doing the patch itself > on the GPU, asynchronously

Re: [Intel-gfx] [PATCH 18/24] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

On Thu, May 18, 2017 at 10:46:32AM +0100, Chris Wilson wrote: > When userspace is doing most of the work, avoiding relocs (using > NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we > still spend a lot of time processing the arrays in execbuf, even though > we now should have

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: Remove last submission result from debugfs

On to, 2017-05-18 at 11:31 +, Michal Wajdeczko wrote: > Debugfs does not seems to be a right place to display transient data. > If we want to capture errors, we should log them. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: set initialised only when init_context callback is NULL (rev2)

On Fri, 19 May 2017, Zhenyu Wang wrote: > On 2017.05.12 12:44:48 +0100, Chris Wilson wrote: >> On Fri, May 12, 2017 at 11:34:21AM -, Patchwork wrote: >> > == Series Details == >> > >> > Series: drm/i915: set initialised only when init_context callback is NULL >> >

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/g4x: Improve gpu reset reliability

Chris Wilson writes: > On Thu, May 18, 2017 at 05:28:41PM +0300, Mika Kuoppala wrote: >> ELK seems to very picky about the preconditions to reset. >> Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does >> not like if reset occurs when there is active ring. >>

Re: [Intel-gfx] [PATCH 01/24] drm/i915/selftests: Pretend to be a gfx pci device

On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > Set the class on our mock pci device to GFX. This should be useful for > utilities like intel-iommu that special case gfx devices. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=101080 > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 17/24] drm/i915: Stash a pointer to the obj's resv in the vma

On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > During execbuf, a mandatory step is that we add this request (this > fence) to each object's reservation_object. Inside execbuf, we track the > vma, and to add the fence to the reservation_object then means having to > first chase the obj,

Re: [Intel-gfx] [PATCH 22/24] drm/i915: Enable rcu-only context lookups

On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > Whilst the contents of the context is still protected by the big > struct_mutex, this is not much of an improvement. It is just one tiny > step towards reducing our BKL. > > Signed-off-by: Chris Wilson > +++

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix 90/270 rotated coordinates for FBC

On 31/03/2017 19:00, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä The clipped src coordinates have already been rotated by 270 degrees for when the plane rotation is 90/270 degrees, hence the FBC code should no longer swap the width and height. Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Use a cached mapping for the physical HWS

On ke, 2017-05-17 at 14:02 +0100, Chris Wilson wrote: > Older gen use a physical address for the hardware status page, for which > we use cache-coherent writes. As the writes are into the cpu cache, we use > a normal WB mapped page to read the HWS, used for our seqno tracking. > > Anecdotally, I

Re: [Intel-gfx] [PATCH 23/24] drm/i915: Keep a recent cache of freed contexts objects for reuse

On 18/05/2017 15:19, Chris Wilson wrote: On Thu, May 18, 2017 at 02:52:41PM +0100, Tvrtko Ursulin wrote: On 18/05/2017 10:46, Chris Wilson wrote: Keep the recently freed context objects for reuse. This allows us to use the current GGTT bindings and dma bound pages, avoiding any clflushes as

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/gvt: Dmabuf support for GVT-g

> +/** > + * Ioctl to query plane info or create dma-buf > + */ > +#define INTEL_VGPU_QUERY_DMABUF 0 > +#define INTEL_VGPU_GENERATE_DMABUF 1 This should use _IO* #defines. > +struct intel_vgpu_dmabuf { > + __u32 plane_id; > + /* out */ > + __u32 fd; > + __u32

Re: [Intel-gfx] [PATCH 01/24] drm/i915/selftests: Pretend to be a gfx pci device

On Fri, May 19, 2017 at 12:02:48PM +0300, Joonas Lahtinen wrote: > On to, 2017-05-18 at 10:46 +0100, Chris Wilson wrote: > > Set the class on our mock pci device to GFX. This should be useful for > > utilities like intel-iommu that special case gfx devices. > > > > References:

[Intel-gfx] [CI PATCH] drm/i915/g4x: Improve gpu reset reliability

ELK seems to very picky about the preconditions to reset. Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does not like if reset occurs when there is active ring. Ville found out that there is workaround with name 'WaMediaResetMainRingCleanup' which suggests that we need to cleanup rings

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915/guc: Remove stale comment for q_fail

On Thu, May 18, 2017 at 07:12:37PM +0200, Michal Wajdeczko wrote: > On Thu, May 18, 2017 at 04:38:01PM +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/3] drm/i915/guc: Remove stale comment for > > q_fail > > URL :

Re: [Intel-gfx] [PATCH 14/17] drm/i915/debugfs: include some gtt_page_size metrics

On Tue, May 16, 2017 at 09:29:45AM +0100, Matthew Auld wrote: > Good to know, mostly for debugging purposes. > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen Ok, we can do this along with setting obj->mm.page_sizes today and that'll

[Intel-gfx] [PATCH 6/8] drm/i915: Plumb crtc_state to PSR enable/disable

From: Ville Syrjälä The PSR enable/disable need to know things about the crtc state, so plumb it through. This will become even more important when we start to reuse the generic infoframe code for the VSC DIP programming as the infoframe code wants the crtc state

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Remove action status and statistics from debugfs

On Wed, May 17, 2017 at 11:48:15AM +0100, Tvrtko Ursulin wrote: > > On 15/05/2017 18:06, Michal Wajdeczko wrote: > >Usefulness of these stats was over-advertised. > > > >v2: remove duplicated engine stats (Chris) > > > >Suggested-by: Chris Wilson > >Signed-off-by:

Re: [Intel-gfx] [PATCH 24/24] RFC drm/i915: Expose a PMU interface for perf queries

On 5/19/2017 1:01 AM, Chris Wilson wrote: On Thu, May 18, 2017 at 04:48:47PM -0700, Dmitry Rogozhkin wrote: On 5/18/2017 2:46 AM, Chris Wilson wrote: The first goal is to be able to measure GPU (and invidual ring) busyness without having to poll registers from userspace. (Which not only

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/6] drm/i915: Remove misleading comment in request_alloc

== Series Details == Series: series starting with [v2,1/6] drm/i915: Remove misleading comment in request_alloc URL : https://patchwork.freedesktop.org/series/24696/ State : success == Summary == Series 24696v1 Series without cover letter

[Intel-gfx] [PATCH 3/4] drm/i915: Call uncore_suspend before platform suspend handlers

Quoting Ville: "the forcewake timer might still be active until the uncore suspend, and having active forcewakes while we've already told the GT wake stuff to stop acting normally doesn't seem quite right to me." Reported-by: Ville Syrjälä Suggested-by: Imre Deak

[Intel-gfx] [PATCH 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

intel_uncore_forcewake_reset() does forcewake puts and gets as such we need to make sure that no-one tries to access the PUNIT->PMIC bus (on systems where this bus is shared) while it runs, otherwise bad things happen. Normally this is taken care of by the i915_pmic_bus_access_notifier() which

[Intel-gfx] [PATCH 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(_priv->pm.wakeref_count);

[Intel-gfx] [PATCH 2/4] drm/i915: Re-register PMIC bus access notifier on runtime resume

intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make infoframe code available to (e)DP ports (rev2)

== Series Details == Series: drm/i915: Make infoframe code available to (e)DP ports (rev2) URL : https://patchwork.freedesktop.org/series/8183/ State : success == Summary == Series 8183v2 drm/i915: Make infoframe code available to (e)DP ports

[Intel-gfx] [PATCH v2 1/8] drm/dp: Add defines for DP SDP types

From: Ville Syrjälä Add defines for the secondary data packet (SDP) types from the spec. These are the DP specific ones, and in addition HDMI infoframe types (see enum hdmi_infoframe_type) are also valid SDP types. v2: Add more SDP types Cc:

[Intel-gfx] [PATCH v2 8/8] drm/i915: Constify states passed to enable/disable/etc. encoder hooks

From: Ville Syrjälä The enable/disable/etc. encoder hooks aren't supposed to alter the state(s), so pass them as const. Unfortunately C lacks any kind of deep const thingy, so this can't catch all abuses. But at least it acts as a hint to the reader telling them

[Intel-gfx] [PATCH 2/8] drm/i915: Check has_infoframes when enabling infoframes

From: Ville Syrjälä has_infoframe is what tells us whether infoframes should be enabled, so let's pass that instead of has_hdmi_sink to .set_infoframes(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 6

[Intel-gfx] [PATCH v2 4/8] drm/i915: Move infoframe vfuncs into intel_digital_port

From: Ville Syrjälä DP ports will also want to utilize the video DIP for SDP transmission. So let's move the vfuncs into the dig_port. v2: Rebase due to DDI changes Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma

[Intel-gfx] [PATCH 7/8] drm/i915: Remove mostly duplicated video DIP handling from PSR code

From: Ville Syrjälä Now that the infoframe hooks are part of the intel_dig_port, we can use the normal .write_infoframe() hook to update the VSC SDP. We do need to deal with the size difference between the VSC DIP and the others though. Another minor snag is that

[Intel-gfx] [PATCH 5/8] drm/i915: Init infoframe vfuncs for DP encoders as well

From: Ville Syrjälä DP ports may want to use the video DIP for SDP transmission, so let's initialize the vfuncs for DP encoders as well. The only exception is port A eDP prior to HSW as that one doesn't have a video DIP instance. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 3/8] drm/i915: Disable infoframes when shutting down DDI HDMI

From: Ville Syrjälä Disabling the video DIP when shutting the port down seems like a good idea. Bspec says: "When disabling both the DIP port and DIP transmission, first disable the port and then disable DIP." and "Restriction : GCP is only supported with HDMI

[Intel-gfx] [PATCH v2 0/8] drm/i915: Make infoframe code available to (e)DP ports

From: Ville Syrjälä A reposting of my earlier series to untangle the video DIP stuff from intel_hdmi. The immediate benefit is getting rid of some duplicated video DIP code from PSR. And in the future I think we may want to start pusing out infoframes for DP stuff

[Intel-gfx] [PATCH v3 6/6] drm/i915/scheduler: Use priorities when resubmitting after reset

Now that we're able to unsubmit requests, we can take advantage of it during reset. Rather than resubmitting the previous workload directly to GuC/ELSP, we can simply move the requests back to priority queue, submitting from the tasklet instead. v2: Move the tasklet schedule out for legacy

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf

On Thu, 18 May 2017 17:50:05 +0800 Xiaoguang Chen wrote: > User space will try to create a management fd for the dma-buf operation. > Using this management fd user can query the plane information and create > a dma-buf fd if necessary. > GVT-g will handle the life cycle

[Intel-gfx] [PATCH v5] drm/i915/gvt: return the correct usable aperture size under gvt environment

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. In gvt environment, each vm only use the ballooned part of aperture, so we should return the correct available aperture size exclude the reserved part by balloon. v2: add 'reserved' in struct i915_address_space to record

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: return the correct usable aperture size under gvt environment (rev4)

== Series Details == Series: drm/i915/gvt: return the correct usable aperture size under gvt environment (rev4) URL : https://patchwork.freedesktop.org/series/24206/ State : success == Summary == Series 24206v4 drm/i915/gvt: return the correct usable aperture size under gvt environment

[Intel-gfx] [PATCH][drm-next] drm/i915: Check for allocation failure

From: Colin Ian King The memory allocation for C is not being null checked and hence we could end up with a null pointer dereference. Fix this with a null pointer check. (I really should have noticed this when I was fixing an earlier issue.) Detected by CoverityScan,

[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Introduce buffer based cmd transport

Buffer based command transport can replace MMIO based mechanism. It may be used to perform host-2-guc and guc-to-host communication. Portions of this patch are based on work by: Michel Thierry Robert Beckett Daniele Ceraolo Spurio

[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Disable send function on fini

In earlier patch 789a625 we were enabling send function only after successful init. For completeness, we should make sure that we disable it on fini. v2: don't group steps by submission flag (Chris) Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v2 3/3] HAX Enable GuC loading & submission

This is just for CI testing, *** DO NOT MERGE *** Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/3] drm/i915/guc: Disable send function on fini

== Series Details == Series: series starting with [v2,1/3] drm/i915/guc: Disable send function on fini URL : https://patchwork.freedesktop.org/series/24715/ State : failure == Summary == Series 24715v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Submit GuC workitems containing coalesced requests

On 19/05/17 06:23, Michał Winiarski wrote: To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check for allocation failure

== Series Details == Series: drm/i915: Check for allocation failure URL : https://patchwork.freedesktop.org/series/24718/ State : success == Summary == Series 24718v1 drm/i915: Check for allocation failure https://patchwork.freedesktop.org/api/1.0/series/24718/revisions/1/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] drm/blend: Fix comment typ-o

== Series Details == Series: series starting with [v4,1/2] drm/blend: Fix comment typ-o URL : https://patchwork.freedesktop.org/series/24727/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

Re: [Intel-gfx] [PATCH v8 3/5] drm/i915: Add option to support dynamic backlight via DPCD

Hi Dhinakaran, Quick question So what is the update about adding new option in i915_params? Is this patch good to go after fixing the 2 points you mentioned? Thanks On Wed, May 17, 2017 at 1:33 PM, Pandiyan, Dhinakaran < dhinakaran.pandi...@intel.com> wrote: > On Tue, 2017-05-16 at 17:34

[Intel-gfx] [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As

[Intel-gfx] [PATCH v4 1/2] drm/blend: Fix comment typ-o

Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. Signed-off-by: Robert Foss --- drivers/gpu/drm/drm_blend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index a0d0d6843288..dee67ef6c670 100644 ---

Re: [Intel-gfx] [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

On 2017-05-18 05:49 AM, Ville Syrjälä wrote: On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote: +/* + * DRM_MODE_REFLECT_ + * + * Signals that the contents of a drm plane has been reflected in + * the axis. Still vague. Ack, I'll add some verbiage. Also you didn't respond to

Re: [Intel-gfx] [PATCH][drm-next] drm/i915: Check for allocation failure

On Fri, May 19, 2017 at 06:56:17PM +0100, Colin King wrote: > From: Colin Ian King > > The memory allocation for C is not being null checked and hence we > could end up with a null pointer dereference. Fix this with a null > pointer check. (I really should have noticed

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On Fri, 19 May 2017, Andrzej Hajda wrote: > On 18.05.2017 13:10, Jani Nikula wrote: >> Face the fact, there are Display Port sink and branch devices out there >> in the wild that don't follow the Display Port specifications, or they >> have bugs, or just otherwise require

Re: [Intel-gfx] [PATCH -next] drm/i915: Fix return value check in kfence selftests

On Fri, May 19, 2017 at 12:26:05AM +, Wei Yongjun wrote: > From: Wei Yongjun > > Fix the return value check which testing the wrong variable. Already fixed up yesterday: commit ac0a73fb526100adc521ec2069623e47ca3997a8 Author: Colin Ian King

Re: [Intel-gfx] [PATCH 24/24] RFC drm/i915: Expose a PMU interface for perf queries

On Thu, May 18, 2017 at 04:48:47PM -0700, Dmitry Rogozhkin wrote: > > > On 5/18/2017 2:46 AM, Chris Wilson wrote: > >The first goal is to be able to measure GPU (and invidual ring) busyness > >without having to poll registers from userspace. (Which not only incurs > >holding the forcewake lock

[Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Submit GuC workitems containing coalesced requests

To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission ports. We also need to stop pretending that we're

[Intel-gfx] [PATCH v2 3/6] drm/i915/guc: Remove GuC wq reservation

Now that we have an upper bound on the number of work items being sent to GuC, we can remove the reservation. v2: Multiply by number of engines in compile time assert (Daniele) Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Michal

[Intel-gfx] [PATCH v2 4/6] drm/i915/scheduler: Remember request priority throughout its lifetime

Since request can be unsubmitted, we need to avoid overriding its priority during submission. Otherwise we won't be able to resubmit it with correct priority. v2: Limit DFS by excluding completed requests (Chris) Cc: Chris Wilson Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v2 1/6] drm/i915: Remove misleading comment in request_alloc

Passing NULL ctx to request_alloc would lead to null-ptr-deref. v2: Let's not replace the comment with a BUG_ON Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_gem_request.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[Intel-gfx] [PATCH v2 5/6] drm/i915/scheduler: Split insert_request

We'd like to reuse the priolist lookup in request resubmission path, let's split insert_request to make that happen. v2: Handle allocation error in lookup rather than in caller (Chris) Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Tvrtko