[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Check for partial PSR dpcd reads (rev2)

== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads (rev2) URL : https://patchwork.freedesktop.org/series/43907/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4255_full -> Patchwork_9144_full = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Check for partial PSR dpcd reads (rev2)

== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads (rev2) URL : https://patchwork.freedesktop.org/series/43907/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4255 -> Patchwork_9144 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH v2] drm/i915/psr: Check for partial PSR dpcd reads

The dpcd read during psr_dpcd_init may not always return the requested number of bytes. No known cases yet, but good to put that check in place. v2: Fix checkpatch warnings. Signed-off-by: Tarun Vyas --- drivers/gpu/drm/i915/intel_psr.c | 8 ++-- 1 file changed, 6 insertions(+), 2

[Intel-gfx] [PATCH i-g-t 0/3] Fix some GCC warnings

During the compilation, some GCC (8.1) warnings are shown. This patchset address some of the warnings problems. Rodrigo Siqueira (3): Avoid truncate string in __igt_lsof_fds Remove extra '\0' in strncpy in igt_save_module_param Move declaration to the top of the code lib/igt_aux.c

[Intel-gfx] [PATCH i-g-t 3/3] Move declaration to the top of the code

This patch fix the following gcc warnings: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] [..] igt_color_encoding.c:45:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] [..] igt_color_encoding.c: In function

[Intel-gfx] [PATCH i-g-t 2/3] Remove extra '\0' in strncpy in igt_save_module_param

This patch fix the following gcc warning: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] strncpy(data->name, name, PARAM_NAME_MAX_SZ); This error happens due to the '\0' character appended by strncpy. Notice that reduces by one in the total of bytes to be

[Intel-gfx] [PATCH i-g-t 1/3] Avoid truncate string in __igt_lsof_fds

Note that 'proc_path' parameter in __igt_lsof_fds receives a string which was initialized with the size of PATH_MAX and the local variable 'path' has the same size, but it also have to append: '/', '\0', and the directory name. This situation caused the warning described below. warning: ‘%s’

[Intel-gfx] [PATCH i-g-t] [RFC] Add support to force specific module load

This patch adds a new option to force the use of a module specified from the command line. The force command expects a module name which will be used on the target test (changing the standard behavior). This feature can be useful for developers that have to create a new module since it is

Re: [Intel-gfx] [PATCH 05/24] drm/i915/icp: Add Interrupt Support

On Thu, May 24, 2018 at 05:43:24PM -0700, Lucas De Marchi wrote: > On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote: > > On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote: > > > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote: > > > > > > > > From: Anusha

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Check for partial PSR dpcd reads

== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads URL : https://patchwork.freedesktop.org/series/43907/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4255_full -> Patchwork_9143_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context

Quoting Lionel Landwerlin (2018-05-29 22:35:08) > On 29/05/18 21:26, Michel Thierry wrote: > > Hi, > > > > On 5/29/2018 12:16 PM, Lionel Landwerlin wrote: > >> We want to be able to modify other context images from the kernel > >> context in a following commit. To be able to do this we need to map

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context

On 29/05/18 21:26, Michel Thierry wrote: Hi, On 5/29/2018 12:16 PM, Lionel Landwerlin wrote: We want to be able to modify other context images from the kernel context in a following commit. To be able to do this we need to map the context image into the kernel context's ppgtt. Signed-off-by:

Re: [Intel-gfx] [PATCH] drm/i915/psr: Set idle frame count based on sink synchronization latency

On Tue, 2018-05-29 at 12:51 -0700, Rodrigo Vivi wrote: > On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote: > > > > DPCD 2009h "Synchronization latency in sink" has bits that tell us > > the > > maximum number of frames sink can take to resynchronize to source > > timing > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Check for partial PSR dpcd reads

== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads URL : https://patchwork.freedesktop.org/series/43907/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4255 -> Patchwork_9143 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: per context slice/subslice powergating (rev7)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4254_full -> Patchwork_9142_full = == Summary - FAILURE == Serious unknown changes

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: Check for partial PSR dpcd reads

== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads URL : https://patchwork.freedesktop.org/series/43907/ State : warning == Summary == $ dim checkpatch origin/drm-tip e77d22f295bc drm/i915/psr: Check for partial PSR dpcd reads -:23: CHECK:PARENTHESIS_ALIGNMENT:

[Intel-gfx] [PATCH] drm/i915/psr: Check for partial PSR dpcd reads

The dpcd read during psr_dpcd_init may not always return the requested number of bytes. No known cases yet, but good to put that check in place. Signed-off-by: Tarun Vyas --- drivers/gpu/drm/i915/intel_psr.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context

Hi, On 5/29/2018 12:16 PM, Lionel Landwerlin wrote: We want to be able to modify other context images from the kernel context in a following commit. To be able to do this we need to map the context image into the kernel context's ppgtt. Signed-off-by: Lionel Landwerlin ---

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

On 25/05/18 08:14, Chris Wilson wrote: We may not idle immediately after a hang, and indeed may send a pulse down the pipeline periodically to become idle. Rather than make a flimsy assumption about how long we need to sleep before the system idles, wait for the system to declare itself idle;

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+

== Series Details == Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+ URL : https://patchwork.freedesktop.org/series/43902/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4254_full -> Patchwork_9141_full = == Summary - WARNING ==

Re: [Intel-gfx] [PATCH] drm/i915/psr: Set idle frame count based on sink synchronization latency

On Tue, May 29, 2018 at 12:51:23PM -0700, Rodrigo Vivi wrote: > On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote: > > DPCD 2009h "Synchronization latency in sink" has bits that tell us the > > maximum number of frames sink can take to resynchronize to source timing > > when

Re: [Intel-gfx] [PATCH] drm/i915/psr: Set idle frame count based on sink synchronization latency

On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote: > DPCD 2009h "Synchronization latency in sink" has bits that tell us the > maximum number of frames sink can take to resynchronize to source timing > when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: per context slice/subslice powergating (rev7)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4254 -> Patchwork_9142 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating (rev7)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating (rev7)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip d23a6b481d4b drm/i915: Program RPCS for Broadwell 6540acb8de8b drm/i915: Record the sseu

[Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context

We want to be able to modify other context images from the kernel context in a following commit. To be able to do this we need to map the context image into the kernel context's ppgtt. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_gem_context.h | 1 +

[Intel-gfx] [PATCH v8 8/8] drm/i915: add a sysfs entry to let users set sseu configs

There are concerns about denial of service around the per context sseu configuration capability. In a previous commit introducing the capability we allowed it only for capable users. This changes adds a new debugfs entry to let any user configure its own context powergating setup. v2: Rename

[Intel-gfx] [PATCH v8 0/8] drm/i915: per context slice/subslice powergating

Hi all, Another iteration that takes into account : - Tvrtko's nits from v7 on patch 8 - Tvrtko's suggestion not to return EPERM when dynamic sseu is disabled through sysfs. Instead store the requested value and apply it when/if dynamic sseu becomes enabled. - A pretty

[Intel-gfx] [PATCH v8 5/8] drm/i915/perf: lock powergating configuration to default when active

If some of the contexts submitting workloads to the GPU have been configured to shutdown slices/subslices, we might loose the NOA configurations written in the NOA muxes. One possible solution to this problem is to reprogram the NOA muxes when we switch to a new context. We initially tried this

[Intel-gfx] [PATCH v8 7/8] drm/i915: Expose RPCS (SSEU) configuration to userspace

From: Chris Wilson We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context image (and currently not accessible via LRI). If the context is adjusted before

[Intel-gfx] [PATCH v8 4/8] drm/i915/perf: reuse intel_lrc ctx regs macro

Abstract the context image access a bit. Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_perf.c | 34 +++- 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

[Intel-gfx] [PATCH v8 2/8] drm/i915: Record the sseu configuration per-context & engine

From: Chris Wilson We want to expose the ability to reconfigure the slices, subslice and eu per context and per engine. To facilitate that, store the current configuration on the context for each engine, which is initially set to the device default upon creation. v2: record sseu configuration

[Intel-gfx] [PATCH v8 1/8] drm/i915: Program RPCS for Broadwell

From: Chris Wilson Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the configuration to userspace and may

[Intel-gfx] [PATCH v8 3/8] drm/i915/perf: simplify configure all context function

We don't need any special treatment on error so just return as soon as possible. Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_perf.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization

On Tue, May 29, 2018 at 5:47 AM, Lionel Landwerlin wrote: > FYI, we're setting this in Mesa : > https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130 > https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67 > I don't think we realized

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+

== Series Details == Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+ URL : https://patchwork.freedesktop.org/series/43902/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4254 -> Patchwork_9141 = == Summary - SUCCESS == No

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable P010, P012 and P016 formats for GLK/CNL

== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9140_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+

== Series Details == Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+ URL : https://patchwork.freedesktop.org/series/43902/ State : warning == Summary == $ dim checkpatch origin/drm-tip ab49b9e98274 drm/i915: Fix sprite destination colorkeying on SKL+

[Intel-gfx] [PATCH xf86-video-intel 8/8] sna/video/sprite: Try disabling plane before giving up on colorkey

From: Ville Syrjälä When we're trying to reinstate the colorkey we might fail on account of the plane still being enable with a configuration that prevent the use of colorkey. This happens easily with NV12 since the plane scaler required by even unscaled NV12 is not compatible with colorkey. To

[Intel-gfx] [PATCH xf86-video-intel 7/8] sna/video/sprite: Make NV12 take the GPU scaling fallback

From: Ville Syrjälä Even unscaled NV12 needs the plane scaler on SKL+, so when unscaled NV12 setplane fails we should still take the GPU scaling fallback path. Signed-off-by: Ville Syrjälä --- src/sna/sna_video_sprite.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff

[Intel-gfx] [PATCH xf86-video-intel 5/8] sna/video/sprite: Query planes for RGB565

From: Ville Syrjälä Not all sprite planes support RGB565. Insrtead of hardcoding which platforms have it let's ask the kernel instead. Signed-off-by: Ville Syrjälä --- src/sna/sna.h | 1 + src/sna/sna_display.c | 76 ++

[Intel-gfx] [PATCH xf86-video-intel 6/8] sna/video/sprite: Add NV12 support

From: Ville Syrjälä Starting from ~KBL planes can do NV12. Let's make use that capability in the sprite Xv adaptor. Signed-off-by: Ville Syrjälä --- src/sna/sna_video_sprite.c | 57 +++--- 1 file changed, 49 insertions(+), 8 deletions(-) diff --git

[Intel-gfx] [PATCH xf86-video-intel 3/8] sna/video: Add XV_COLORSPACE attribute for the textured Xv adaptor

From: Ville Syrjälä Allow the client to select between BT.601 and BT.709 via the XV_COLORSPACE port attribute with the textured Xv adaptor as well. Since the BT.601 coefficients are currently hardcoded in the yuv->rgb shader, let's just add a mostly duplicated shader with hardcoded BT.709

[Intel-gfx] [PATCH xf86-video-intel 4/8] sna/video/sprite: Add sprite planes in order

From: Ville Syrjälä On SKL+ dst color keying only works between the first sprite and the primary. We probably wante the first Xv port to be the first sprite plane so that the user gets working colorkeying for the port that is most likely to be used first. No way to get dst colorkeying with the

[Intel-gfx] [PATCH xf86-video-intel 2/8] Rename current yuv->rgb shader sources to exa_wm_yuv_rgb_bt601

From: Ville Syrjälä Our current yuv->rgb shaders follow the BT.601 conversion formula. Rename the shader sources to indicate that fact. Signed-off-by: Ville Syrjälä --- src/render_program/Makefile.am | 22 +++--- src/render_program/exa_wm_yuv_rgb.g5a

[Intel-gfx] [PATCH xf86-video-intel 1/8] Remove duplicate exa_wm_yuv_rgb.g5a shader source

From: Ville Syrjälä exa_wm_yuv_rgb.g5a is identical to exa_wm_yuv_rgb.g4a. Just use a symlink intead of duplicating the whole file. Signed-off-by: Ville Syrjälä --- src/render_program/exa_wm_yuv_rgb.g5a | 99 +-- 1 file changed, 1 insertion(+), 98 deletions(-)

[Intel-gfx] [PATCH 5/5] drm/i915: Implement dst colorkeying for VLV/CHV sprites

From: Ville Syrjälä On VLV/CHV we can use the "src key window" bit on the primary plane to implemnt sprite dst colorkeying. This is exactly the same mechanism that would be used on gen2-4 for sprite C dst colorkeying as well. The slight complication with this approach is that we have to adjust

[Intel-gfx] [PATCH 4/5] drm/i915: Make primary/sprite zpos configurable on VLV/CHV

From: Ville Syrjälä VLV/CHV can change the z order between the primary and sprite planes freely. Let's expose that capability by making the zpos property mutable. The cursor plane is always on top, so the cursor zpos is left as an immutable property. The way the hardware is configured is a bit

[Intel-gfx] [PATCH 2/5] drm/i915: Fix VLV/CHV sprite src colorkey mask

From: Ville Syrjälä VLV/CHV sprites use the old plane C layout of the colorkey mask register. Insted of 8 bit masks for each RGB component in the lower bits, the register only has the per channel src key enable bits. On g4x+ sprites those bits are 24,25,26 whereas on the old plane C and VLV/CHV

[Intel-gfx] [PATCH 3/5] drm/i915: Add basic immutable zpos properties for all planes

From: Ville Syrjälä Add an immutable zpos property for all planes. The normal order is (bottom to top): primary,sprite(s),cursor. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 10 -- drivers/gpu/drm/i915/intel_sprite.c | 5 - 2 files changed, 12

[Intel-gfx] [PATCH 1/5] drm/i915: Fix sprite destination colorkeying on SKL+

From: Ville Syrjälä On SKL+ the dst colorkey must be configured on the lower plane that contains the colorkey. This is in contrast to most earlier platforms where the dst colorkey is configured on the plane above. The hardware will peform dst keying only between two immediately adjacent (in

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/gmbus: Enable burst read

On Fri, May 18, 2018 at 02:54:53PM +0530, Ramalingam C wrote: > Support for Burst read in HW is added for HDCP2.2 compliance > requirement. > > This patch enables the burst read for all the gmbus read of more than > 511Bytes, on capable platforms. > > v2: > Extra line is removed. > v3: >

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()

Quoting Patchwork (2018-05-29 18:53:25) > == Series Details == > > Series: series starting with [1/5] drm/i915: Remove stale asserts from > i915_gem_find_active_request() > URL : https://patchwork.freedesktop.org/series/43892/ > State : failure > > == Summary == > > = CI Bug Log - changes

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()

== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9139_full = == Summary -

[Intel-gfx] [PULL] drm-misc-fixes for 4.17

Hi Dave, Although we didn't have anything for you last week, we have a couple of one-liners this week. Tomi is fixing a regression introduced in 4.17, and Dhinakaran added a previously unsupported psr setup time which could be affecting displays in the wild. drm-misc-fixes-2018-05-29: core: Add

Re: [Intel-gfx] [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc

Op 29-05-18 om 15:28 schreef Juha-Pekka Heikkila: > Add P010 definition, semi-planar yuv format where each component > is 16 bits 10 msb containing color value. First come Y plane [10:6] > followed by 2x2 subsampled Cr:Cb plane [10:6:10:6] > > Add P012 definition, semi-planar yuv format where each

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, One potential Spectre vector plugging patch, a NULL deref fix and a DMI info fix reported by user. This is still based on -rc6 as my flight was delayed last week to the extent I missed possibility of sending the PR. For 4.19, Rodrigo will be picking up drm-next after Jani is done with

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error

On Tue, 29 May 2018 17:17:02 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-05-29 16:10:44) On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson wrote: > Quoting Michal Wajdeczko (2018-05-28 18:16:18) >> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and >>

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error

Quoting Michal Wajdeczko (2018-05-29 16:10:44) > On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2018-05-28 18:16:18) > >> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and > >> those events are now handled by

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error

On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-05-28 18:16:18) SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and those events are now handled by intel_guc_to_host_event_handler_mmio(). We should not try to read it on MMIO action

Re: [Intel-gfx] [RFC PATCH] drm/i915/guc: New interface files for GuC starting in Gen11

Hi, On Fri, 25 May 2018 23:59:35 +0200, Oscar Mateo wrote: GuC interface has been redesigned (or cleaned up, rather) starting with Gen11, as a stepping stone towards a new branching strategy that helps maintain backwards compatibility with previous Gens, as well as sideward compatibility with

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error

Quoting Michal Wajdeczko (2018-05-28 18:16:18) > SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and > those events are now handled by intel_guc_to_host_event_handler_mmio(). > > We should not try to read it on MMIO action error as 1) we may be using > different set of

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable P010, P012 and P016 formats for GLK/CNL

== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4253 -> Patchwork_9140 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P010, P012 and P016 formats for GLK/CNL

== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Add P010, P012, P016 format definitions and fourcc Okay! Commit: drm/i915: Add P010, P012,

Re: [Intel-gfx] [PATCH i-g-t] igt/gem_ctx_isolation: Test INSTPM back to gen6

On 29/05/18 12:16, Chris Wilson wrote: Lionel pointed out that INSTPM was context saved, at least from gen6, not from gen9. The only caveat is that INSTPM is a masked register (the upper 16bits are a write-enable mask, the lower 16bits the value to change) and also contains a read-only counter

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P010, P012 and P016 formats for GLK/CNL

== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : warning == Summary == $ dim checkpatch origin/drm-tip 28b8b10f6e1d drm: Add P010, P012, P016 format definitions and fourcc -:28: WARNING:LONG_LINE: line

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()

== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4253 -> Patchwork_9139 = == Summary - WARNING ==

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()

== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Remove stale asserts from

[Intel-gfx] [PATCH 4/4] drm/i915: enable P010, P012, P016 formats for primary and sprite planes

Enabling of P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by: Juha-Pekka Heikkila --- drivers/gpu/drm/i915/intel_display.c | 24 +- drivers/gpu/drm/i915/intel_sprite.c | 39 +++- 2 files

[Intel-gfx] [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats

Preparations for enabling P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by: Juha-Pekka Heikkila --- drivers/gpu/drm/i915/intel_atomic.c | 3 +- drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +- drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [PATCH 5/5] drm/i915: Only sanitize GEM from late suspend

During testing we encounter a conflict between SUSPEND_TEST_DEVICES and disabling reset (gem_eio/suspend). This results in the device continuing on without being reset, but since it has gone through HW sanitization to account for the suspend/resume cycle, we have to assume the device has been

[Intel-gfx] [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc

Add P010 definition, semi-planar yuv format where each component is 16 bits 10 msb containing color value. First come Y plane [10:6] followed by 2x2 subsampled Cr:Cb plane [10:6:10:6] Add P012 definition, semi-planar yuv format where each component is 16 bits 12 msb containing color value. First

[Intel-gfx] [PATCH 3/5] drm/i915: "Race-to-idle" after switching to the kernel context

During suspend we want to flush out all active contexts and their rendering. To do so we queue a request from the kernel's context, once we know that request is done, we know the GPU is completely idle. To speed up that switch bump the GPU clocks. Switching to the kernel context prior to idling

[Intel-gfx] [PATCH 2/5] drm/i915: Switch to kernel context before idling at runtime

We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through

[Intel-gfx] [PATCH 1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()

Since we use i915_gem_find_active_request() from inside intel_engine_dump() and may call that at any time, we do not guarantee that the engine is paused nor that the signal kthreads and irq handler are suspended, so we cannot assert that the breadcrumb doesn't advance and that the irq hasn't

[Intel-gfx] [PATCH 4/5] drm/i915: After reset on sanitization, reset the engine backends

As we reset the GPU on suspend/resume, we also do need to reset the engine state tracking so call into the engine backends. This is especially important so that we can also sanitize the state tracking across resume. References: https://bugs.freedesktop.org/show_bug.cgi?id=106702 Signed-off-by:

[Intel-gfx] [PATCH 2/4] drm/i915: Add P010, P012, P016 plane control definitions

Add needed plane control flag definitions for P010, P012 and P016 formats. Signed-off-by: Juha-Pekka Heikkila --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 6953419..a7e9316

[Intel-gfx] [PATCH 0/4] Enable P010, P012 and P016 formats for GLK/CNL

These patches enable P010, P012 and P016 formats for GLK and CNL. These formats are similar to NV12 extending from 8 bits per channel to 10, 12 and 16 bits per channel. For user space components there is in IGT kms_available_modes_crc test which can test these new modes, test need to be

Re: [Intel-gfx] [PATCH v4 00/11] Workarounds for Icelake

Oscar Mateo writes: > The remaining WA patches that haven't been merged to date, plus > two new ones (WaEnablePreemptionGranularityControlByUMD & > Wa_1406463099). > > Oscar Mateo (11): > drm/i915/icl: WaDisableImprovedTdlClkGating > drm/i915/icl: WaEnableStateCacheRedirectToCS >

Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization

FYI, we're setting this in Mesa : https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130 https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67 I don't think we realized this was a privileged register. Anuj: Maybe we can drop it? -

Re: [Intel-gfx] [PATCH 11/11] drm/i915/icl: Wa_1406463099

Oscar Mateo writes: > Prevents an error in the GAM unit. Also known as WaGamTlbPendError > > References: HSDES#1406463099 > References: HSDES#1406465643 > Signed-off-by: Oscar Mateo Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_reg.h | 5 +++-- >

Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization

Oscar Mateo writes: > Enables blend optimization for floating point RTs > > v2: Rebased on top of the WA refactoring > v3: Added References (Mika) > > References: HSDES#1406393558 > Cc: Mika Kuoppala > Signed-off-by: Oscar Mateo Let's see if we can get away without whitelisting this,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error

== Series Details == Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error URL : https://patchwork.freedesktop.org/series/43865/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9138_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

Quoting Stephen Rothwell (2018-05-29 12:26:05) > Hi all, > > After merging the drm-intel-fixes tree, today's linux-next build (i386 > defconfig) failed like this: Thanks for reporting. I've added a patch to fix the issue now. I'll talk with our CI team about testing 32-bit building to try to

[Intel-gfx] ✓ Fi.CI.IGT: success for RFT mm/oomkill: Don't skip the reaper

== Series Details == Series: RFT mm/oomkill: Don't skip the reaper URL : https://patchwork.freedesktop.org/series/43884/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9137_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] [PATCH i-g-t] igt/gem_ctx_isolation: Test INSTPM back to gen6

Lionel pointed out that INSTPM was context saved, at least from gen6, not from gen9. The only caveat is that INSTPM is a masked register (the upper 16bits are a write-enable mask, the lower 16bits the value to change) and also contains a read-only counter bit (which counts flushes, and so flip

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error

== Series Details == Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error URL : https://patchwork.freedesktop.org/series/43865/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9138 = == Summary - SUCCESS == No regressions found. External

Re: [Intel-gfx] [PATCH 03/11] drm/i915/icl: Wa_2006665173

Oscar Mateo writes: > Disable blend embellishment in RCC. > > Also, some other registers style fixed in passing. > > v2: Rebased on top of the WA refactoring > v3: Added References (Mika) > v4: > - Fixed in B0 > - Mentioned style fixes in commit message > > References: HSDES#2006665173 > Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for RFT mm/oomkill: Don't skip the reaper

== Series Details == Series: RFT mm/oomkill: Don't skip the reaper URL : https://patchwork.freedesktop.org/series/43884/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9137 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9137 need

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v6] intel-gpu-top: Rewrite the tool to be safe to use

On 4 April 2018 at 16:26, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio > register access. This patch rewrites it to use only PMU. > > Only overall command streamer busyness and GPU global data such as power > and

[Intel-gfx] [PATCH] RFT mm/oomkill: Don't skip the reaper

If we find a task that has already been selected for reaping, consider that it may still free some memory. Currently, we skip such tasks believing that we've already extracted as memory free pages as possible from before hitting a livelock. In practice, at least on single user systems deliberating

Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2

> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Tuesday, May 29, 2018 2:01 PM > To: C, Ramalingam > Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; seanp...@chromium.org; chris@chris- >

Re: [Intel-gfx] [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface

On Tuesday 29 May 2018 02:12 PM, Daniel Vetter wrote: On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote: On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote: On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote: On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C

[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

Hi all, After merging the drm-intel-fixes tree, today's linux-next build (i386 defconfig) failed like this: In file included from include/asm-generic/barrier.h:20:0, from arch/x86/include/asm/barrier.h:86, from include/linux/nospec.h:8, from

[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "net/sch_generic: Shut up noise"

== Series Details == Series: Revert "net/sch_generic: Shut up noise" URL : https://patchwork.freedesktop.org/series/43878/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9136_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH 02/11] drm/i915/icl: WaEnableStateCacheRedirectToCS

Oscar Mateo writes: > Redirects the state cache to the CS Command buffer section for > performance reasons. > > v2: Rebased > v3: Rebased on top of the WA refactoring > v3: Added References (Mika) > > References: HSDES#1604325460 > Cc: Mika Kuoppala > Signed-off-by: Oscar Mateo Reviewed-by:

Re: [Intel-gfx] [PATCH 01/11] drm/i915/icl: WaDisableImprovedTdlClkGating

Oscar Mateo writes: > Revert to the legacy implementation. > > v2: GEN7_ROW_CHICKEN2 is masked > v3: > - Rebased > - Renamed to Wa_2006611047 > - A0 and B0 only > v4: > - Add spaces around '<<' (and fix the surrounding code as well) > - Mark the WA as pre-prod > v5: Rebased on top of

Re: [Intel-gfx] [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface

On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote: > On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote: > > > > > > On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote: > > > On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote: > > > > Initialize HDCP2.2

Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2

On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Tuesday, May 29, 2018 12:27 PM > > To: C, Ramalingam > > Cc: intel-gfx@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function

On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote: > > Den 24.05.2018 11.16, skrev Daniel Vetter: > > On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote: > > > This is the first step in getting generic fbdev emulation. > > > A drm_fb_helper_funcs.fb_probe function is

  1   2   >