Re: [Intel-gfx] [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote: >I still have no idea how this autoselect picks up patches that do *not* >have cc: stable nor Fixes: from us. What information do you have that we >don't for making that call? I think there's a difference in views about the stable tag

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

Greg KH wrote: > On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: >> Greg KH wrote: >>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote: Greg KH wrote: > On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote: >> Hi! >> >> Hopefully the right

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

Jani Nikula wrote: > On Sun, 19 Nov 2017, Greg KH wrote: >> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: >>> Greg KH wrote: On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: > Greg KH wrote: >> On Sat, Nov 18, 2017 at

Re: [Intel-gfx] [PATCH v2] drm/i915: Initialise entry in intel_ppat_get() for older compilers

Reviewed-by: Zhi Wang -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Monday, November 20, 2017 11:55 AM To: Wang, Zhi A ; Chris Wilson ; intel-gfx@lists.freedesktop.org Cc:

[Intel-gfx] [PATCH 2/2] drm/i915: Automatic i915_switch_context for legacy

During request construction, after pinning the context we know whether or not we have to emit a context switch. So move this common operation from every caller into i915_gem_request_alloc() itself. v2: Always submit the request if we emitted some commands during request construction, as typically

[Intel-gfx] [PATCH 1/2] drm/i915: Pull the unconditional GPU cache invalidation into request construction

As the request now may implicitly invoke a context-switch, we should follow that with a GPU TLB invalidation. Also even before using GGTT, we should invalidate the TLBs for any updates (as well as the ppgtt invalidates that are unconditionally applied by execbuf). Since we almost always require

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE URL : https://patchwork.freedesktop.org/series/34081/ State : success == Summary == Test kms_flip: Subgroup flip-vs-panning-vs-hang-interruptible:

Re: [Intel-gfx] [PATCH v3 04/11] drm/i915: Handle adjust better in intel_pipe_config_compare

On Mon, Nov 13, 2017 at 07:24:22PM +0200, Ville Syrjälä wrote: > On Fri, Nov 10, 2017 at 02:02:45PM +0100, Daniel Vetter wrote: > > On Fri, Nov 10, 2017 at 12:34:56PM +0100, Maarten Lankhorst wrote: > > > Some parameters use CHECK_BOOLL, but should really use > > > CHECK_BOOL_INCOMPLETE. We cannot

Re: [Intel-gfx] [PATCH 09/10] drm/modes: Provide global mode_valid hook

On Tue, Nov 14, 2017 at 08:32:57PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Allow drivers to provide a device wide .mode_valid() hook in addition to > the already existing crtc/encoder/bridge/connector hooks. This can be > used to validate

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Provide a device level .mode_valid() hook

On Tue, Nov 14, 2017 at 08:32:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > We never support certain mode flags etc. Reject those early on in the > mode_config.mode_valid() hook. That allows us to remove some duplicated > checks from the connector

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Provide a device level .mode_valid() hook

On Mon, Nov 20, 2017 at 09:01:07AM +0100, Daniel Vetter wrote: > On Tue, Nov 14, 2017 at 08:32:58PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We never support certain mode flags etc. Reject those early on in the > > mode_config.mode_valid() hook.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE URL : https://patchwork.freedesktop.org/series/34081/ State : success == Summary == Series 34081v1 series starting with [1/2] drm/i915/execlists: Listen to COMPLETE

[Intel-gfx] Monday Morning Mini-Melts

The bxt fix is here; the bxt fix is here. Go review and test. Michel, if you want to retake authorship please do so, then I can swap mine for a review and tested-by. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write

The hardware needs some time to process the information received in the ExecList Submission Port, and expects us to don't write anything new until it has 'acknowledged' this new execlist by sending an IDLE_ACTIVE or PREEMPTED CSB event. If we do not follow this, the driver could write new data

[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

Since commit e1fee72c2ea2e9c0c6e6743d32a6832f21337d6c Author: Oscar Mateo Date: Thu Jul 24 17:04:40 2014 +0100 drm/i915/bdw: Avoid non-lite-restore preemptions execlists has listened to (ACTIVE_IDLE | ELEMENT_SWITCH) for detecting when one context completed and it

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

On Sun, 19 Nov 2017, Greg KH wrote: > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: >> Greg KH wrote: >> > On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: >> >> Greg KH wrote: >> >>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer

[Intel-gfx] [PATCH] i965: Always try to create a logical context

Always enable use of HW logical contexts to preserve GPU state between batches when the kernel supports such constructs, continuing to enforce the required support for gen6+. At runtime, this effectively removes the BRW_NEW_CONTEXT flag (and the upload of invariant state) from the start of every

Re: [Intel-gfx] [PATCH v2] drm/i915: Initialise entry in intel_ppat_get() for older compilers

On Fri, 2017-11-17 at 13:32 +, Wang, Zhi A wrote: > Thanks! Looks good to me. An explicit Reviewed-by would probably be in place then? Then we get the patch merged, too. Regards, Joonas > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday,

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Pull the unconditional GPU cache invalidation into request construction

== Series Details == Series: series starting with [1/2] drm/i915: Pull the unconditional GPU cache invalidation into request construction URL : https://patchwork.freedesktop.org/series/34092/ State : warning == Summary == Test kms_flip: Subgroup vblank-vs-suspend-interruptible:

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

Maarten Lankhorst wrote: > Op 20-11-17 om 09:51 schreef Rainer Fiebig: >> Jani Nikula wrote: >>> On Sun, 19 Nov 2017, Greg KH wrote: On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: > Greg KH wrote: >> On Sun, Nov 19, 2017 at 12:56:26PM

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Assert that we don't get mixed IDLE_ACTIVE | COMPLETE events

== Series Details == Series: drm/i915/execlists: Assert that we don't get mixed IDLE_ACTIVE | COMPLETE events URL : https://patchwork.freedesktop.org/series/34094/ State : failure == Summary == Applying: drm/i915/execlists: Assert that we don't get mixed IDLE_ACTIVE | COMPLETE events Using

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

Maarten Lankhorst wrote: > Op 20-11-17 om 09:51 schreef Rainer Fiebig: >> Jani Nikula wrote: >>> On Sun, 19 Nov 2017, Greg KH wrote: On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: > Greg KH wrote: >> On Sun, Nov 19, 2017 at 12:56:26PM

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

Op 20-11-17 om 12:38 schreef Rainer Fiebig: > Maarten Lankhorst wrote: >> Op 20-11-17 om 09:51 schreef Rainer Fiebig: >>> Jani Nikula wrote: On Sun, 19 Nov 2017, Greg KH wrote: > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: >> Greg KH

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter

Quoting Patchwork (2017-11-20 16:05:56) > == Series Details == > > Series: series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists > module parameter > URL : https://patchwork.freedesktop.org/series/34109/ > State : failure > > == Summary == > > Applying: drm/i915: Remove

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: Cleanup unwanted public symbols

== Series Details == Series: drm/i915/gvt: Cleanup unwanted public symbols URL : https://patchwork.freedesktop.org/series/34101/ State : success == Summary == Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 Test kms_frontbuffer_tracking:

Re: [Intel-gfx] [PATCH 4/4] drm/i915: expose EU topology through sysfs

On 20/11/17 16:13, Tvrtko Ursulin wrote: On 20/11/2017 12:23, Lionel Landwerlin wrote: With the introduction of asymetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate

[Intel-gfx] ✓ Fi.CI.IGT: success for tools: Stop opening the driver just to find the debugfs

== Series Details == Series: tools: Stop opening the driver just to find the debugfs URL : https://patchwork.freedesktop.org/series/34107/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt: fail -> PASS

Re: [Intel-gfx] [PATCH 3/4] drm/i915: expose engine availability through sysfs

On 20/11/2017 12:23, Lionel Landwerlin wrote: This enables userspace to discover the engines available on the GPU. Here is the layout on a Skylake GT4: /sys/devices/pci:00/:00:02.0/drm/card0/gt ├── bcs It niggles me a bit that engine class names are directly under gt. If we end up

Re: [Intel-gfx] [PATCH 4/4] drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write

Quoting Michel Thierry (2017-11-20 16:17:01) > On 11/20/2017 4:34 AM, Chris Wilson wrote: > > The hardware needs some time to process the information received in the > > ExecList Submission Port, and expects us to not write anything more until > > it has 'acknowledged' this new submission by

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pull the unconditional GPU cache invalidation into request construction

Quoting Mika Kuoppala (2017-11-20 15:26:57) > Chris Wilson writes: > > > As the request now may implicitly invoke a context-switch, we should > > follow that with a GPU TLB invalidation. Also even before using GGTT, we > > s/follow/preample? As it is the context-switch

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftest: Make guc clients static

== Series Details == Series: drm/i915/selftest: Make guc clients static URL : https://patchwork.freedesktop.org/series/34100/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail -> PASS (shard-snb)

Re: [Intel-gfx] [PATCH 3/4] drm/i915: expose engine availability through sysfs

On 20/11/2017 12:23, Lionel Landwerlin wrote: This enables userspace to discover the engines available on the GPU. Here is the layout on a Skylake GT4: /sys/devices/pci:00/:00:02.0/drm/card0/gt ├── bcs │   └── 0 │   ├── capabilities │   ├── class │   └── id One more thing

Re: [Intel-gfx] [PATCH 4/4] drm/i915: expose EU topology through sysfs

On 20/11/2017 12:23, Lionel Landwerlin wrote: With the introduction of asymetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts

Re: [Intel-gfx] [PATCH 3/4] drm/i915: expose engine availability through sysfs

On 20/11/17 16:03, Tvrtko Ursulin wrote: - I would need engine->instance here as well. Sure. I thought that wasn't uabi though. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Make ips_enabled a property depending on whether IPS is enabled, v2.

Op 20-11-17 om 15:01 schreef Ville Syrjälä: > On Mon, Nov 20, 2017 at 01:23:35PM +0100, Maarten Lankhorst wrote: >> ips_enabled was used as a variable of whether IPS can be enabled or not, >> but should be used to test whether IPS is actually enabled. >> >> Changes since v1: >> - Call

Re: [Intel-gfx] [PATCH] drm/i915/selftest: Make guc clients static

On 11/20/2017 5:26 AM, Chris Wilson wrote: Make the private array used for stashing test clients static, to silence sparse. References: 55bd6bd75717 ("drm/i915/selftests: Add a GuC doorbells selftest") Signed-off-by: Chris Wilson Cc: Michel Thierry

Re: [Intel-gfx] [PATCH 3/4] drm/i915/execlists: Assert that we don't get mixed IDLE_ACTIVE | COMPLETE events

Quoting Joonas Lahtinen (2017-11-20 13:25:58) > On Mon, 2017-11-20 at 12:34 +, Chris Wilson wrote: > > If IDLE_ACTIVE is set, then all other bits are invalid. For us, we can > > assert that if we see a COMPLETE | PREEMPTED event, then it should be > > impossible for it to also contain an

[Intel-gfx] ✓ Fi.CI.BAT: success for tools: Stop opening the driver just to find the debugfs

== Series Details == Series: tools: Stop opening the driver just to find the debugfs URL : https://patchwork.freedesktop.org/series/34107/ State : success == Summary == IGT patchset tested on top of latest successful build 9fb5344bab2540e3d12a7d3a94c2a3801a6fec36 tools/error_decode: Print

Re: [Intel-gfx] [PATCH 3/4] drm/i915: expose engine availability through sysfs

On 20/11/2017 16:33, Lionel Landwerlin wrote: On 20/11/17 16:03, Tvrtko Ursulin wrote: - I would need engine->instance here as well. Sure. I thought that wasn't uabi though. Then again engine->instance is already there as the containing directory name. So do I need it in a separate file,

Re: [Intel-gfx] [PATCH v6 03/10] drm/i915: s/enum plane/enum i9xx_plane_id/

On Fri, Nov 17, 2017 at 09:19:10PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Rename enum plane to enum i9xx_plane_id to make it clear that it only > applies to pre-SKL platforms. > > enum i9xx_plane_id is a global identifier, whereas enum plane_id is >

[Intel-gfx] [CI 4/5] drm/i915: Move debugfs/i915_semaphore_status to i915_engine_info

As the semaphores is just part of the engine, include it with the general pretty printer universally used for debugging. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [CI 3/5] drm/i915: Disable semaphores on Sandybridge

I should have admitted defeat long ago as there has been a rare but persistent error on Sandybridge where semaphore signaling did not propagate to the waiter, leading to a GPU hang. With the work on fence signaling for v4.9, the impact of using CPU driven signaling was greatly reduced wrt to the

[Intel-gfx] [CI 2/5] drm/i915: Remove obsolete ringbuffer emission for gen8+

Since removing the module parameter to force selection of ringbuffer emission for gen8, the code is defunct. Remove it. To put the difference into perspective, a couple of microbenchmarks (bdw i7-5557u, 20170324): ring execlists exec continuous

[Intel-gfx] [CI 1/5] drm/i915: Remove i915.enable_execlists module parameter

Execlists and legacy ringbuffer submission are no longer feature comparable (execlists now offer greater functionality that should overcome their performance hit) and obsoletes the unsafe module parameter, i.e. comparing the two modes of execution is no longer useful, so remove the debug tool.

Re: [Intel-gfx] [PATCH 4/4] drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write

Quoting Chris Wilson (2017-11-20 16:45:44) > Quoting Michel Thierry (2017-11-20 16:17:01) > > On 11/20/2017 4:34 AM, Chris Wilson wrote: > > > The hardware needs some time to process the information received in the > > > ExecList Submission Port, and expects us to not write anything more until > >

[Intel-gfx] [PATCH igt] tools: Stop opening the driver just to find the debugfs

Since the tools want to work without the module loaded, remove the assumption that we want to load the driver to find debugfs. Signed-off-by: Chris Wilson --- lib/igt_debugfs.c| 15 ++- tools/intel_display_poller.c | 8 +---

Re: [Intel-gfx] [PATCH 4/4] drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write

On 11/20/2017 4:34 AM, Chris Wilson wrote: The hardware needs some time to process the information received in the ExecList Submission Port, and expects us to not write anything more until it has 'acknowledged' this new submission by sending an IDLE_ACTIVE or PREEMPTED CSB event. If we do not

Re: [Intel-gfx] [PATCH igt] tools: Stop opening the driver just to find the debugfs

On Mon, Nov 20, 2017 at 04:01:24PM +, Chris Wilson wrote: > Since the tools want to work without the module loaded, remove the > assumption that we want to load the driver to find debugfs. So looking at the history it was actually Tomeu that caused this problem originally. That added the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter

== Series Details == Series: series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter URL : https://patchwork.freedesktop.org/series/34115/ State : success == Summary == Series 34115v1 series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module

Re: [Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On 20 November 2017 at 23:13, Daniel Vetter wrote: > On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: >> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote: >> > Hi all, >> > >> > Since I'm going slightly off-topic, I've tweaked the subject line and >> >

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Declare we allocated the guc clients

Quoting Michel Thierry (2017-11-20 21:52:06) > On 11/20/2017 1:19 PM, Chris Wilson wrote: > > Silence sparse over > > > > drivers/gpu/drm/i915/selftests/intel_guc.c:135 igt_guc_init_doorbell_hw() > > error: we previously assumed 'guc->execbuf_client' could be null (see line > > 123) > >

[Intel-gfx] [PATCH] drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to power on` in kernel log at boot time. This patch relates to the following bugs: * https://bugs.freedesktop.org/show_bug.cgi?id=103414 * https://bugzilla.kernel.org/show_bug.cgi?id=57591 Toshiba Satellite Z930 laptops needs

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter

== Series Details == Series: series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter URL : https://patchwork.freedesktop.org/series/34109/ State : failure == Summary == Applying: drm/i915: Remove i915.enable_execlists module parameter Patch failed at 0001

[Intel-gfx] [CI 5/5] drm/i915: Remove i915.semaphores modparam

Having disabled the broken semaphores on Sandybridge, there is no need for a modparam any more, so remove it in favour of a simple HAS_LEGACY_SEMAPHORES() guard. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Maarten

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[]

== Series Details == Series: drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[] URL : https://patchwork.freedesktop.org/series/34116/ State : warning == Summary == Series 34116v1 drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[]

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter

== Series Details == Series: series starting with [CI,1/5] drm/i915: Remove i915.enable_execlists module parameter URL : https://patchwork.freedesktop.org/series/34115/ State : warning == Summary == Test kms_cursor_crc: Subgroup cursor-64x64-dpms: pass -> SKIP

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Declare we allocated the guc clients

On 11/20/2017 1:19 PM, Chris Wilson wrote: Silence sparse over drivers/gpu/drm/i915/selftests/intel_guc.c:135 igt_guc_init_doorbell_hw() error: we previously assumed 'guc->execbuf_client' could be null (see line 123) drivers/gpu/drm/i915/selftests/intel_guc.c:142 igt_guc_init_doorbell_hw()

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Declare we allocated the guc clients

== Series Details == Series: drm/i915/selftests: Declare we allocated the guc clients URL : https://patchwork.freedesktop.org/series/34117/ State : success == Summary == Series 34117v1 drm/i915/selftests: Declare we allocated the guc clients

Re: [Intel-gfx] [PATCH v2] drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+

On Fri, Nov 17, 2017 at 08:01:46AM +, David Weinehall wrote: > GEN6_RC_VIDEO_FREQ is deprecated for >= gen10; > don't try to program it. > > v2: Use IS_GEN9() instead of INTEL_GEN() and remove comment (Rodrigo) > > Signed-off-by: David Weinehall >

[Intel-gfx] ✗ Fi.CI.IGT: failure for benchmarks/gem_exec_nop: fix engines selection

== Series Details == Series: benchmarks/gem_exec_nop: fix engines selection URL : https://patchwork.freedesktop.org/series/34114/ State : failure == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test drv_module_reload:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Declare we allocated the guc clients

== Series Details == Series: drm/i915/selftests: Declare we allocated the guc clients URL : https://patchwork.freedesktop.org/series/34117/ State : success == Summary == Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (shard-snb) fdo#102848 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for benchmarks/gem_exec_nop: fix engines selection

== Series Details == Series: benchmarks/gem_exec_nop: fix engines selection URL : https://patchwork.freedesktop.org/series/34114/ State : success == Summary == IGT patchset tested on top of latest successful build 9fb5344bab2540e3d12a7d3a94c2a3801a6fec36 tools/error_decode: Print ASCII user

Re: [Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Mon, Nov 20, 2017 at 8:13 AM, Daniel Vetter wrote: > On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: >> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote: >> > Hi all, >> > >> > Since I'm going slightly off-topic, I've tweaked the subject line and >>

Re: [Intel-gfx] [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote: > On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote: > > > Sorry this took so long. > > > > No worries. > > > > > > > > The vmwgfx part: Reviewed-by:

Re: [Intel-gfx] [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

On Mon, Nov 20, 2017 at 09:32:56AM -0800, Sinclair Yeh wrote: > On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote: > > On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote: > > > On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote: > > > > Sorry this took so long. > >

[Intel-gfx] [CI 4/5] drm/i915: Move debugfs/i915_semaphore_status to i915_engine_info

As the semaphores is just part of the engine, include it with the general pretty printer universally used for debugging. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH] drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[]

sparse spots drivers/gpu/drm/i915/gvt/opregion.c:234 alloc_and_init_virt_opregion() error: memcpy() 'header->signature' too small (16 vs 17) as gvt is indeed trying to memcpy a string longer than the signature[]. Fixes: b2d6ef70614e ("drm/i915/gvt: Let each vgpu has separate opregion memory")

[Intel-gfx] [PATCH igt] benchmarks/gem_exec_nop: fix engines selection

Code on loop() function shadowed function parameter which led to inability to try out different engines in the test: we always loaded RCS0. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103804 Signed-off-by: Dmitry Rogozhkin Cc: Chris Wilson

Re: [Intel-gfx] [PATCH igt] benchmarks/gem_exec_nop: fix engines selection

Quoting Dmitry Rogozhkin (2017-11-20 11:49:46) > Code on loop() function shadowed function parameter which led > to inability to try out different engines in the test: we always > loaded RCS0. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103804 > Signed-off-by: Dmitry Rogozhkin

[Intel-gfx] [CI 1/5] drm/i915: Remove i915.enable_execlists module parameter

Execlists and legacy ringbuffer submission are no longer feature comparable (execlists now offer greater functionality that should overcome their performance hit) and obsoletes the unsafe module parameter, i.e. comparing the two modes of execution is no longer useful, so remove the debug tool.

[Intel-gfx] [CI 5/5] drm/i915: Remove i915.semaphores modparam

Having disabled the broken semaphores on Sandybridge, there is no need for a modparam any more, so remove it in favour of a simple HAS_LEGACY_SEMAPHORES() guard. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Maarten

[Intel-gfx] [CI 3/5] drm/i915: Disable semaphores on Sandybridge

I should have admitted defeat long ago as there has been a rare but persistent error on Sandybridge where semaphore signaling did not propagate to the waiter, leading to a GPU hang. With the work on fence signaling for v4.9, the impact of using CPU driven signaling was greatly reduced wrt to the

Re: [Intel-gfx] [PATCH i-g-t 0/5] Import drm UAPI headers.

Petri Latvala writes: > On Sat, Nov 11, 2017 at 12:27:15AM +, Lionel Landwerlin wrote: >> Hey Eric, >> >> Like it did for Mesa I think this makes developers' lives easier. >> Not having to update libdrm and then compile against the right version just >> for the

[Intel-gfx] [CI 2/5] drm/i915: Remove obsolete ringbuffer emission for gen8+

Since removing the module parameter to force selection of ringbuffer emission for gen8, the code is defunct. Remove it. To put the difference into perspective, a couple of microbenchmarks (bdw i7-5557u, 20170324): ring execlists exec continuous

[Intel-gfx] [PATCH] drm/i915/selftests: Declare we allocated the guc clients

Silence sparse over drivers/gpu/drm/i915/selftests/intel_guc.c:135 igt_guc_init_doorbell_hw() error: we previously assumed 'guc->execbuf_client' could be null (see line 123) drivers/gpu/drm/i915/selftests/intel_guc.c:142 igt_guc_init_doorbell_hw() error: we previously assumed

Re: [Intel-gfx] Supporting Intel GPU tracing in gpuvis

On 11/20/2017 06:01 AM, Tvrtko Ursulin wrote: Hi, On 16/11/2017 20:42, Michael Sartain wrote: On Wed, Sep 6, 2017, at 02:09 AM, Chris Wilson wrote: Quoting Daniel Vetter (2017-09-06 08:46:50) Hi Pierre, On Tue, Sep 5, 2017 at 11:15 PM, Pierre-Loup A. Griffais

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

== Series Details == Series: drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log URL : https://patchwork.freedesktop.org/series/34125/ State : warning == Summary == Series 34125v1 drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

Re: [Intel-gfx] [PATCH i-g-t 7/7] tools/intel_watermark: Try not to dump nonexistent planes on SKL+

On Fri, 2017-09-15 at 20:57 +0300, Ville Syrjala wrote: > From: Dhinakaran Pandiyan This should be yours :) > > Having registers for nonexistent planes in the dumpo might end up being > rather confusing. Try to only include real planes. > Thanks for

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[]

On 2017.11.20 21:15:16 +, Chris Wilson wrote: > sparse spots > > drivers/gpu/drm/i915/gvt/opregion.c:234 alloc_and_init_virt_opregion() error: > memcpy() 'header->signature' too small (16 vs 17) > > as gvt is indeed trying to memcpy a string longer than the signature[]. > > Fixes:

Re: [Intel-gfx] [CI 20/21] drm/i915: Remove unsafe i915.enable_rc6

On Sun, Nov 19, 2017 at 6:32 AM, Chris Wilson wrote: > It has been many years since the last confirmed sighting (and fix) of an > RC6 related bug (usually a system hang). Remove the parameter to stop > users from setting dangerous values, as they often set it during

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Cleanup unwanted public symbols

On 2017.11.20 13:31:31 +, Chris Wilson wrote: > drivers/gpu/drm/i915/gvt/execlist.c:531:6: warning: symbol 'clean_execlist' > was not declared. Should it be static? > drivers/gpu/drm/i915/gvt/execlist.c:545:6: warning: symbol 'reset_execlist' > was not declared. Should it be static? >

Re: [Intel-gfx] linux-firmware pull request(KBL:DMC)

Hi, OK, this is not moving with speed we would like. What is blocking this to be merged? So consider this gentle ping. And just for question, if we are blocked by not merging to linux-firmware.git is that enough that firmware exists only on 01.org until this get merged to linux-firmware.git

Re: [Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: > Of course our CI is open, so if someone is supremely bored and wants to > backport more stuff for drm/i915, they could do that. But atm it doesn't > happen, and then having to deal with the fallout is not really great (like > I said,

Re: [Intel-gfx] [PATCH] i965: Always try to create a logical context

On Monday, November 20, 2017 1:29:42 AM PST Chris Wilson wrote: > Always enable use of HW logical contexts to preserve GPU state between > batches when the kernel supports such constructs, continuing to enforce > the required support for gen6+. > > At runtime, this effectively removes the

[Intel-gfx] [PATCH v2 1/3] drm/i915: Make ips_enabled a property depending on whether IPS is enabled, v2.

ips_enabled was used as a variable of whether IPS can be enabled or not, but should be used to test whether IPS is actually enabled. Changes since v1: - Call needs_modeset on new crtc state. (Ville) - IPS can be enabled with sprite plane enabled too. (Ville) - Fix CDCLK vs IPS workaround. (Ville)

[Intel-gfx] [PATCH (resend) 3/3] drm/i915: Re-enable fastboot by default

This fix was originally reverted because it left a chromebook pixel black, and no immediate fix was available. This has been fixed in the meantime. Rather than trying to remove the parameter, set it to default to true for now, so we can always back out if required. Signed-off-by: Maarten

[Intel-gfx] [PATCH v2 2/3] drm/i915: Enable IPS with only sprite plane visible too, v2.

This comment predates atomic, and I think with the way we currently track IPS, it's safe to enable this for the case we switch too. Changes since v1: - Keep IPS enabled when switching planes. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 4/4] drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write

The hardware needs some time to process the information received in the ExecList Submission Port, and expects us to not write anything more until it has 'acknowledged' this new submission by sending an IDLE_ACTIVE or PREEMPTED CSB event. If we do not follow this, the driver could write new data

[Intel-gfx] [PATCH 3/4] drm/i915/execlists: Assert that we don't get mixed IDLE_ACTIVE | COMPLETE events

If IDLE_ACTIVE is set, then all other bits are invalid. For us, we can assert that if we see a COMPLETE | PREEMPTED event, then it should be impossible for it to also contain an IDLE_ACTIVE flag. Suggested-by: Joonas Lahtinen Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 2/4] drm/i915/execlists: Reduce completed event mask to COMPLETE | PREEMPTED

Since we get a COMPLETE event when the context switch occurs on RING_HEAD == RING_TAIL and a PREEMPTED event when a switch occurs before that point COMPLETE | PREEMPTED should cover all possible context switch completion events. We can move the ELEMENT_SWITCH info message from the COMPLETED_MASK

[Intel-gfx] [PATCH 1/4] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

Since commit e1fee72c2ea2e9c0c6e6743d32a6832f21337d6c Author: Oscar Mateo Date: Thu Jul 24 17:04:40 2014 +0100 drm/i915/bdw: Avoid non-lite-restore preemptions execlists has listened to (ACTIVE_IDLE | ELEMENT_SWITCH) for detecting when one context completed and it

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix init_clock_gating for resume

On Thu, Nov 16, 2017 at 04:14:50PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2017-11-16 16:02:15) > > From: Ville Syrjälä > > > > Moving the init_clock_gating() call from intel_modeset_init_hw() to > > intel_modeset_gem_init() had an unintended effect of

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Enable IPS with only sprite plane visible too, v2.

On Mon, Nov 20, 2017 at 01:23:36PM +0100, Maarten Lankhorst wrote: > This comment predates atomic, and I think with the way we currently > track IPS, it's safe to enable this for the case we switch too. > > Changes since v1: > - Keep IPS enabled when switching planes. > > Signed-off-by: Maarten

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Expose more GPU properties through sysfs (rev3)

== Series Details == Series: drm/i915: Expose more GPU properties through sysfs (rev3) URL : https://patchwork.freedesktop.org/series/33950/ State : success == Summary == Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (shard-snb) fdo#102707

Re: [Intel-gfx] [PATCH 10/10] video/hdmi: Pass buffer size to infoframe unpack functions

On 11/13/2017 06:04 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > To make sure the infoframe unpack functions don't end up examining > stack garbage or oopsing, let's pass in the size of the buffer. > > Cc: Thierry Reding > Cc: Hans

Re: [Intel-gfx] 4.9.62: intermittent flicker after upgrade from 4.9.61

Maarten Lankhorst wrote: > Op 20-11-17 om 09:51 schreef Rainer Fiebig: >> Jani Nikula wrote: >>> On Sun, 19 Nov 2017, Greg KH wrote: On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: > Greg KH wrote: >> On Sun, Nov 19, 2017 at 12:56:26PM

[Intel-gfx] [PATCH v2 0/3] drm/i915: Enable fastboot, v3!

Updates to IPS fixes, and then flipping the switch. :) Maarten Lankhorst (3): drm/i915: Make ips_enabled a property depending on whether IPS is enabled, v2. drm/i915: Enable IPS with only sprite plane visible too, v2. drm/i915: Re-enable fastboot by default

Re: [Intel-gfx] [PATCH v3 04/11] drm/i915: Handle adjust better in intel_pipe_config_compare

On Mon, Nov 20, 2017 at 12:53:28PM +0200, Ville Syrjälä wrote: > On Mon, Nov 20, 2017 at 11:38:49AM +0100, Daniel Vetter wrote: > > On Mon, Nov 13, 2017 at 07:24:22PM +0200, Ville Syrjälä wrote: > > > On Fri, Nov 10, 2017 at 02:02:45PM +0100, Daniel Vetter wrote: > > > > On Fri, Nov 10, 2017 at

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable fastboot, v3!

== Series Details == Series: drm/i915: Enable fastboot, v3! URL : https://patchwork.freedesktop.org/series/34098/ State : success == Summary == Series 34098v1 drm/i915: Enable fastboot, v3! https://patchwork.freedesktop.org/api/1.0/series/34098/revisions/1/mbox/ Test kms_busy:

Re: [Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: > On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote: > > Hi all, > > > > Since I'm going slightly off-topic, I've tweaked the subject line and > > trimmed some of the conversation. > > I believe everyone in the CC list

  1   2   >