Re: [Intel-gfx] [PATCH] drm/i915: Remove pre-production pooled-EU w/a for Broxton

On Thu, 16 Nov 2017, Rodrigo Vivi wrote: > On Thu, Nov 16, 2017 at 09:22:23AM +, Jani Nikula wrote: >> On Wed, 15 Nov 2017, Chris Wilson wrote: >> > Quoting David Weinehall (2017-11-15 18:01:41) >> >> On Tue, Nov 14, 2017 at 01:51:16PM +,

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Impletments dynamic WOPCM partitioning.

On 11/17/2017 3:17 AM, Michal Wajdeczko wrote: On Thu, 16 Nov 2017 08:34:01 +0100, Sagar Arun Kamble wrote: Typo in the subject. GLK showing failure to load GuC with this approach on CI. On 11/15/2017 10:47 PM, Jackie Li wrote: Static WOPCM partitioning will

Re: [Intel-gfx] [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

Regards Shashank On 11/16/2017 9:56 PM, Ville Syrjälä wrote: On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä If the user mode would specify an aspect ratio

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

Regards Shashank On 11/16/2017 9:53 PM, Ville Syrjälä wrote: On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio

Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

Regards Shashank On 11/16/2017 9:51 PM, Ville Syrjälä wrote: On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä Appedix F of HDMI 2.0 says that some HDMI sink

Re: [Intel-gfx] [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

Regards Shashank On 11/16/2017 9:46 PM, Ville Syrjälä wrote: On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote: Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä HDMI 2.0 Appendix F suggest that we should

[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

== Series Details == Series: Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk" URL : https://patchwork.freedesktop.org/series/33969/ State : success == Summary == Test drv_selftest: Subgroup mock_sanitycheck: dmesg-warn -> PASS (shard-hsw) fdo#103719

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

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, > > which includes many improvements as noted below. > > > > thanks > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

== Series Details == Series: Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk" URL : https://patchwork.freedesktop.org/series/33969/ State : success == Summary == Series 33969v1 Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

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

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 some sizes and images, but doesn't break anything." Cc: Rodrigo Vivi

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

On Thu, Nov 02, 2017 at 06:38:32PM +0200, Ville Syrjala wrote: > 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

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

On Fri, Oct 13, 2017 at 04:58:38PM +0300, Ville Syrjala wrote: > 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. > > Cc: Daniel Vetter > Suggested-by:

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

Quoting Chris Wilson (2017-11-16 22:25:45) > Quoting Chris Wilson (2017-11-16 22:11:30) > > If we are about to do another context-switch in the near future skip > > doing performing a lite-restore now. (Forcing a lite-restore just before > > a context-switch effectively doubles the cost of that

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

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. > > enum i9xx_plane_id is a global identifier, whereas enum plane_id is >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

== Series Details == Series: drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion URL : https://patchwork.freedesktop.org/series/33965/ State : failure == Summary == Series 33965v1 drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v5,1/2] drm/i915/selftests: Add a GuC doorbells selftest

== Series Details == Series: series starting with [v5,1/2] drm/i915/selftests: Add a GuC doorbells selftest URL : https://patchwork.freedesktop.org/series/33964/ State : warning == Summary == Series 33964v1 series starting with [v5,1/2] drm/i915/selftests: Add a GuC doorbells selftest

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

Quoting Chris Wilson (2017-11-16 22:11:30) > If we are about to do another context-switch in the near future skip > doing performing a lite-restore now. (Forcing a lite-restore just before > a context-switch effectively doubles the cost of that context-switch, so > long as we can handle the

[Intel-gfx] [PATCH] drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

If we are about to do another context-switch in the near future skip doing performing a lite-restore now. (Forcing a lite-restore just before a context-switch effectively doubles the cost of that context-switch, so long as we can handle the interrupt and resubmit before the GPU powers down, which

[Intel-gfx] [PATCH v5 2/2] HAX enable GuC submission for CI

From: Michal Wajdeczko Also revert ("drm/i915/guc: Assert that we switch between known ggtt->invalidate functions") Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++-- drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] [PATCH v5 1/2] drm/i915/selftests: Add a GuC doorbells selftest

The first test aims to check guc_init_doorbell_hw, changing the existing guc clients and doorbells state before calling it. The second test tries to create as many clients as it is currently possible (currently limited to max number of doorbells) and exercise the doorbell alloc/dealloc code.

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915/selftests: Add a GuC doorbells selftest

On 11/16/2017 7:10 AM, Chris Wilson wrote: Quoting Michel Thierry (2017-11-15 18:30:27) The first test aims to check guc_init_doorbell_hw, changing the existing guc clients and doorbells state before calling it. The second test tries to create as many clients as it is currently possible

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Impletments dynamic WOPCM partitioning.

On Thu, 16 Nov 2017 08:34:01 +0100, Sagar Arun Kamble wrote: Typo in the subject. GLK showing failure to load GuC with this approach on CI. On 11/15/2017 10:47 PM, Jackie Li wrote: Static WOPCM partitioning will lead to GuC loading failure if the GuC/HuC firmware

Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm

Quoting Paulo Zanoni (2017-11-16 20:45:26) > Em Qui, 2017-11-16 às 20:24 +0200, David Weinehall escreveu: > > On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote: > > > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote: > > > > Now that we have CI, and that pm_rpm fully

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

Quoting Ville Syrjala (2017-11-16 19:14:47) > From: Ville Syrjälä > > The current code is trying to be lazy with fences on scanout buffers. > That looks broken for several reasons: > * gen2/3 always need a fence for tiled scanout Which it already gets. All

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Add a FIXME about FBC vs. fence. 90/270 degree rotation

Quoting Ville Syrjala (2017-11-16 19:14:50) > From: Ville Syrjälä > > Currently we're pinning the fence for the rotated GTT view. That doesn't > acually make any sense since the fence is used only for the FBC GTT > tracking. For that we would want the fence for the

Re: [Intel-gfx] [PATCH] drm/i915: Remove pre-production pooled-EU w/a for Broxton

On Thu, Nov 16, 2017 at 09:22:23AM +, Jani Nikula wrote: > On Wed, 15 Nov 2017, Chris Wilson wrote: > > Quoting David Weinehall (2017-11-15 18:01:41) > >> On Tue, Nov 14, 2017 at 01:51:16PM +, Chris Wilson wrote: > >> > WaEnablePooledEuFor2x6 only applies to

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

On Thu, Nov 16, 2017 at 07:14:47PM +, Ville Syrjala wrote: > From: Ville Syrjälä > > The current code is trying to be lazy with fences on scanout buffers. > That looks broken for several reasons: > * gen2/3 always need a fence for tiled scanout > * the unpin

Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm

Em Qui, 2017-11-16 às 20:24 +0200, David Weinehall escreveu: > On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote: > > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote: > > > Now that we have CI, and that pm_rpm fully passes (I guess the > > > audio > > > folks have

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

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 > > wrote: > > > Hi Daniel, > > > > > > In the past couple of months we've been working

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

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, > which includes many improvements as noted below. > > thanks > > -- > The following changes since commit

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with lib/igt_kms: Add igt_display_reset function, v3. (rev3)

== Series Details == Series: series starting with lib/igt_kms: Add igt_display_reset function, v3. (rev3) URL : https://patchwork.freedesktop.org/series/33934/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render:

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes

== Series Details == Series: series starting with [1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes URL : https://patchwork.freedesktop.org/series/33960/ State : failure == Summary == Series 33960v1 series starting with [1/5] drm/i915: Always pin the fence for

[Intel-gfx] [PATCH 2/5] drm/i915: Clean up fbc vs. plane checks

From: Ville Syrjälä Let's record the information whether a plane can do fbc or not under struct inte_plane. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 36

[Intel-gfx] [PATCH 3/5] drm/i915: Require fence only for FBC capable planes

From: Ville Syrjälä Since only a subset of primary planes are FBC capable there's no need to waste fences on all of them. So let's skip the fence if the plane isn't even fbc capable. In the future we might extend this to skip the fence even for FBC capable planes

[Intel-gfx] [PATCH 4/5] drm/i915: Add a FIXME about FBC vs. fence. 90/270 degree rotation

From: Ville Syrjälä Currently we're pinning the fence for the rotated GTT view. That doesn't acually make any sense since the fence is used only for the FBC GTT tracking. For that we would want the fence for the normal GTT view instead of the rotated view. Too lazy

[Intel-gfx] [PATCH 5/5] drm/i915: Extract intel_plane_{pin, unpin}_fb()

From: Ville Syrjälä We've replicated the fb pin/unpin code in a few places. Pull it into convenint helpers. This results in a slight change in behaviour on account of the cursor path now dropping struct_mutex and reacquiring it later. Signed-off-by: Ville Syrjälä

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

From: Ville Syrjälä The current code is trying to be lazy with fences on scanout buffers. That looks broken for several reasons: * gen2/3 always need a fence for tiled scanout * the unpin doesn't know whether we pinned the fence or not so it may unpin something

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with lib/igt_kms: Add igt_display_reset function, v3. (rev3)

== Series Details == Series: series starting with lib/igt_kms: Add igt_display_reset function, v3. (rev3) URL : https://patchwork.freedesktop.org/series/33934/ State : success == Summary == IGT patchset tested on top of latest successful build 936b97165308e179880fc0f218192881953f2544 lib:

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add igt_display_reset function, v3.

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. Changes since v1: - Merely reset rotation to HW value. Changes since v2: - Compile. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm

On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote: > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote: > > Now that we have CI, and that pm_rpm fully passes (I guess the audio > > folks have implemented proper runtime pm for snd-hda, hooray, pls > > confirm) it's time to

Re: [Intel-gfx] [PATCH 0/7] WRPLL fixes for HDMI 2.0 on Cannonlake.

Merged to dinq. Thanks for all reviews and comments. On Tue, Nov 14, 2017 at 07:47:52PM +, Rodrigo Vivi wrote: > With these fixes and clean-ups around wrpll plus > extending HDMI 2.0 from GLK to CNL we could finally > get a functional HDMI 2.0 display with 4k60Hz. > > Thanks, > Rodrigo. >

[Intel-gfx] ✓ Fi.CI.IGT: success for WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4)

== Series Details == Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4) URL : https://patchwork.freedesktop.org/series/33823/ State : success == Summary == Test drv_selftest: Subgroup mock_sanitycheck: pass -> DMESG-WARN (shard-snb) fdo#103717 Test

[Intel-gfx] ✗ Fi.CI.IGT: warning 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 : warning == Summary == Test drv_selftest: Subgroup mock_sanitycheck: pass -> DMESG-WARN (shard-snb) fdo#103717 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4)

== Series Details == Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4) URL : https://patchwork.freedesktop.org/series/33823/ State : success == Summary == Series 33823v4 WRPLL fixes for HDMI 2.0 on Cannonlake. https://patchwork.freedesktop.org/api/1.0/series/33823/revisions/4/mbox/

Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/13/2017 10:34 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from > > 3D to 2D mode in

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Update names of submission related static functions

On Thu, 16 Nov 2017 10:53:51 +0100, Sagar Arun Kamble wrote: i915_guc_submit, i915_guc_dequeue, i915_guc_submission_park and i915_guc_submission_upark are functions internal to GuC submission hence remove "i915_" prefix. Suggested-by: Michal Wajdeczko

Re: [Intel-gfx] [PATCH] drm/i915: Don't sanitize frame start delay if the pipe is off

On Wed, Nov 15, 2017 at 08:17:21PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2017-11-15 20:04:42) > > From: Ville Syrjälä > > > > Avoid touching PIPECONF in intel_sanitize_crtc() unless the pipe is > > actually on. Should cure some unclaimed register

[Intel-gfx] [PATCH] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

Starting on GLK we support HDMI 2.0. So this patch only extend the work Shashank has made to GLK to CNL. v2: The version that compiles :/ v3: Invert order to newer || older platforms check. (Ville). Cc: Ville Syrjälä Cc: Paulo Zanoni Cc:

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

On Wed, Nov 15, 2017 at 04:44:54PM +, alexander.le...@verizon.com wrote: > On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote: > >On Wed, Nov 15, 2017 at 02:45:43AM +, alexander.le...@verizon.com wrote: > >> From: Ville Syrjälä > >> > >> [

Re: [Intel-gfx] [PATCH v2 02/10] drm/uapi: Validate the mode flags/type

On Wed, Nov 15, 2017 at 06:02:59PM +, Jose Abreu wrote: > Hi Ville, > > On 15-11-2017 15:49, Ville Syrjala wrote: > > > > +#define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \ > > +DRM_MODE_FLAG_NHSYNC | \ > > +

Re: [Intel-gfx] [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/13/2017 10:34 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > If the user mode would specify an aspect ratio other than 4:3 or 16:9 > > we now silently

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

On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/13/2017 10:34 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") > > cause us to not send

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with lib/igt_kms: Add igt_display_reset function, v2. (rev2)

== Series Details == Series: series starting with lib/igt_kms: Add igt_display_reset function, v2. (rev2) URL : https://patchwork.freedesktop.org/series/33934/ State : failure == Summary == IGT patchset build failed on latest successful build 936b97165308e179880fc0f218192881953f2544 lib:

[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 01/10] video/hdmi: Allow "empty" HDMI infoframes

On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 11/13/2017 10:34 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe > > when switching

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

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 not applying > some workarounds on resume. This, for example, cause some

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add igt_display_reset function, v2.

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. Changes since v1: - Merely reset rotation to HW value. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Expose more GPU properties through sysfs

== Series Details == Series: drm/i915: Expose more GPU properties through sysfs URL : https://patchwork.freedesktop.org/series/33950/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h

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

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 not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB

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

This enables userspace to discover the engines available on the GPU. Here is the layout : /sys/devices/pci:00/:00:02.0/drm/card0/engines ├── bcs0 │   ├── class │   └── instance ├── rcs0 │   ├── class │   └── instance ├── vcs0 │   ├── class │   ├── hevc │   └── instance ├── vcs1 │   ├──

[Intel-gfx] [PATCH 3/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 0/4] drm/i915: Expose more GPU properties through sysfs

Hi all, Based on feedback on previous series by Tvrtko & myself, here is a series that exposes EU topology & engines availability through sysfs. Cheers, Lionel Landwerlin (4): drm/i915: store all subslice masks drm/i915/debugfs: reuse max slice/subslices already stored in sseu drm/i915:

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: exercise_ggtt may have nothing to do

Quoting Chris Wilson (2017-11-15 15:25:58) > When operating on the live_ggtt we have to find a usuable hole for our > test. It is possible for there to be no hole we can use, so initialise > the err to 0 for the early exit. > > Signed-off-by: Chris Wilson > --- >

Re: [Intel-gfx] [PATCH] drm/i915: Don't sanitize frame start delay if the pipe is off

On Wed, Nov 15, 2017 at 09:13:28PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2017-11-15 20:04:42) > > From: Ville Syrjälä > > > > Avoid touching PIPECONF in intel_sanitize_crtc() unless the pipe is > > actually on. Should cure some unclaimed register

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Don't sanitize frame start delay if the pipe is off

On Wed, Nov 15, 2017 at 09:17:01PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Don't sanitize frame start delay if the pipe is off > URL : https://patchwork.freedesktop.org/series/33901/ > State : success > > == Summary == > > Test kms_busy: > Subgroup

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915/selftests: Add a GuC doorbells selftest

Quoting Michel Thierry (2017-11-15 18:30:27) > The first test aims to check guc_init_doorbell_hw, changing the existing > guc clients and doorbells state before calling it. > > The second test tries to create as many clients as it is currently possible > (currently limited to max number of

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for GuC submission functions/struct name/prototype update (rev3)

Quoting Patchwork (2017-11-16 14:56:50) > == Series Details == > > Series: GuC submission functions/struct name/prototype update (rev3) > URL : https://patchwork.freedesktop.org/series/33679/ > State : warning > > == Summary == > > Test kms_setmode: > Subgroup basic: >

Re: [Intel-gfx] [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be

[Intel-gfx] ✗ Fi.CI.IGT: warning for GuC submission functions/struct name/prototype update (rev3)

== Series Details == Series: GuC submission functions/struct name/prototype update (rev3) URL : https://patchwork.freedesktop.org/series/33679/ State : warning == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test kms_flip:

Re: [Intel-gfx] [PATCH igt v2] tools/error_decode: Print ASCII user buffers

On 16/11/2017 14:35, Chris Wilson wrote: Look at the first 16 characters of the user buffer and if they are all printable, assume that user buffer contains ASCII data (e.g. a debug log) that we want to simply print out. Otherwise, we treat it as a binary data and hexdump as before. Tvrtko: you

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

Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915: Update execlists tasklet naming

Quoting Sagar Arun Kamble (2017-11-16 13:32:37) > intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related > tasklet functions. Name them with "submission_tasklet" suffix and > remove intel/i915 prefix as they are static. Also rename irq_tasklet > as just tasklet for clarity. > >

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Automatic i915_switch_context for legacy

Quoting Mika Kuoppala (2017-11-16 14:00:13) > Chris Wilson writes: > > > 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()

Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested

Re: [Intel-gfx] [PATCH igt] lib: Dump /sys/kernel/debug/suspend_stats after suspend failure

Quoting Arkadiusz Hiler (2017-11-16 14:31:03) > On Tue, Nov 14, 2017 at 01:19:01PM +, Chris Wilson wrote: > > I noticed that dpm was storing some information about which phase of > > suspend failed inside suspend_stats. That will be useful to help debug > > such failures, so automatically dump

Re: [Intel-gfx] [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to

[Intel-gfx] [PATCH igt v2] tools/error_decode: Print ASCII user buffers

Look at the first 16 characters of the user buffer and if they are all printable, assume that user buffer contains ASCII data (e.g. a debug log) that we want to simply print out. Otherwise, we treat it as a binary data and hexdump as before. Tvrtko: you know you could just write this as a printf

Re: [Intel-gfx] [PATCH igt] lib: Dump /sys/kernel/debug/suspend_stats after suspend failure

On Tue, Nov 14, 2017 at 01:19:01PM +, Chris Wilson wrote: > I noticed that dpm was storing some information about which phase of > suspend failed inside suspend_stats. That will be useful to help debug > such failures, so automatically dump it after suspend fails. > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915: Clear breadcrumb node when cancelling signaling

Quoting Joonas Lahtinen (2017-11-16 11:08:18) > On Wed, 2017-11-15 at 12:14 +, Chris Wilson wrote: > > When we call intel_engine_cancel_signaling() to stop reporting whether > > or not a request is completed via an asynchronous signal, we remove that > > request from the breadcrumb wait queue.

Re: [Intel-gfx] [PATCH v6] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

Quoting Tvrtko Ursulin (2017-11-16 14:00:50) > > On 16/11/2017 10:50, Chris Wilson wrote: > > We check whether the multiplies will overflow prior to calling > > kmalloc_array so that we can respond with -EINVAL for the invalid user > > arguments rather than treating it as an -ENOMEM that would

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915: Update execlists tasklet naming

On Thu, 16 Nov 2017 14:32:37 +0100, Sagar Arun Kamble wrote: intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related tasklet functions. Name them with "submission_tasklet" suffix and remove intel/i915 prefix as they are static. Also rename

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC submission functions/struct name/prototype update (rev3)

== Series Details == Series: GuC submission functions/struct name/prototype update (rev3) URL : https://patchwork.freedesktop.org/series/33679/ State : success == Summary == Series 33679v3 GuC submission functions/struct name/prototype update

Re: [Intel-gfx] [PATCH v6] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

On 16/11/2017 10:50, Chris Wilson wrote: We check whether the multiplies will overflow prior to calling kmalloc_array so that we can respond with -EINVAL for the invalid user arguments rather than treating it as an -ENOMEM that would otherwise occur. However, as Dan Carpenter pointed out, we

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Automatic i915_switch_context for legacy

Chris Wilson writes: > 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

Re: [Intel-gfx] [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples

On 11/15/2017 6:01 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-11-15 12:13:54) From: Sourab Gupta Currently, we have the ability to only forward the GPU timestamps in the samples (which are generated via OA reports). This limits the ability to correlate

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Make request's wait-for-space explicit

Chris Wilson writes: > Quoting Mika Kuoppala (2017-11-15 13:51:13) >> Chris Wilson writes: >> >> > At the start of building a request, we would wait for roughly enough >> > space to fit the average request (to reduce the likelihood of having

Re: [Intel-gfx] [PATCH igt 1/2] lib/gt: Mark up engine classes

On 15/11/2017 13:32, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-11-15 13:26:09) On 14/11/2017 13:19, Chris Wilson wrote: We introduce the concept of classes that each engine may belong to. There may be more than one engine available in each class, but each engine only belongs to one

Re: [Intel-gfx] [PATCH 2/3] drm/i915/: Initialise trans_min for skl_compute_transition_wm()

On Wed, Nov 15, 2017 at 10:50:35AM +, Chris Wilson wrote: > clang spots > > drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used > uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] > if (INTEL_GEN(dev_priv) >= 10) > > but fortunately

Re: [Intel-gfx] [RFC 2/3] drm/i915/guc: Omit guc_init_doorbell_hw during driver load

On 11/16/2017 12:00 AM, Michel Thierry wrote: During driver load we create the GuC clients and allocate their doorbells just before executing guc_init_doorbell_hw; but since we just created these doorbells, how can they be out of sync? This code has had more than enough refactoring (2 more

Re: [Intel-gfx] [RFC 2/3] drm/i915/guc: Omit guc_init_doorbell_hw during driver load

On 15/11/17 10:30, Michel Thierry wrote: During driver load we create the GuC clients and allocate their doorbells just before executing guc_init_doorbell_hw; but since we just created these doorbells, how can they be out of sync? This code has had more than enough refactoring (2 more still in

Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

On Mon, Nov 13, 2017 at 10:47:44AM -0800, Rodrigo Vivi wrote: > On Sat, Nov 11, 2017 at 09:43:44AM +, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 11/11/2017 3:56 AM, Rodrigo Vivi wrote: > > > Starting on GLK we support HDMI 2.0. So this patch only > > > extend the

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] lib/igt_kms: Add igt_display_reset function.

== Series Details == Series: series starting with [1/4] lib/igt_kms: Add igt_display_reset function. URL : https://patchwork.freedesktop.org/series/33934/ State : failure == Summary == IGT patchset tested on top of latest successful build 88d6550795fad3974d77e4db2f563c5e2e8872e1 Revert

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/kms_cursor_legacy: Rework the 2x tests.

== Series Details == Series: tests/kms_cursor_legacy: Rework the 2x tests. URL : https://patchwork.freedesktop.org/series/33933/ State : warning == Summary == Test kms_chv_cursor_fail: Subgroup pipe-c-128x128-bottom-edge: skip -> PASS (shard-hsw)

[Intel-gfx] [PATCH v3 6/6] HAX enable GuC submission for CI

Also revert ("drm/i915/guc: Assert that we switch between known ggtt->invalidate functions") --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++-- drivers/gpu/drm/i915/i915_params.h | 4 ++-- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

[Intel-gfx] [PATCH v3 5/6] drm/i915/guc: Rename i915_guc_submission.c|h to intel_guc_submission.c|h

With all component structures and functions named appropriately, change the names of GuC submission source files. There were bunch of style issues in guc_submission.c that are highlighted now by checkpatch. Fix those. Update name in Documentation/gpu. (Joonas) v2: Rebase. v3: Rebase.

[Intel-gfx] [PATCH v3 4/6] drm/i915/guc: Rename i915_guc_client struct to intel_guc_client

GuC submission clients are currently being used in kernel only hence update the structure name to intel_guc_client. Signed-off-by: Sagar Arun Kamble Cc: Michal Wajdeczko Cc: Michal Winiarski Cc: Chris Wilson

[Intel-gfx] [PATCH v3 1/6] drm/i915: Update execlists tasklet naming

intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related tasklet functions. Name them with "submission_tasklet" suffix and remove intel/i915 prefix as they are static. Also rename irq_tasklet as just tasklet for clarity. v2: s/_bh/_tasklet (Chris) Suggested-by: Michal Wajdeczko

[Intel-gfx] [PATCH v3 3/6] drm/i915/guc: Update name and prototype of GuC submission interface functions

i915 GuC submission is hardware interface and GuC APIs that are not user facing should be named intel_guc* hence we change GuC submission related functions name prefix to intel_guc. Also changed the parameter to these functions to intel_guc struct. v2: Using local guc variable in

  1   2   >