[Intel-gfx] [PATCH xf86-video-intel] sna/io: Align the linear source buffer to cache line for 2d blt

On SKL+ the linear source buffer has to start from cache line boundary to meet the 2d engine source copy requirements. Signed-off-by: Guang Bai --- src/sna/sna_io.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/src/sna/sna_io.c b/src/sna/sna_io.c index

Re: [Intel-gfx] [PATCH] [intel-gfx] drm/i915/intel_csr.c Added ICL Stepping info.

Yeah, Thanks for the "Acked-by" Rodrigo. I request Imre/Anusha to review/acknowledge the same. Regards Jyoti -Original Message- From: Vivi, Rodrigo Sent: Tuesday, September 4, 2018 11:02 AM To: Yadav, Jyoti R Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH]

Re: [Intel-gfx] [PATCH] [intel-gfx] drm/i915/intel_csr.c Added ICL Stepping info.

On Mon, Sep 03, 2018 at 03:45:13AM -0400, Jyoti Yadav wrote: > As DMC Package contain DMC FW for multiple steppings including default > stepping. This patch will help to load FW for that particular stepping, > if FW for that stepping is available, instead of loading default FW. > Cc: Imre Deak

Re: [Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.

On Mon, Sep 03, 2018 at 01:00:39PM +0300, Imre Deak wrote: > On Mon, Aug 27, 2018 at 05:38:44PM -0700, Anusha Srivatsa wrote: > > Add Support to load DMC on Icelake. > > > > While at it, also add support to load the firmware > > during system resume. > > > > v2: load firmware during system

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix ICL+ HDMI clock readout

On Mon, Sep 03, 2018 at 05:28:41PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Copy the 38.4 vs. 19.2 MHz ref clock exception from the dpll > mgr into the clock readout function as well. > > v2: Refactor the code into a common function > s/is_icl/gen11+/ (Rodrigo) neat > >

Re: [Intel-gfx] [PULL] gvt-fixes for 4.19

On Tue, Sep 04, 2018 at 10:54:37AM +0800, Zhenyu Wang wrote: > > Hi, > > Here's current gvt-fixes for 4.19 with more BXT fixes, > two guest warning fixes, dmabuf format mod fix and one > for recent multiple VM timeout failure. pulled, thanks! > > Thanks > -- > The following changes since

[Intel-gfx] [PULL] gvt-next for 4.20

Hi, Here's initial gvt-next for 4.20 with two optimization for guest context shadowing and command parser, and with W=1 build fixes. Thanks -- The following changes since commit 279ce5d117078ee8ea40c40199399889981fd808: drm/i915/gvt: declare gvt as i915's soft dependency (2018-07-10 11:13:11

[Intel-gfx] [PULL] gvt-fixes for 4.19

Hi, Here's current gvt-fixes for 4.19 with more BXT fixes, two guest warning fixes, dmabuf format mod fix and one for recent multiple VM timeout failure. Thanks -- The following changes since commit 80ab316901bc4ae6dd0b5903dbe22766307eac9b: drm/i915/audio: Hook up component bindings even if

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Combine cleanup_status_page()

== Series Details == Series: series starting with [1/2] drm/i915: Combine cleanup_status_page() URL : https://patchwork.freedesktop.org/series/49085/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757_full -> Patchwork_10074_full = == Summary - SUCCESS == No regressions

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix ICL HDMI clock readout (rev2)

== Series Details == Series: drm/i915: Fix ICL HDMI clock readout (rev2) URL : https://patchwork.freedesktop.org/series/48805/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757_full -> Patchwork_10072_full = == Summary - SUCCESS == No regressions found. == Known

[Intel-gfx] ✓ Fi.CI.IGT: success for kernel/panic: Show the stacktrace after additional notifier messages

== Series Details == Series: kernel/panic: Show the stacktrace after additional notifier messages URL : https://patchwork.freedesktop.org/series/49080/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757_full -> Patchwork_10071_full = == Summary - SUCCESS == No

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/14] drm: Add drm/kernel.h header file

== Series Details == Series: series starting with [01/14] drm: Add drm/kernel.h header file URL : https://patchwork.freedesktop.org/series/49089/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4758 -> Patchwork_10076 = == Summary - FAILURE == Serious unknown changes

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/14] drm: Add drm/kernel.h header file

== Series Details == Series: series starting with [01/14] drm: Add drm/kernel.h header file URL : https://patchwork.freedesktop.org/series/49089/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Add drm/kernel.h header file

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/14] drm: Add drm/kernel.h header file

== Series Details == Series: series starting with [01/14] drm: Add drm/kernel.h header file URL : https://patchwork.freedesktop.org/series/49089/ State : warning == Summary == $ dim checkpatch origin/drm-tip a39d30c28e70 drm: Add drm/kernel.h header file -:139: WARNING:FILE_PATH_CHANGES:

Re: [Intel-gfx] [PATCH 09/14] drm: Update todo.rst

On 3 September 2018 at 17:54, Daniel Vetter wrote: > -Hide legacy cruft better > - > - > -Way back DRM supported only drivers which shadow-attached to PCI devices with > -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge > -of the entire

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix context RPCS programming (rev2)

== Series Details == Series: drm/i915/icl: Fix context RPCS programming (rev2) URL : https://patchwork.freedesktop.org/series/49005/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757_full -> Patchwork_10070_full = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH 09/14] drm: Update todo.rst

Hi Daniel. > -Note that this is well in progress, but ``drmP.h`` is still huge. The updated > -plan is to switch to per-file driver API headers, which will also structure > -the kerneldoc better. This should also allow more fine-grained ``#include`` > -directives. > +The DRM subsystem originally

[Intel-gfx] ✗ Fi.CI.BAT: failure for video/fbdev: Warn when we try to free a registered framebuffer

== Series Details == Series: video/fbdev: Warn when we try to free a registered framebuffer URL : https://patchwork.freedesktop.org/series/49088/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4757 -> Patchwork_10075 = == Summary - FAILURE == Serious unknown changes

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Combine cleanup_status_page()

Quoting Matthew Auld (2018-09-03 17:39:09) > On Mon, 3 Sep 2018 at 16:25, Chris Wilson wrote: > > > > Pull the physical status page cleanup into a common > > cleanup_status_page() for caller simplicity. > > > > Signed-off-by: Chris Wilson > Reviewed-by: Matthew Auld And applied just on the

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for video/fbdev: Warn when we try to free a registered framebuffer

== Series Details == Series: video/fbdev: Warn when we try to free a registered framebuffer URL : https://patchwork.freedesktop.org/series/49088/ State : warning == Summary == $ dim checkpatch origin/drm-tip 19ba7c0f116f video/fbdev: Warn when we try to free a registered framebuffer -:28:

[Intel-gfx] [PATCH 14/14] drm/vmwgfx: Add FIXME comments for customer page_flip handlers

The idea behind allowing drivers to override legacy ioctls (instead of using the generic implementations unconditionally) is to handle bugs in old driver-specific userspace. Like e.g. vmw_kms_set_config does, to work around some vmwgfx userspace not clearing its ioctl structs properly. But you

[Intel-gfx] [PATCH 12/14] drm/vmwgfx: Don't look at state->allow_modeset

That's purely for the uapi layer to implement the ALLOW_MODESET flag. Drivers should instead look at the state, e.g. through drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove the confusing comment, since checking allow_modeset is at best a micro optimization. Signed-off-by:

[Intel-gfx] [PATCH 13/14] drm/atomic: Improve docs for drm_atomic_state->allow_modeset

Motivated by vmwgfx digging around in core uapi bits it shouldn't dig around in. Signed-off-by: Daniel Vetter --- include/drm/drm_atomic.h | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index

[Intel-gfx] [PATCH 10/14] drm: Extract drm_atomic_state_helper.[hc]

We already have a separate overview doc for this, makes sense to untangle it from the overall atomic helpers. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 19 +- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 568

[Intel-gfx] [PATCH 11/14] drm/vmwgfx: Remove confused comment from vmw_du_connector_atomic_set_property

The core _does_ the call to drm_atomic_commit for you. That's pretty much the entire point of having the fancy new atomic_set/get_prop callbacks. Signed-off-by: Daniel Vetter Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 -- 1 file

[Intel-gfx] [PATCH 07/14] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder

It's the default. The exported version was kinda a transition state, before we made this the default. To stop new atomic drivers from using it (instead of just relying on the default) let's unexport it. Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc:

[Intel-gfx] [PATCH 06/14] drm: extract drm_atomic_uapi.c

This leaves all the commit/check and state handling in drm_atomic.c, while pulling all the uapi glue and the huge ioctl itself into a seprate file. This seems to almost perfectly split the rather big drm_atomic.c file into 2 equal sizes. Also adjust the kerneldoc and type a very terse overview

[Intel-gfx] [PATCH 01/14] drm: Add drm/kernel.h header file

We have a bunch of neat little macros all over the place which should move to kernel.h. But some of them died in bikesheds on lkml, and we need a decent home for them. Start out by moving the for_each_if macro there. Cc: Sean Paul Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 08/14] drm/amdgpu: Remove default best_encoder hook from DC

For atomic driver this is the default, no need to reimplement it. We still need to keep the copypasta for not-atomic drivers though, since no one polished the legacy crtc helpers as much as the atomic ones. Signed-off-by: Daniel Vetter Cc: Alex Deucher Cc: Harry Wentland Cc: Andrey Grodzovsky

[Intel-gfx] [PATCH 09/14] drm: Update todo.rst

- drmP.h is now fully split up. - vkms is happening (and will gain its own todo and docs under a new vkms.rst file real soon) - legacy cruft is completely hidden now, drm_vblank.c is split out from drm_irq.c now. - best_encoder atomic cleanup is done (it's now the default, not even exported

[Intel-gfx] [PATCH 05/14] drm/atomic: trim driver interface/docs

Remove the kerneldoc and EXPORT_SYMBOL which aren't used and really shouldn't ever be used by drivers directly. Unfortunately this means we need to move the set_writeback_fb function around to avoid a forward decl. Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Gustavo Padovan Cc: Maarten

[Intel-gfx] [PATCH 04/14] drm: drop drmP.h include from drm_crtc.c

This is starting to become easy! v2: Compiles now, with drm/kernel.h extracted. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c

[Intel-gfx] [PATCH 03/14] drm: drop drmP.h include from drm_plane.c

Just a bit of missing includes and pre declarations. v2: Compiles now, with drm/kernel.h extracted. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_internal.h | 8 drivers/gpu/drm/drm_plane.c | 11 ++- include/drm/drm_color_mgmt.h

[Intel-gfx] [PATCH 02/14] drm: Drop drmP.h from drm_connector.c

Only needed minimal changes in drm_internal.h (for the drm_ioctl_t type and a few forward declarations), plus a few missing includes in drm_connector.c. Yay, the last stage of the drm header cleanup can finally commence! v2: Compiles now, with drm/kernel.h extracted. Reviewed-by: Sean Paul

[Intel-gfx] [PATCH] video/fbdev: Warn when we try to free a registered framebuffer

Just a tool for CI to emit the stacktrace of who is lost track of their framebuffers and tried to free it before unregistering it. References: https://bugs.freedesktop.org/show_bug.cgi?id=107712 Cc: Daniel Vetter --- Would be useful to keep in core-for-CI as a debug aide. ---

Re: [Intel-gfx] [PATCH] drm/i915: Fix up FORCE_GPU_RELOC (debug) to flush CPU write domains

On Mon, 3 Sep 2018 at 16:04, Chris Wilson wrote: > > We currently assert that if the target is in a CPU write domain, we use > a CPU path rather than the GPU path. However, we have a debug override > to force the GPU path and that unfortunately hits the assert. Include > the async clflush under

Re: [Intel-gfx] [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

On Wed, Aug 22, 2018 at 10:54:04AM +0200, Daniel Vetter wrote: > DRM drivers really, really, really don't want random userspace to > share buffer behind it's back, bypassing the dma-buf buffer sharing > machanism. For that reason we've ruthlessly rejected any IOCTL > exposing the physical address

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Combine cleanup_status_page()

On Mon, 3 Sep 2018 at 16:25, Chris Wilson wrote: > > Pull the physical status page cleanup into a common > cleanup_status_page() for caller simplicity. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] drm: Remove "protection" around drm_vma_offset_manager_destroy()

On Mon, Sep 03, 2018 at 10:31:55AM +0100, Chris Wilson wrote: > Using a spinlock to serialize the destroy function, within the destroy > function itself does not prevent the buggy driver from shooting > themselves in the foot - either way they still have a use-after-free > issue. > > Reported-by:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Combine cleanup_status_page()

== Series Details == Series: series starting with [1/2] drm/i915: Combine cleanup_status_page() URL : https://patchwork.freedesktop.org/series/49085/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757 -> Patchwork_10074 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Combine cleanup_status_page()

== Series Details == Series: series starting with [1/2] drm/i915: Combine cleanup_status_page() URL : https://patchwork.freedesktop.org/series/49085/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Combine cleanup_status_page() Okay! Commit: drm/i915: Use a cached

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix up FORCE_GPU_RELOC (debug) to flush CPU write domains

== Series Details == Series: drm/i915: Fix up FORCE_GPU_RELOC (debug) to flush CPU write domains URL : https://patchwork.freedesktop.org/series/49084/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4757 -> Patchwork_10073 = == Summary - FAILURE == Serious unknown changes

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

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 observed lost breadcrumbs writes into the HWS on i965gm, which

[Intel-gfx] [PATCH 1/2] drm/i915: Combine cleanup_status_page()

Pull the physical status page cleanup into a common cleanup_status_page() for caller simplicity. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 20 ++-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix ICL HDMI clock readout (rev2)

== Series Details == Series: drm/i915: Fix ICL HDMI clock readout (rev2) URL : https://patchwork.freedesktop.org/series/48805/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757 -> Patchwork_10072 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH] drm/i915: Fix up FORCE_GPU_RELOC (debug) to flush CPU write domains

We currently assert that if the target is in a CPU write domain, we use a CPU path rather than the GPU path. However, we have a debug override to force the GPU path and that unfortunately hits the assert. Include the async clflush under the debug option. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH v2] drm/i915: Fix ICL+ HDMI clock readout

From: Ville Syrjälä Copy the 38.4 vs. 19.2 MHz ref clock exception from the dpll mgr into the clock readout function as well. v2: Refactor the code into a common function s/is_icl/gen11+/ (Rodrigo) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107722 Signed-off-by: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for kernel/panic: Show the stacktrace after additional notifier messages

== Series Details == Series: kernel/panic: Show the stacktrace after additional notifier messages URL : https://patchwork.freedesktop.org/series/49080/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757 -> Patchwork_10071 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] [PATCH i-g-t v3] lib/pm: Wait a little for sound module load to complete

Sometimes we may probe the sound module as it is still being registered and its debugfs not yet fully populated. If we do not find a file we expect to exist, sleep a little and check again. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107801 Signed-off-by: Chris Wilson Cc: Imre Deak

[Intel-gfx] [PATCH] kernel/panic: Show the stacktrace after additional notifier messages

Most systems keep the last messages from the panic, and we value the stacktrace most, so dump it last in order to preserve it for post-mortems. Signed-off-by: Chris Wilson --- kernel/panic.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/kernel/panic.c

[Intel-gfx] [PATCH i-g-t v2] lib/pm: Wait a little for sound module load to complete

Sometimes we may probe the sound module as it is still being registered and its debugfs not yet fully populated. If we do not find a file we expect to exist, sleep a little and check again. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107801 Signed-off-by: Chris Wilson Cc: Imre Deak

Re: [Intel-gfx] [PATCH i-g-t] lib/pm: Wait a little for sound module load to complete

Quoting Chris Wilson (2018-09-03 13:51:10) > Sometimes we may probe the sound module as it is still being registered > and its debugfs not yet fully populated. If we do not find a file we > expect to exist, sleep a little and check again. > > Bugzilla:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix context RPCS programming (rev2)

== Series Details == Series: drm/i915/icl: Fix context RPCS programming (rev2) URL : https://patchwork.freedesktop.org/series/49005/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4757 -> Patchwork_10070 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH i-g-t] lib/pm: Wait a little for sound module load to complete

Sometimes we may probe the sound module as it is still being registered and its debugfs not yet fully populated. If we do not find a file we expect to exist, sleep a little and check again. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107801 Signed-off-by: Chris Wilson Cc: Imre Deak

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Fix context RPCS programming (rev2)

== Series Details == Series: drm/i915/icl: Fix context RPCS programming (rev2) URL : https://patchwork.freedesktop.org/series/49005/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9a2751c01ca2 drm/i915/icl: Fix context RPCS programming -:18: WARNING:TYPO_SPELLING: 'writting'

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Remove "protection" around drm_vma_offset_manager_destroy()

== Series Details == Series: drm: Remove "protection" around drm_vma_offset_manager_destroy() URL : https://patchwork.freedesktop.org/series/49069/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4754_full -> Patchwork_10069_full = == Summary - SUCCESS == No regressions

Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

OK, so no end-user queries matter, just the queries from the tools for end-users do, right? And with making the open-source tool (shipped by distros, etc.) suitable for negotiations we need to hurry while at least the trace-point mechanism is not yet completely broken and can be used to show

[Intel-gfx] [PATCH v2] drm/i915/icl: Fix context RPCS programming

From: Tvrtko Ursulin There are two issues with the current RPCS programming for Icelake: Expansion of the slice count bitfield has been missed, as well as the required programming workaround for the subslice count bitfield size limitation. 1) Bitfield width for configuring the active slice

Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context RPCS programming

On 31/08/2018 17:52, Lionel Landwerlin wrote: On 31/08/2018 12:53, Tvrtko Ursulin wrote: From: Tvrtko Ursulin There are two issues with the current RPCS programming for Icelake: Expansion of the slice count bitfield has been missed, as well as the required programming workaround for the

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Do a full device reset after being wedged

Quoting Patchwork (2018-09-03 11:29:24) > == Series Details == > > Series: series starting with [1/5] drm/i915: Do a full device reset after > being wedged > URL : https://patchwork.freedesktop.org/series/49061/ > State : success > > == Summary == > > = CI Bug Log - changes from

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Flag any possible writes for a GTT fault

Quoting Chris Wilson (2018-09-03 11:33:34) > We do not explicitly mark the PTE for the user's GTT mmap as being > wrprotect, so we don't get a refault when we would need to change a > read-only mmapping into read-write. As such, we must presume that if the > vma has PROT_WRITE it may be written

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Do a full device reset after being wedged

== Series Details == Series: series starting with [1/5] drm/i915: Do a full device reset after being wedged URL : https://patchwork.freedesktop.org/series/49061/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753_full -> Patchwork_10068_full = == Summary - SUCCESS ==

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Forcibly flush unwanted requests in drop-caches

Quoting Chris Wilson (2018-09-03 11:33:37) > Add a mode to debugfs/drop-caches to flush unwanted requests off the GPU > (by wedging the device and resetting). This is very useful if a test > terminated leaving a long queue of hanging batches that would ordinarily > require a round trip through

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Early rejection of buffer allocations larger than RAM

Quoting Chris Wilson (2018-09-03 11:33:36) > We currently try to pin and allocate the whole buffer at a time. If that > object is larger than RAM, we will try to pin the whole of physical > memory, force the machine into oom, and then still fail the allocation. > > If the request is obviously too

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Force the slow path after a user-write error

Quoting Chris Wilson (2018-09-03 11:33:35) > If we fail to write the user relocation back when it is changed, force > ourselves to take the slow relocation path where we can handle faults in > the write path. There is still an element of dubiousness as having > patched up the batch to use the

Re: [Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.

On Mon, Aug 27, 2018 at 05:38:44PM -0700, Anusha Srivatsa wrote: > Add Support to load DMC on Icelake. > > While at it, also add support to load the firmware > during system resume. > > v2: load firmware during system resume.(Imre) > > v3: enable has_csr for icelake.(Jyoti) > > v4: Only load

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Remove "protection" around drm_vma_offset_manager_destroy()

== Series Details == Series: drm: Remove "protection" around drm_vma_offset_manager_destroy() URL : https://patchwork.freedesktop.org/series/49069/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4754 -> Patchwork_10069 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH] drm/i915: Reduce context HW ID lifetime

On 31/08/2018 13:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-08-30 17:23:43) On 30/08/2018 11:24, Chris Wilson wrote: +static int steal_hw_id(struct drm_i915_private *i915) +{ + struct i915_gem_context *ctx, *cn; + LIST_HEAD(pinned); + int id = -ENOSPC; + +

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Do a full device reset after being wedged

Quoting Chris Wilson (2018-09-03 11:33:33) > We only call unset_wedged on the global reset path (since it's a global > operation), so if we are terminally wedged and wish to reset, take the > full device reset path rather than the quicker individual engine resets. > > Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm: Remove "protection" around drm_vma_offset_manager_destroy()

Using a spinlock to serialize the destroy function, within the destroy function itself does not prevent the buggy driver from shooting themselves in the foot - either way they still have a use-after-free issue. Reported-by: Jia-Ju Bai Signed-off-by: Chris Wilson Cc: Davidlohr Bueso Cc: Liviu

Re: [Intel-gfx] [PATCH] drm/i915: Determine uses-full-ppgtt from context for execbuf

Quoting Rodrigo Vivi (2018-09-03 06:20:22) > On Sat, Sep 01, 2018 at 10:24:51AM +0100, Chris Wilson wrote: > > Rather than inspect the global module parameter for whether full-ppgtt > > maybe enabled, we can inspect the context directly as to whether it has > > its own vm. > > > > Signed-off-by:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/intel_csr.c Added ICL Stepping info.

== Series Details == Series: drm/i915/intel_csr.c Added ICL Stepping info. URL : https://patchwork.freedesktop.org/series/49058/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753_full -> Patchwork_10067_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Do a full device reset after being wedged

== Series Details == Series: series starting with [1/5] drm/i915: Do a full device reset after being wedged URL : https://patchwork.freedesktop.org/series/49061/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753 -> Patchwork_10068 = == Summary - SUCCESS == No

[Intel-gfx] [PATCH libdrm] Add basic CONTRIBUTING file

I picked up a bunch of the pieces from wayland's version: https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md The weston one is fairly similar. Then I rather massively trimmed it down since in reality libdrm is a bit a dumping ground with very few real rules. The commit

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Do a full device reset after being wedged

== Series Details == Series: series starting with [1/5] drm/i915: Do a full device reset after being wedged URL : https://patchwork.freedesktop.org/series/49061/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4125e8b6522d drm/i915: Do a full device reset after being wedged

[Intel-gfx] [PATCH 2/5] drm/i915: Flag any possible writes for a GTT fault

We do not explicitly mark the PTE for the user's GTT mmap as being wrprotect, so we don't get a refault when we would need to change a read-only mmapping into read-write. As such, we must presume that if the vma has PROT_WRITE it may be written to, although this is supposed to be indicated by

[Intel-gfx] [PATCH 4/5] drm/i915: Early rejection of buffer allocations larger than RAM

We currently try to pin and allocate the whole buffer at a time. If that object is larger than RAM, we will try to pin the whole of physical memory, force the machine into oom, and then still fail the allocation. If the request is obviously too large, error out early. We opt to do this in the

[Intel-gfx] [PATCH 3/5] drm/i915: Force the slow path after a user-write error

If we fail to write the user relocation back when it is changed, force ourselves to take the slow relocation path where we can handle faults in the write path. There is still an element of dubiousness as having patched up the batch to use the correct offset, it no longer matches the

[Intel-gfx] [PATCH 1/5] drm/i915: Do a full device reset after being wedged

We only call unset_wedged on the global reset path (since it's a global operation), so if we are terminally wedged and wish to reset, take the full device reset path rather than the quicker individual engine resets. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 3 ++- 1 file

[Intel-gfx] [PATCH 5/5] drm/i915: Forcibly flush unwanted requests in drop-caches

Add a mode to debugfs/drop-caches to flush unwanted requests off the GPU (by wedging the device and resetting). This is very useful if a test terminated leaving a long queue of hanging batches that would ordinarily require a round trip through hangcheck for each. It reduces the inter-test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/intel_csr.c Added ICL Stepping info.

== Series Details == Series: drm/i915/intel_csr.c Added ICL Stepping info. URL : https://patchwork.freedesktop.org/series/49058/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753 -> Patchwork_10067 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/intel_csr.c Added ICL Stepping info.

== Series Details == Series: drm/i915/intel_csr.c Added ICL Stepping info. URL : https://patchwork.freedesktop.org/series/49058/ State : warning == Summary == $ dim checkpatch origin/drm-tip e524a457fd75 drm/i915/intel_csr.c Added ICL Stepping info. -:20: CHECK:LINE_SPACING: Please use a

[Intel-gfx] [PATCH] [intel-gfx] drm/i915/intel_csr.c Added ICL Stepping info.

As DMC Package contain DMC FW for multiple steppings including default stepping. This patch will help to load FW for that particular stepping, if FW for that stepping is available, instead of loading default FW. Signed-off-by: Jyoti Yadav --- drivers/gpu/drm/i915/intel_csr.c | 8 1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Kill debugfs's i915_dpcd

== Series Details == Series: drm/i915: Kill debugfs's i915_dpcd URL : https://patchwork.freedesktop.org/series/49055/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753_full -> Patchwork_10066_full = == Summary - SUCCESS == No regressions found. == Known issues ==

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Protect against wrong reg offset and warn.

== Series Details == Series: drm/i915: Protect against wrong reg offset and warn. URL : https://patchwork.freedesktop.org/series/49054/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753_full -> Patchwork_10065_full = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Kill debugfs's i915_dpcd

== Series Details == Series: drm/i915: Kill debugfs's i915_dpcd URL : https://patchwork.freedesktop.org/series/49055/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4753 -> Patchwork_10066 = == Summary - SUCCESS == No regressions found. External URL: