Re: [Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

On Fri, 24 Nov 2017, Matthew Auld wrote: > From: Joonas Lahtinen Please CC the linux kernel mailinglist on patches related to x86. The MAINTAINERS file says: X86 ARCHITECTURE (32-BIT AND 64-BIT) M: Thomas Gleixner M: Ingo Molnar

[Intel-gfx] ✗ Fi.CI.IGT: warning for make stolen resource centric (rev3)

== Series Details == Series: make stolen resource centric (rev3) URL : https://patchwork.freedesktop.org/series/34256/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-cur-indfb-draw-render: skip -> PASS (shard-hsw)

Re: [Intel-gfx] [PATCH 9/9] drm/i915: prefer resource_size_t for everything stolen

Quoting Matthew Auld (2017-11-24 21:29:30) > Keeps things consistent now that we make use of struct resource. This > should keep us covered in case we ever get huge amounts of stolen > memory. > > v2: bunch of missing conversions (Chris) > > Signed-off-by: Matthew Auld >

Re: [Intel-gfx] [PATCH 8/9] drm/i915: make mappable struct resource centric

Quoting Matthew Auld (2017-11-24 21:29:29) > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Paulo Zanoni > --- > diff --git

Re: [Intel-gfx] [PATCH 7/9] drm/i915: make reserved struct resource centric

Quoting Matthew Auld (2017-11-24 21:29:28) Always have a small explanation here. "Now that we are using struct resource to track the stolen region, it is more convenient if we track the reserved portion of that region in a resource as well." > v2: s/<= end + 1/< end/ (Chris) > > Signed-off-by:

Re: [Intel-gfx] [PATCH 6/9] drm/i915: make dsm struct resource centric

Quoting Matthew Auld (2017-11-24 21:29:27) > v2: check range_overflow when writing to 32b registers (Chris) > pepper in some comments (Chris) > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 5/9] drm/i915: s/mappable_end/mappable_size/

Quoting Matthew Auld (2017-11-24 21:29:26) > In a later patch we introduce 'struct resource mappable', which means we > will have both mappable.end and mappable_end, both meaning different > things. Therefore to avoid any confusion prefer mappable_size for > mappable_end, since it is effectively

Re: [Intel-gfx] [PATCH 4/9] drm/i915: nuke the duplicated stolen discovery

Quoting Matthew Auld (2017-11-24 21:29:25) > We duplicate the stolen discovery code in early-quirks and in i915, > however now the stolen region is exported as a resource from > early-quirks we can nuke the duplication. > > Signed-off-by: Matthew Auld > Cc: Joonas

Re: [Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

Quoting Matthew Auld (2017-11-24 21:29:22) > From: Joonas Lahtinen > > In preparation for upcoming SKUs, allow more freedom in placement > of the Intel graphics stolen memory by BIOS to full 64bit range. > > v2: export the stolen region as a resource > fix

[Intel-gfx] ✓ Fi.CI.BAT: success for make stolen resource centric (rev3)

== Series Details == Series: make stolen resource centric (rev3) URL : https://patchwork.freedesktop.org/series/34256/ State : success == Summary == Series 34256v3 make stolen resource centric https://patchwork.freedesktop.org/api/1.0/series/34256/revisions/3/mbox/ Test gem_exec_reloc:

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Aggregate all RC6 states into one counter

Quoting Chris Wilson (2017-11-24 20:40:31) > Quoting Tvrtko Ursulin (2017-11-24 17:13:31) > > From: Tvrtko Ursulin > > > > Chris has discovered that RC6, RC6p and RC6pp counters are mutually > > exclusive, and even that on some SNB SKUs you get RC6p increasing, and on >

[Intel-gfx] [PATCH 6/9] drm/i915: make dsm struct resource centric

v2: check range_overflow when writing to 32b registers (Chris) pepper in some comments (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni ---

[Intel-gfx] [PATCH 7/9] drm/i915: make reserved struct resource centric

v2: s/<= end + 1/< end/ (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.h| 4

[Intel-gfx] [PATCH 8/9] drm/i915: make mappable struct resource centric

Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni --- drivers/gpu/drm/i915/gvt/gvt.h| 2 +- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH 4/9] drm/i915: nuke the duplicated stolen discovery

We duplicate the stolen discovery code in early-quirks and in i915, however now the stolen region is exported as a resource from early-quirks we can nuke the duplication. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [PATCH 5/9] drm/i915: s/mappable_end/mappable_size/

In a later patch we introduce 'struct resource mappable', which means we will have both mappable.end and mappable_end, both meaning different things. Therefore to avoid any confusion prefer mappable_size for mappable_end, since it is effectively the size of the resource. Signed-off-by: Matthew

[Intel-gfx] [PATCH 9/9] drm/i915: prefer resource_size_t for everything stolen

Keeps things consistent now that we make use of struct resource. This should keep us covered in case we ever get huge amounts of stolen memory. v2: bunch of missing conversions (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc:

[Intel-gfx] [PATCH 3/9] x86/early-quirks: reverse the if ladders

Makes things much easier to follow. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris Wilson

[Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

From: Joonas Lahtinen In preparation for upcoming SKUs, allow more freedom in placement of the Intel graphics stolen memory by BIOS to full 64bit range. v2: export the stolen region as a resource fix u16 << 16 (Chris) Signed-off-by: Joonas Lahtinen

[Intel-gfx] [PATCH 2/9] x86/early-quirks: replace the magical increment start values

Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris

[Intel-gfx] [PATCH 0/9] make stolen resource centric

Continuation of Paulo' stolen series[1], addressing the feedback from Joonas and Chris. [1] https://patchwork.freedesktop.org/series/30923/ Joonas Lahtinen (1): x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit Matthew Auld (8): x86/early-quirks: replace the

Re: [Intel-gfx] [PATCH] drm/i915/guc: Use consistent name for scratch register count

Quoting Michal Wajdeczko (2017-11-24 17:02:39) > We should be consistent on naming of similar definitions. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Joonas Lahtinen > Cc: Sagar Arun Kamble

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Aggregate all RC6 states into one counter

Quoting Tvrtko Ursulin (2017-11-24 17:13:31) > From: Tvrtko Ursulin > > Chris has discovered that RC6, RC6p and RC6pp counters are mutually > exclusive, and even that on some SNB SKUs you get RC6p increasing, and on > the others RC6. > > Furthermore RC6p and RC6pp were

Re: [Intel-gfx] [PATCH i-g-t] intel/pmu: Catch-up with i915 RC6 aggregation changes

Quoting Tvrtko Ursulin (2017-11-24 17:16:18) > From: Tvrtko Ursulin > > Since i915 PMU is removing separate RC6 counters and now aggregates all > under a single one, catch up the test and intel-gpu-overlay with those > changes. > > Signed-off-by: Tvrtko Ursulin

[Intel-gfx] ✗ Fi.CI.IGT: warning for intel/pmu: Catch-up with i915 RC6 aggregation changes

== Series Details == Series: intel/pmu: Catch-up with i915 RC6 aggregation changes URL : https://patchwork.freedesktop.org/series/34371/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: fail -> SKIP

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/guc: Use consistent name for scratch register count

== Series Details == Series: drm/i915/guc: Use consistent name for scratch register count URL : https://patchwork.freedesktop.org/series/34369/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: pass -> FAIL

[Intel-gfx] ✗ Fi.CI.IGT: failure for make stolen resource centric (rev2)

== Series Details == Series: make stolen resource centric (rev2) URL : https://patchwork.freedesktop.org/series/34256/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: pass -> FAIL (shard-snb)

Re: [Intel-gfx] [PATCH 8/8] drm/i915: prefer resource_size_t for everything stolen

Quoting Matthew Auld (2017-11-24 17:56:34) > On 24 November 2017 at 16:54, Chris Wilson wrote: > > Quoting Matthew Auld (2017-11-24 16:42:57) > >> Keeps things consistent now that we make use of struct resource. This > >> should keep us covered in case we ever get huge

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Aggregate all RC6 states into one counter

Quoting Chris Wilson (2017-11-24 18:19:03) > Quoting Tvrtko Ursulin (2017-11-24 17:13:31) > > From: Tvrtko Ursulin > > > > Chris has discovered that RC6, RC6p and RC6pp counters are mutually > > exclusive, and even that on some SNB SKUs you get RC6p increasing, and on >

[Intel-gfx] ✓ Fi.CI.BAT: success for intel/pmu: Catch-up with i915 RC6 aggregation changes

== Series Details == Series: intel/pmu: Catch-up with i915 RC6 aggregation changes URL : https://patchwork.freedesktop.org/series/34371/ State : success == Summary == IGT patchset tested on top of latest successful build c6577473df7117b7a6e030605df1e28cd0e55708 lib/igt_core: Move write_stderr

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] igt: Remove Android support

== Series Details == Series: series starting with [1/2] igt: Remove Android support URL : https://patchwork.freedesktop.org/series/34365/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail -> PASS

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Aggregate all RC6 states into one counter

Quoting Tvrtko Ursulin (2017-11-24 17:13:31) > From: Tvrtko Ursulin > > Chris has discovered that RC6, RC6p and RC6pp counters are mutually > exclusive, and even that on some SNB SKUs you get RC6p increasing, and on > the others RC6. > > Furthermore RC6p and RC6pp were

Re: [Intel-gfx] [PATCH i-g-t] intel/pmu: Catch-up with i915 RC6 aggregation changes

Quoting Tvrtko Ursulin (2017-11-24 17:16:18) > From: Tvrtko Ursulin > > Since i915 PMU is removing separate RC6 counters and now aggregates all > under a single one, catch up the test and intel-gpu-overlay with those > changes. First run failed (perf_pmu:1928)

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pmu: Aggregate all RC6 states into one counter

== Series Details == Series: drm/i915/pmu: Aggregate all RC6 states into one counter URL : https://patchwork.freedesktop.org/series/34370/ State : failure == Summary == Series 34370v1 drm/i915/pmu: Aggregate all RC6 states into one counter

Re: [Intel-gfx] [PATCH 8/8] drm/i915: prefer resource_size_t for everything stolen

On 24 November 2017 at 16:54, Chris Wilson wrote: > Quoting Matthew Auld (2017-11-24 16:42:57) >> Keeps things consistent now that we make use of struct resource. This >> should keep us covered in case we ever get huge amounts of stolen >> memory. >> >> v2: bunch of

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Expose the busyspin durations for i915_wait_request

== Series Details == Series: drm/i915: Expose the busyspin durations for i915_wait_request URL : https://patchwork.freedesktop.org/series/34364/ State : success == Summary == Test gem_busy: Subgroup close-race: fail -> PASS (shard-snb) fdo#103829 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Use consistent name for scratch register count

== Series Details == Series: drm/i915/guc: Use consistent name for scratch register count URL : https://patchwork.freedesktop.org/series/34369/ State : success == Summary == Series 34369v1 drm/i915/guc: Use consistent name for scratch register count

[Intel-gfx] [PATCH i-g-t] intel/pmu: Catch-up with i915 RC6 aggregation changes

From: Tvrtko Ursulin Since i915 PMU is removing separate RC6 counters and now aggregates all under a single one, catch up the test and intel-gpu-overlay with those changes. Signed-off-by: Tvrtko Ursulin --- lib/igt_perf.h | 4 +---

[Intel-gfx] [PATCH] drm/i915/pmu: Aggregate all RC6 states into one counter

From: Tvrtko Ursulin Chris has discovered that RC6, RC6p and RC6pp counters are mutually exclusive, and even that on some SNB SKUs you get RC6p increasing, and on the others RC6. Furthermore RC6p and RC6pp were only present starting from GEN6 until, GEN7, not including

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/guc: Advance over port[0] if set and not preempting

Quoting Patchwork (2017-11-24 17:02:54) > == Series Details == > > Series: series starting with [1/2] drm/i915/guc: Advance over port[0] if set > and not preempting > URL : https://patchwork.freedesktop.org/series/34361/ > State : success > > == Summary == > > Test kms_frontbuffer_tracking:

Re: [Intel-gfx] [PATCH 2/8] x86/early-quirks: replace the magical increment start values

On Fri, Nov 24, 2017 at 04:42:51PM +, Matthew Auld wrote: > Replace the magical +2, +9 etc. with +MB, which is far easier to read. > > Suggested-by: Ville Syrjälä > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen

[Intel-gfx] ✗ Fi.CI.IGT: warning for lib/igt_core: Move write_stderr out of LIBUNWIND ifdef

== Series Details == Series: lib/igt_core: Move write_stderr out of LIBUNWIND ifdef URL : https://patchwork.freedesktop.org/series/34349/ State : warning == Summary == Test kms_flip: Subgroup wf_vblank-vs-modeset-interruptible: pass -> SKIP (shard-hsw)

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Reject odd pipe source width with double wide/dual link

On Thu, Nov 23, 2017 at 09:04:48PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay > we must not adjust pipe_src_w to accommodate double wide/dual link. > Instead just reject the mode

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/guc: Advance over port[0] if set and not preempting

== Series Details == Series: series starting with [1/2] drm/i915/guc: Advance over port[0] if set and not preempting URL : https://patchwork.freedesktop.org/series/34361/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render:

[Intel-gfx] [PATCH] drm/i915/guc: Use consistent name for scratch register count

We should be consistent on naming of similar definitions. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Sagar Arun Kamble ---

[Intel-gfx] ✓ Fi.CI.BAT: success for make stolen resource centric (rev2)

== Series Details == Series: make stolen resource centric (rev2) URL : https://patchwork.freedesktop.org/series/34256/ State : success == Summary == Series 34256v2 make stolen resource centric https://patchwork.freedesktop.org/api/1.0/series/34256/revisions/2/mbox/ fi-bdw-5557u total:289

Re: [Intel-gfx] [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Move the plane clip rectangle handling into > drm_atomic_helper_check_plane_state(). Drivers no longer > have to worry about such mundane details. > > Cc: Laurent Pinchart

Re: [Intel-gfx] [PATCH] drm/i915: Disable THP until we have a read BW W/A

On 24 November 2017 at 11:27, Joonas Lahtinen wrote: > We seem to be missing some W/A for 2M pages and are getting > a hit on raw read bandwidths (even 30%) even though the write > bandwidths improve (even 10%). > > For now, disable THP, which is our only

Re: [Intel-gfx] [PATCH] drm/i915: Expose the busyspin durations for i915_wait_request

Quoting Tvrtko Ursulin (2017-11-24 16:44:21) > > On 24/11/2017 14:54, Chris Wilson wrote: > > An interesting discussion regarding "hybrid interrupt polling" for NVMe > > came to the conclusion that the ideal busyspin before sleeping was half > > of the expected request latency (and better if it

Re: [Intel-gfx] [PATCH 8/8] drm/i915: prefer resource_size_t for everything stolen

Quoting Matthew Auld (2017-11-24 16:42:57) > Keeps things consistent now that we make use of struct resource. This > should keep us covered in case we ever get huge amounts of stolen > memory. > > v2: bunch of missing conversions (Chris) > > Signed-off-by: Matthew Auld >

Re: [Intel-gfx] [PATCH] drm/i915: Expose the busyspin durations for i915_wait_request

On 24/11/2017 14:54, Chris Wilson wrote: An interesting discussion regarding "hybrid interrupt polling" for NVMe came to the conclusion that the ideal busyspin before sleeping was half of the expected request latency (and better if it was already halfway through that request). This suggested

[Intel-gfx] [PATCH 6/8] drm/i915: make reserved struct resource centric

v2: s/<= end + 1/< end/ (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.h| 4

[Intel-gfx] [PATCH 2/8] x86/early-quirks: replace the magical increment start values

Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris

[Intel-gfx] [PATCH 8/8] drm/i915: prefer resource_size_t for everything stolen

Keeps things consistent now that we make use of struct resource. This should keep us covered in case we ever get huge amounts of stolen memory. v2: bunch of missing conversions (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc:

[Intel-gfx] [PATCH 5/8] drm/i915: make dsm struct resource centric

v2: check range_overflow when writing to 32b registers (Chris) pepper in some comments (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni ---

[Intel-gfx] [PATCH 3/8] drm/i915: nuke the duplicated stolen discovery

We duplicate the stolen discovery code in early-quirks and in i915, however now the stolen region is exported as a resource from early-quirks we can nuke the duplication. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [PATCH 1/8] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

From: Joonas Lahtinen In preparation for upcoming SKUs, allow more freedom in placement of the Intel graphics stolen memory by BIOS to full 64bit range. v2: export the stolen region as a resource fix u16 << 16 (Chris) Signed-off-by: Joonas Lahtinen

[Intel-gfx] [PATCH 7/8] drm/i915: make mappable struct resource centric

Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni --- drivers/gpu/drm/i915/gvt/gvt.h| 2 +- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH 4/8] drm/i915: s/mappable_end/mappable_size/

In a later patch we introduce 'struct resource mappable', which means we will have both mappable.end and mappable_end, both meaning different things. Therefore to avoid any confusion prefer mappable_size for mappable_end, since it is effectively the size of the resource. Signed-off-by: Matthew

[Intel-gfx] [PATCH 0/8] make stolen resource centric

Continuation of Paulo' stolen series[1], addressing the feedback from Joonas and Chris. [1] https://patchwork.freedesktop.org/series/30923/ Joonas Lahtinen (1): x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit Matthew Auld (7): x86/early-quirks: replace the

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Tidy ELSP port assignment

== Series Details == Series: drm/i915/guc: Tidy ELSP port assignment URL : https://patchwork.freedesktop.org/series/34358/ State : success == Summary == Test kms_flip: Subgroup modeset-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#103060 Test

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [CI,1/3] drm/i915/guc: Tidy ELSP port assignment

== Series Details == Series: series starting with [CI,1/3] drm/i915/guc: Tidy ELSP port assignment URL : https://patchwork.freedesktop.org/series/34360/ State : warning == Summary == Test gem_busy: Subgroup close-race: pass -> FAIL (shard-snb) fdo#103829

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Pass the correct msgs to gmbus_is_index_read()

On Fri, Nov 24, 2017 at 02:55:28PM +0200, Ville Syrjälä wrote: > On Thu, Nov 23, 2017 at 08:50:41PM +, Chris Wilson wrote: > > Quoting Ville Syrjala (2017-11-23 19:41:55) > > > From: Ville Syrjälä > > > > > > We're supposed to examine msgs[i] and msgs[i+1] to

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] igt: Remove Android support

== Series Details == Series: series starting with [1/2] igt: Remove Android support URL : https://patchwork.freedesktop.org/series/34365/ State : success == Summary == IGT patchset tested on top of latest successful build c6577473df7117b7a6e030605df1e28cd0e55708 lib/igt_core: Move

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

On Fri, Nov 24, 2017 at 04:35:10PM +0100, Maarten Lankhorst wrote: > Op 24-11-17 om 16:03 schreef Daniel Vetter: > > On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote: > >> This was implemented correctly only on the atomic ioctl before, but > >> it should really be working on all 3

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

Op 24-11-17 om 16:03 schreef Daniel Vetter: > On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote: >> This was implemented correctly only on the atomic ioctl before, but >> it should really be working on all 3 ioctl's involved, so ensure we >> always set crtc_id correctly with a

Re: [Intel-gfx] [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

On Fri, Nov 24, 2017 at 04:08:28PM +0200, Ville Syrjälä wrote: > On Fri, Nov 24, 2017 at 11:59:45AM +, Liviu Dudau wrote: > > On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > Hi Ville, > > > > > > > > Move the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Expose the busyspin durations for i915_wait_request

== Series Details == Series: drm/i915: Expose the busyspin durations for i915_wait_request URL : https://patchwork.freedesktop.org/series/34364/ State : success == Summary == Series 34364v1 drm/i915: Expose the busyspin durations for i915_wait_request

[Intel-gfx] [PATCH i-g-t 2/2] Revert "lib/igt_aux: Make procps optional"

This reverts commit d7d3f4e87b827152f00bdf89a67871736672b492 and gets rid of the config option from the meson.build. It was needed only for the Android support. Signed-off-by: Arkadiusz Hiler --- configure.ac | 6 +- lib/igt_aux.c | 35

[Intel-gfx] [PATCH i-g-t 1/2] igt: Remove Android support

This patch gets rid of the Android support, deleting all the hacks and moving code around to the places it belongs. Android build is not really maintained properly and rots rather fast. With recent push for Meson here and Android going for Soong it will only accelerate. It's a good time to drop

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Advance over port[0] if set and not preempting

On Fri, Nov 24, 2017 at 01:37:44PM +, Chris Wilson wrote: > Our execlist emulation is intended to only use a maximum of 2 ports per > engine, so as to not overflow the wq. (By knowing the limits, we can > avoid having to handle the wq exhaustion.) However, upon adding > preemption, we lost the

Re: [Intel-gfx] [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer

On Thu, Nov 23, 2017 at 02:13:08PM +0200, Jani Nikula wrote: > I'm juggling too many things, and drm-misc maintenance is one that I > keep dropping on the floor. Admit reality and remove myself as > maintainer. This still leaves us with a nice team of three who are > actually doing the drm-misc

Re: [Intel-gfx] [PATCH] drm/i915: Disable THP until we have a read BW W/A

Quoting Chris Wilson (2017-11-24 12:12:33) > Quoting Joonas Lahtinen (2017-11-24 11:27:50) > > We seem to be missing some W/A for 2M pages and are getting > > a hit on raw read bandwidths (even 30%) even though the write > > bandwidths improve (even 10%). > > > > For now, disable THP, which is

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote: > This was implemented correctly only on the atomic ioctl before, but > it should really be working on all 3 ioctl's involved, so ensure we > always set crtc_id correctly with a testcase. > > Signed-off-by: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Disable THP until we have a read BW W/A

== Series Details == Series: drm/i915: Disable THP until we have a read BW W/A URL : https://patchwork.freedesktop.org/series/34355/ State : warning == Summary == Warning: bzip CI_DRM_3381/shard-glkb6/results8.json.bz2 wasn't in correct JSON format Test perf: Subgroup polling:

[Intel-gfx] [PATCH] drm/i915: Expose the busyspin durations for i915_wait_request

An interesting discussion regarding "hybrid interrupt polling" for NVMe came to the conclusion that the ideal busyspin before sleeping was half of the expected request latency (and better if it was already halfway through that request). This suggested that we too should look again at our tradeoff

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags

== Series Details == Series: series starting with [1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags URL : https://patchwork.freedesktop.org/series/34354/ State : success == Summary == Warning: bzip CI_DRM_3381/shard-glkb6/results8.json.bz2 wasn't in correct JSON format Test

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/igt_core: Move write_stderr out of LIBUNWIND ifdef

== Series Details == Series: lib/igt_core: Move write_stderr out of LIBUNWIND ifdef URL : https://patchwork.freedesktop.org/series/34349/ State : success == Summary == IGT patchset tested on top of latest successful build 2a1c1c099113022f091f9e9585be88c6c9cefec5 igt/perf_pmu: Recalibrate

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Rename i915_guc_reg.h to intel_guc_reg.h (rev2)

== Series Details == Series: drm/i915/guc: Rename i915_guc_reg.h to intel_guc_reg.h (rev2) URL : https://patchwork.freedesktop.org/series/34319/ State : success == Summary == Warning: bzip CI_DRM_3381/shard-glkb6/results8.json.bz2 wasn't in correct JSON format Test kms_flip: Subgroup

Re: [Intel-gfx] [PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle

On Fri, Nov 24, 2017 at 03:32:22PM +0100, Philipp Zabel wrote: > On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > > > No functional changes as the code

Re: [Intel-gfx] [PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle

On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > No functional changes as the code already uses crtc_state->mode > to populate the clip, which is also what

Re: [Intel-gfx] [PATCH 06/15] drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle

On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > Note that this replaces crtc_state->adjusted_mode usage with > crtc_state->mode. The latter is the correct

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/guc: Advance over port[0] if set and not preempting

== Series Details == Series: series starting with [1/2] drm/i915/guc: Advance over port[0] if set and not preempting URL : https://patchwork.freedesktop.org/series/34361/ State : success == Summary == Series 34361v1 series starting with [1/2] drm/i915/guc: Advance over port[0] if set and

Re: [Intel-gfx] [PATCH v3] drm/i915: Use exponential backoff for wait_for()

Quoting Michał Winiarski (2017-11-24 12:37:56) > Since we see the effects for GuC preeption, let's gather some evidence. > > (SKL) > intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption' > > drm-tip: > usecs : count distribution > 0 -> 1

Re: [Intel-gfx] [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

On Fri, Nov 24, 2017 at 11:59:45AM +, Liviu Dudau wrote: > On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > Hi Ville, > > > > > Move the plane clip rectangle handling into > > drm_atomic_helper_check_plane_state().

Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Friday, November 24, 2017 3:50 PM > To: Rantala, Valtteri > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Apply >

Re: [Intel-gfx] [PATCH] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

On Fri, Nov 24, 2017 at 09:30:17AM +0200, Joonas Lahtinen wrote: > @@ -426,14 +426,14 @@ static size_t __init chv_stolen_size(int num, int slot, > int func) >* 0x17 to 0x1d: 4MB increments start at 36MB >*/ > if (gms < 0x11) > - return (size_t)gms * MB(32); > +

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Advance over port[0] if set and not preempting

Chris Wilson writes: > Quoting Chris Wilson (2017-11-24 13:37:44) >> Our execlist emulation is intended to only use a maximum of 2 ports per >> engine, so as to not overflow the wq. (By knowing the limits, we can >> avoid having to handle the wq exhaustion.) However,

Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too

On Fri, Nov 24, 2017 at 10:37:12AM +0200, Valtteri Rantala wrote: > Testing the texture read performance shows that the same tuning for > the SQ credits is needed on GLK as on BXT/APL. This has been also > confirmed by Altug from the HW team. > > V2: Rebase > > Signed-off-by: Valtteri Rantala

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Advance over port[0] if set and not preempting

Chris Wilson writes: > Our execlist emulation is intended to only use a maximum of 2 ports per > engine, so as to not overflow the wq. (By knowing the limits, we can > avoid having to handle the wq exhaustion.) However, upon adding > preemption, we lost the skip over

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Advance over port[0] if set and not preempting

Quoting Chris Wilson (2017-11-24 13:37:44) > Our execlist emulation is intended to only use a maximum of 2 ports per > engine, so as to not overflow the wq. (By knowing the limits, we can > avoid having to handle the wq exhaustion.) However, upon adding > preemption, we lost the skip over the

Re: [Intel-gfx] [PATCH v2] drm/i915: Enable render context support for Ironlake (gen5)

On Thu, Nov 23, 2017 at 08:47:45PM +, Chris Wilson wrote: > Ironlake does support being able to saving and reloading context specific > registers between contexts, providing isolation of the basic GPU state > (as programmable by userspace). This allows userspace to assume that the > GPU

Re: [Intel-gfx] [PATCH 12/15] drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle

On Thu, Nov 23, 2017 at 09:04:59PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > No functional changes as the code already uses crtc_state->mode > to populate the clip, which is also

Re: [Intel-gfx] [PATCH 00/15] drm: More plane clipping polish

On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > This series first unifies all users of drm_atomic_helper_check_plane_state() > to populate the clip rectangle with drm_mode_get_hv_timing(), and once > everything is unified

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Advance over port[0] if set and not preempting

Our execlist emulation is intended to only use a maximum of 2 ports per engine, so as to not overflow the wq. (By knowing the limits, we can avoid having to handle the wq exhaustion.) However, upon adding preemption, we lost the skip over the first port if set for the non-preemption path. Restore

[Intel-gfx] [PATCH 2/2] HAX Enable GuC Submission for CI

From: Michał Winiarski Also: Revert "drm/i915/guc: Assert that we switch between known ggtt->invalidate functions" This reverts commit 04f7b24eccdfae680a36e9825fe0d61dcd5ed528. --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++-- drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/guc: Tidy ELSP port assignment

== Series Details == Series: series starting with [CI,1/3] drm/i915/guc: Tidy ELSP port assignment URL : https://patchwork.freedesktop.org/series/34360/ State : success == Summary == Series 34360v1 series starting with [CI,1/3] drm/i915/guc: Tidy ELSP port assignment

Re: [Intel-gfx] [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

On Fri, Nov 24, 2017 at 02:26:09PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/17/2017 6:19 PM, Ville Syrjälä wrote: > > On Fri, Nov 17, 2017 at 05:50:11PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 11/17/2017 5:05 PM, Ville Syrjälä

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Stop averaging with the previous sample

On 24/11/2017 10:38, Patchwork wrote: == Series Details == Series: drm/i915/pmu: Stop averaging with the previous sample URL : https://patchwork.freedesktop.org/series/34346/ State : success == Summary == Series 34346v1 drm/i915/pmu: Stop averaging with the previous sample

Re: [Intel-gfx] [PATCH] drm/i915/guc: Tidy ELSP port assignment

Quoting Chris Wilson (2017-11-24 12:29:16) > Since we know that the port is empty, we do not need to extract the > count from the old request it and copy it over to the new request, or > attempt to unref the NULL old request pointer. > > Signed-off-by: Chris Wilson >

  1   2   >