[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE (rev2)

== Series Details == Series: drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE (rev2) URL : https://patchwork.freedesktop.org/series/34044/ State : success == Summary == Warning: bzip CI_DRM_3359/shard-glkb6/results1.json.bz2 wasn't in correct JSON format Test kms_flip:

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/lrc: Stop writing to ELSP until HW has processed the previous write

== Series Details == Series: drm/i915/lrc: Stop writing to ELSP until HW has processed the previous write URL : https://patchwork.freedesktop.org/series/34043/ State : warning == Summary == Warning: bzip CI_DRM_3359/shard-glkb6/results1.json.bz2 wasn't in correct JSON format Test kms_flip:

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/9] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

== Series Details == Series: series starting with [CI,1/9] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE URL : https://patchwork.freedesktop.org/series/34049/ State : warning == Summary == Series 34049v1 series starting with [CI,1/9] drm/i915/execlists: Listen to

[Intel-gfx] [CI 5/9] 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 8/9] 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: success for drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE (rev2)

== Series Details == Series: drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE (rev2) URL : https://patchwork.freedesktop.org/series/34044/ State : success == Summary == Series 34044v2 drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

[Intel-gfx] [CI 7/9] 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 1/9] 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

[Intel-gfx] [CI 4/9] 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 6/9] 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 9/9] drm/i915: Unwind incomplete legacy context switches

The legacy context switch for ringbuffer submission is multistaged, where each of those stages may fail. However, we were updating global state after some stages, and so we had to force the incomplete request to be submitted because we could not unwind. Save the global state before performing the

[Intel-gfx] [CI 3/9] 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] [CI 2/9] 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.BAT: success for drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

== Series Details == Series: drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE URL : https://patchwork.freedesktop.org/series/34044/ State : success == Summary == Series 34044v1 drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

[Intel-gfx] [PATCH v2] 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] drm/i915/execlists: Listen to COMPLETE context event not ACTIVE_IDLE

Quoting Michel Thierry (2017-11-18 00:53:57) > On 11/17/2017 4:31 PM, Chris Wilson wrote: > > Since its inception, execlists has listened to (ACTIVE_IDLE | > > ELEMENT_SWITCH) for detecting when one context completed and it either > > continued onto the next (in port 1) or idled. We would always

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

On 11/17/2017 4:31 PM, Chris Wilson wrote: Since its inception, execlists has listened to (ACTIVE_IDLE | ELEMENT_SWITCH) for detecting when one context completed and it either continued onto the next (in port 1) or idled. We would always see COMPLETE | ACTIVE_IDLE on the final context-switch

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lrc: Stop writing to ELSP until HW has processed the previous write

== Series Details == Series: drm/i915/lrc: Stop writing to ELSP until HW has processed the previous write URL : https://patchwork.freedesktop.org/series/34043/ State : success == Summary == Series 34043v1 drm/i915/lrc: Stop writing to ELSP until HW has processed the previous write

Re: [Intel-gfx] [PATCH i-g-t 4/4] tests: Rename chamelium to kms_chamelium.

Reviewed-by: Lyude Paul On Thu, 2017-11-16 at 13:45 +0100, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > tests/Makefile.am | 6 +++--- > tests/intel-ci/fast-feedback.testlist | 18

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

Quoting Michel Thierry (2017-11-18 00:30:38) > 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

[Intel-gfx] [RFC 1/2] drm/i915: Extend GuC action fast spin time

From: John Harrison The 'request pre-emption' GuC command seems to be slower than other commands. It typically takes 20-30us on a GP-MRB system (BXT). That means that the super-fast busy-spin wait in the GuC send action code hits the 10us time out. It then drops

[Intel-gfx] [RFC 0/2] Excessive latency in GuC send action

From: John Harrison While working on a customer project, it was noticed that the time taken to issue a pre-emption request to the GuC would vary quite significantly. The correct case was low microseconds but the worst case was tens of milliseconds. Two separate issues

[Intel-gfx] [RFC 2/2] drm/i915: Avoid stalling on GuC send mutex lock

From: John Harrison There is a mutex_lock in the GuC send action code path to ensure serialised access to the host-to-GuC mechanism. Acquiring the lock apparently sees random stalls of around 6ms. That is even when the lock is definitely not acquired by any other

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

Since its inception, execlists has listened to (ACTIVE_IDLE | ELEMENT_SWITCH) for detecting when one context completed and it either continued onto the next (in port 1) or idled. We would always see COMPLETE | ACTIVE_IDLE on the final context-switch event, but on recent gen it appears that we now

[Intel-gfx] [PATCH] drm/i915/lrc: Stop 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

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib/igt_kms: Make igt_output_from_connector probe all outputs

Reviewed-by: Lyude Paul On Thu, 2017-11-16 at 13:45 +0100, Maarten Lankhorst wrote: > igt_output_from_connector should be used for disconnected outputs > too, this is useful for chamelium testing, where disconnected outputs > may reappear. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH i-g-t 3/4] tests/chamelium: Only initialize igt_display once

Reviewed-by: Lyude Paul On Thu, 2017-11-16 at 13:45 +0100, Maarten Lankhorst wrote: > Instead of first calling kmstest_unset_all_crtcs, and calling > igt_display_init for each test, use igt_display_reset to reset > igt_display between tests, and use atomic commit to disable all

Re: [Intel-gfx] [PATCH i-g-t 1/4] lib/igt_kms: Add igt_display_reset function.

Reviewed-by: Lyude Paul On Thu, 2017-11-16 at 13:45 +0100, Maarten Lankhorst wrote: > A lot of code duplicates this, but it should be handled in the core. > Add it and use it after igt_display_init(), the tests have to be > converted one by one. > > Signed-off-by: Maarten

[Intel-gfx] Updated drm-intel-testing

Hi all, The following changes tagged drm-intel-testing-2017-11-17-2: drm-intel-next-2017-11-17-1: More change sets for 4.16: - Many improvements for selftests and other igt tests (Chris) - Forcewake with PUNIT->PMIC bus fixes and robustness (Hans) - Define an engine class for uABI (Tvrtko) -

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

On Fri, Nov 17, 2017 at 08:32:19PM +, Ville Syrjälä wrote: > On Fri, Nov 17, 2017 at 12:12:15PM -0800, Rodrigo Vivi wrote: > > On Fri, Nov 17, 2017 at 07:19:10PM +, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Rename enum plane to enum

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Plane assert/readout cleanups etc. (rev9)

== Series Details == Series: drm/i915: Plane assert/readout cleanups etc. (rev9) URL : https://patchwork.freedesktop.org/series/31758/ State : warning == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test drv_module_reload:

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

On Fri, Nov 17, 2017 at 12:12:15PM -0800, Rodrigo Vivi wrote: > On Fri, Nov 17, 2017 at 07:19:10PM +, 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. >

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

On Fri, Nov 17, 2017 at 07:19:10PM +, 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. Oh! I should had read this before commenting on the cover letter...

Re: [Intel-gfx] [PATCH v3 00/10] drm/i915: Plane assert/readout cleanups etc.

On Fri, Nov 17, 2017 at 07:19:07PM +, Ville Syrjala wrote: > From: Ville Syrjälä > > OK, one more time. This time with s/plane/i9xx_plane/ etc. all over. why not intel_plane?! > Maybe that will make everyone happy? Unlikely, but let's try. :) > > Patch 3

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Plane assert/readout cleanups etc. (rev9)

== Series Details == Series: drm/i915: Plane assert/readout cleanups etc. (rev9) URL : https://patchwork.freedesktop.org/series/31758/ State : success == Summary == Series 31758v9 drm/i915: Plane assert/readout cleanups etc.

[Intel-gfx] [PATCH v3 10/10] drm/i915: Add rudimentary plane state verification

From: Ville Syrjälä Check that the planes are in the state we expect them to be. For now we can only check whether each plane is correctly enabled or disabled. In the future we may want to expand the plane state readout to support a more thorough verification. v2:

[Intel-gfx] [PATCH v3 09/10] drm/i915: Use plane->get_hw_state() for initial plane fb readout

From: Ville Syrjälä Since we now have a ->get_hw_state() method for planes, let's use that during the initial plane fb readout. v2: s/plane/i9xx_plane/ etc. (James) Cc: James Ausmus Cc: Daniel Vetter Suggested-by:

[Intel-gfx] [PATCH v2 06/10] drm/i915: Nuke ironlake_get_initial_plane_config()

From: Ville Syrjälä The only relevant difference between i9xx_get_initial_plane_config() and ironlake_get_initial_plane_config() is the HSW/BDW TILEOFF handling. Add that to i9xx_get_initial_plane_config() and nuke ironlake_get_initial_plane_config(). v2:

[Intel-gfx] [PATCH v3 00/10] drm/i915: Plane assert/readout cleanups etc.

From: Ville Syrjälä OK, one more time. This time with s/plane/i9xx_plane/ etc. all over. Maybe that will make everyone happy? Unlikely, but let's try. Patch 3 is the only one missing r-b. Ville Syrjälä (10): drm/i915: Add .get_hw_state() method for planes

[Intel-gfx] [PATCH v2 07/10] drm/i915: Switch fbc over to for_each_new_intel_plane_in_state()

From: Ville Syrjälä Stop using the old for_each_intel_plane_in_state() type iteration macro and replace it with for_each_new_intel_plane_in_state(). And similarly replace drm_atomic_get_existing_crtc_state() with intel_atomic_get_new_crtc_state(). Switch over to

[Intel-gfx] [PATCH v3 02/10] drm/i915: Redo plane sanitation during readout

From: Ville Syrjälä Unify the plane disabling during state readout by pulling the code into a new helper intel_plane_disable_noatomic(). We'll also read out the state of all planes, so that we know which planes really need to be diabled. Additonally we change the

[Intel-gfx] [PATCH v3 08/10] drm/i915: Nuke crtc->plane

From: Ville Syrjälä Eliminate crtc->plane since it's pretty much a layering violation. We can always get the plane via crtc->primary if we actually need it. The only ugly thing left is plane_to_crtc_mapping[], but that's still needed by the pre-g4x watermark code.

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

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 per-pipe. We need the old global identifier to index the primary plane (and

[Intel-gfx] [PATCH v3 04/10] drm/i915: Use enum i9xx_plane_id for the .get_fifo_size() hooks

From: Ville Syrjälä Replace the 0 and 1 with PLANE_A and PLANE_B in the pre-g4x wm code. v2: s/old_plane_id/i9xx_plane_id/ (Daniel) v3: s/plane/i9xx_plane/ etc. (James) Cc: James Ausmus Cc: Daniel Vetter

[Intel-gfx] [PATCH v4 01/10] drm/i915: Add .get_hw_state() method for planes

From: Ville Syrjälä Add a .get_hw_state() method for planes, returning true or false depending on whether the plane is enabled. Use it to rewrite the plane enabled/disabled asserts in platform agnostic fashion. We do lose the pre-gen4 plane<->pipe mapping checks,

[Intel-gfx] [PATCH v5 05/10] drm/i915: Cleanup enum pipe/enum plane_id/enum i9xx_plane_id in initial fb readout

From: Ville Syrjälä Use enum pipe, enum plane_id, and enum i9xx_plane_id consistently in the initial framebuffe readout. v2: Use old_plane_id in the ilk code v3: s/old_plane_id/i9xx_plane_id/ (Daniel) v4: Rebase due to GLK/CNL PLANE_COLOR_CTL alpha stuff v5:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix init_clock_gating for resume (rev2)

== Series Details == Series: drm/i915: Fix init_clock_gating for resume (rev2) URL : https://patchwork.freedesktop.org/series/33718/ State : success == Summary == Series 33718v2 drm/i915: Fix init_clock_gating for resume https://patchwork.freedesktop.org/api/1.0/series/33718/revisions/2/mbox/

Re: [Intel-gfx] [PATCH v2 2/2] i915/drrs/debugfs: crtc id and psr status

On Tue, Nov 07, 2017 at 06:40:08PM +, Ramalingam C wrote: > From: "C, Ramalingam" > > Existing debugfs entry i915_drrs_status is updated with crtc id and > if PSR is cause for DRRS disabled state. > > [v2]: Dropped the module parameter details as ctl moved from

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Runtime disable for eDP DRRS

On Tue, Nov 07, 2017 at 06:38:23PM +, Ramalingam C wrote: > From: "C, Ramalingam" > > Debugfs called i915_drrs_ctl is added to enable and disable the > eDP DRRS. Writing 0 will disable the feature, whereas non-zero > will enable the feature. > > Possibility of

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev3)

Quoting Patchwork (2017-11-17 18:37:16) > == Series Details == > > Series: drm/i915/selftests: Report ENOMEM clearly for an allocation failure > (rev3) > URL : https://patchwork.freedesktop.org/series/33994/ > State : success > > == Logs == > > For more details see: >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev3)

== Series Details == Series: drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev3) URL : https://patchwork.freedesktop.org/series/33994/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-shrfb-pgflip-blt: pass

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+ (rev2)

== Series Details == Series: drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+ (rev2) URL : https://patchwork.freedesktop.org/series/33608/ State : success == Summary == Series 33608v2 drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+

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

== Series Details == Series: drm/i915: Enable fastboot, v2! URL : https://patchwork.freedesktop.org/series/34010/ State : success == Summary == Test drv_selftest: Subgroup mock_sanitycheck: pass -> DMESG-WARN (shard-hsw) fdo#103719 Test kms_frontbuffer_tracking:

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

On Fri, Nov 17, 2017 at 03:37:53PM +, Maarten Lankhorst wrote: > Small fixes for IPS, and then we flip the switch! :-) > > Maarten Lankhorst (3): > drm/i915: Make ips_enabled a property depending on whether IPS is > enabled. > drm/i915: Enable IPS for sprite plane > drm/i915:

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

On Fri, Nov 17, 2017 at 01:08:25AM +, Radhakrishna Sripada wrote: > This reverts commit 8f067837c4b713ce2e69be95af7b2a5eb3bd7de8. > > HSD says "WA withdrawn. It was causing corruption with some images. > WA is not strictly necessary since this bug just causes loss of FBC > compression with

Re: [Intel-gfx] [PATCH] drm/i915: Add a policy note for removing workarounds

Quoting Rodrigo Vivi (2017-11-17 17:33:49) > On Fri, Nov 17, 2017 at 11:11:28AM +, Jani Nikula wrote: > > On Fri, 17 Nov 2017, Chris Wilson wrote: > > > Rodrigo gave a persuasive argument for keeping workarounds: that they > > > serve as a good guide for the bring up

Re: [Intel-gfx] [GIT PULL] gvt-next for 4.16

On Fri, Nov 17, 2017 at 02:02:51AM +, Zhenyu Wang wrote: > On 2017.11.16 12:20:14 -0800, Rodrigo Vivi wrote: > > Hi Zhenyu, > > > > On Thu, Nov 16, 2017 at 09:20:07AM +, Zhenyu Wang wrote: > > > > > > Hi, > > > > > > As we missed 4.15 cycle, here's the bigger initial 4.16 gvt-next pull,

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

== Series Details == Series: series starting with [CI,1/2] drm/i915: Pull the unconditional GPU cache invalidation into request construction URL : https://patchwork.freedesktop.org/series/34016/ State : warning == Summary == Series 34016v1 series starting with [CI,1/2] drm/i915: Pull the

Re: [Intel-gfx] [PATCH] drm/i915: Add a policy note for removing workarounds

On Fri, Nov 17, 2017 at 11:11:28AM +, Jani Nikula wrote: > On Fri, 17 Nov 2017, Chris Wilson wrote: > > Rodrigo gave a persuasive argument for keeping workarounds: that they > > serve as a good guide for the bring up of the next generation. Not only > > do

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes

On Fri, Nov 17, 2017 at 01:21:35PM +, Ville Syrjälä wrote: > On Thu, Nov 16, 2017 at 12:49:23PM -0800, Rodrigo Vivi wrote: > > On Thu, Nov 16, 2017 at 07:14:47PM +, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > The current code is trying to be

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev3)

== Series Details == Series: drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev3) URL : https://patchwork.freedesktop.org/series/33994/ State : success == Summary == Series 33994v3 drm/i915/selftests: Report ENOMEM clearly for an allocation failure

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev2)

== Series Details == Series: drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev2) URL : https://patchwork.freedesktop.org/series/33994/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-a: skip

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Pull the unconditional GPU cache invalidation into request construction (rev2)

== Series Details == Series: drm/i915: Pull the unconditional GPU cache invalidation into request construction (rev2) URL : https://patchwork.freedesktop.org/series/34007/ State : warning == Summary == Series 34007v2 drm/i915: Pull the unconditional GPU cache invalidation into request

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

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

[Intel-gfx] [PATCH v5] drm/i915/selftests: Report ENOMEM clearly for an allocation failure

If we can not run the drunk_hole test because we couldn't allocate the memory for the permutation array (even after we tried trimming the size), report a clear ENOMEM. Similary, if we are asked to operate on a hole too small for ourselves, make it skip quietly. v2: Avoid malloc(0) since that

[Intel-gfx] [CI 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] [CI 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.BAT: success for drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev2)

== Series Details == Series: drm/i915/selftests: Report ENOMEM clearly for an allocation failure (rev2) URL : https://patchwork.freedesktop.org/series/33994/ State : success == Summary == Series 33994v2 drm/i915/selftests: Report ENOMEM clearly for an allocation failure

[Intel-gfx] [CI] 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 drm/i915: Expose more GPU properties through sysfs (rev2)

== Series Details == Series: drm/i915: Expose more GPU properties through sysfs (rev2) URL : https://patchwork.freedesktop.org/series/33950/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail -> PASS

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

Quoting Chris Wilson (2017-11-17 15:23:58) > @@ -1818,8 +1814,7 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb) > /* Unconditionally flush any chipset caches (for streaming writes). */ > i915_gem_chipset_flush(eb->i915); > > - /* Unconditionally invalidate GPU

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Report ENOMEM clearly for an allocation failure

On 17 November 2017 at 15:31, Chris Wilson wrote: > If we can not run the drunk_hole test because we couldn't allocate the > memory for the permutation array (even after we tried trimming the > size), report a clear ENOMEM. Similary, if we are asked to operate on a >

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

== Series Details == Series: series starting with [CI,1/2] drm/i915: Pull the unconditional GPU cache invalidation into request construction URL : https://patchwork.freedesktop.org/series/34008/ State : failure == Summary == Series 34008v1 series starting with [CI,1/2] drm/i915: Pull the

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Report ENOMEM clearly for an allocation failure

On 17 November 2017 at 15:31, Chris Wilson wrote: > If we can not run the drunk_hole test because we couldn't allocate the > memory for the permutation array (even after we tried trimming the > size), report a clear ENOMEM. Similary, if we are asked to operate on a >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Enable IPS for sprite plane

On Fri, Nov 17, 2017 at 04:37:55PM +0100, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_display.c | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Pull the unconditional GPU cache invalidation into request construction

== Series Details == Series: drm/i915: Pull the unconditional GPU cache invalidation into request construction URL : https://patchwork.freedesktop.org/series/34007/ State : failure == Summary == Series 34007v1 drm/i915: Pull the unconditional GPU cache invalidation into request construction

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

On Fri, Nov 17, 2017 at 04:37:54PM +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. > > Signed-off-by: Maarten Lankhorst > --- >

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

On Thu, Nov 16, 2017 at 03:21:32PM -0800, James Ausmus wrote: > On Mon, Oct 23, 2017 at 05:50:32PM +0300, 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. >

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

== Series Details == Series: drm/i915: Expose more GPU properties through sysfs (rev2) URL : https://patchwork.freedesktop.org/series/33950/ State : success == Summary == Series 33950v2 drm/i915: Expose more GPU properties through sysfs

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

Small fixes for IPS, and then we flip the switch! :-) Maarten Lankhorst (3): drm/i915: Make ips_enabled a property depending on whether IPS is enabled. drm/i915: Enable IPS for sprite plane drm/i915: Re-enable fastboot by default drivers/gpu/drm/i915/i915_params.h| 2 +-

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

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. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 75 ---

[Intel-gfx] [PATCH 2/3] drm/i915: Enable IPS for sprite plane

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index

[Intel-gfx] [(resend) PATCH 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] drm/i915/selftests: Report ENOMEM clearly for an allocation failure

If we can not run the drunk_hole test because we couldn't allocate the memory for the permutation array (even after we tried trimming the size), report a clear ENOMEM. Similary, if we are asked to operate on a hole too small for ourselves, make it skip quietly. v2: Avoid malloc(0) since that

[Intel-gfx] [CI 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] [CI 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] [CI] 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

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

On 17/11/17 10:53, Chris Wilson wrote: Quoting Lionel Landwerlin (2017-11-16 16:00:03) 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] [PATCH v2 4/4] drm/i915: expose EU topology through sysfs

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 of the GPU with the OA unit, because signals

[Intel-gfx] [PATCH v2 2/4] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reused it. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git

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

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 ├── rcs │   └── 0 │   ├── capabilities │   ├── class │  

[Intel-gfx] [PATCH v2 1/4] drm/i915: store all subslice masks

Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all

[Intel-gfx] [PATCH v2 0/4] drm/i915: Expose more GPU properties through sysfs

Hi, An update based on Chris & Tvrtko's feedback. Cheers, Lionel Landwerlin (4): drm/i915: store all subslice masks drm/i915/debugfs: reuse max slice/subslices already stored in sseu drm/i915: expose engine availability through sysfs drm/i915: expose EU topology through sysfs

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Automatic i915_switch_context for legacy

== Series Details == Series: series starting with [CI,1/2] drm/i915: Automatic i915_switch_context for legacy URL : https://patchwork.freedesktop.org/series/34005/ State : failure == Summary == Series 34005v1 series starting with [CI,1/2] drm/i915: Automatic i915_switch_context for legacy

Re: [Intel-gfx] [(resend) PATCH 1/2] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

Op 17-11-17 om 15:53 schreef Ville Syrjälä: > On Fri, Nov 17, 2017 at 03:47:58PM +0100, Maarten Lankhorst wrote: >> Op 17-11-17 om 14:31 schreef Ville Syrjälä: >>> On Wed, Nov 15, 2017 at 05:31:56PM +0100, Maarten Lankhorst wrote: The watermarks it should calculate against are the old optimal

[Intel-gfx] [CI 2/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] [CI 1/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

Re: [Intel-gfx] [(resend) PATCH 1/2] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

On Fri, Nov 17, 2017 at 03:47:58PM +0100, Maarten Lankhorst wrote: > Op 17-11-17 om 14:31 schreef Ville Syrjälä: > > On Wed, Nov 15, 2017 at 05:31:56PM +0100, Maarten Lankhorst wrote: > >> The watermarks it should calculate against are the old optimal watermarks. > >> The currently active crtc

Re: [Intel-gfx] [(resend) PATCH 1/2] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

Op 17-11-17 om 14:31 schreef Ville Syrjälä: > On Wed, Nov 15, 2017 at 05:31:56PM +0100, Maarten Lankhorst wrote: >> The watermarks it should calculate against are the old optimal watermarks. >> The currently active crtc watermarks are pure fiction, and are invalid in >> case of a nonblocking

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Automatic i915_switch_context for legacy

== Series Details == Series: drm/i915: Automatic i915_switch_context for legacy URL : https://patchwork.freedesktop.org/series/34002/ State : failure == Summary == Test gem_exec_reloc: Subgroup basic-range: pass -> INCOMPLETE (shard-snb) Subgroup

  1   2   >