Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

On Fri, Feb 23, 2018 at 09:25:03PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > While we want to potentially support multiple different gamma/degamma > LUT sizes we can (and should) at least check that the blob length > is a multiple of the LUT entry size.

Re: [Intel-gfx] [PATCH 4/6] drm: Introduce drm_color_lut_size()

On Fri, Feb 23, 2018 at 09:25:04PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Provide a small helper to convert the blob length in bytes > to the number of LUT entries. > > Signed-off-by: Ville Syrjälä > --- >

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote: > On 2018-02-22 04:42 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The documentation for the ctm matrix suggests a two's complement > > format, but at least the i915 implementation is using

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes

On Mon, 2018-03-05 at 18:51 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > All CNL universal planes support horizontal mirroring. Currently > we expose the capability only for the primary plane. Expose it > for the overlay planes as well. > > Cc: Joonas

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/cnl: document WaVFUnitClockGatingDisable

== Series Details == Series: drm/i915/cnl: document WaVFUnitClockGatingDisable URL : https://patchwork.freedesktop.org/series/39409/ State : failure == Summary == Possible new issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl)

Re: [Intel-gfx] [PATCH 11/15] drm/i915/guc: Always print log stats in i915_guc_info when using GuC

On 2/27/2018 6:22 PM, Michał Winiarski wrote: While some of the content in this file is related to GuC submission only, that's not the case with log related statistics. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: Add Wa_2201832410

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 URL : https://patchwork.freedesktop.org/series/39408/ State : warning == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-a-64x64-right-edge: dmesg-warn -> PASS (shard-hsw)

Re: [Intel-gfx] [PATCH 09/15] drm/i915/guc: Move check for fast memcpy_wc to relay creation

On 2/27/2018 6:22 PM, Michał Winiarski wrote: We only need those fast memcpy_wc when we're using relay to read continuous GuC log. Let's prevent the user from creating a relay if we know we won't be able to keep up with GuC. Signed-off-by: Michał Winiarski Cc:

Re: [Intel-gfx] [PATCH 08/15] drm/i915/guc: Split relay control and GuC log level

On 2/27/2018 6:22 PM, Michał Winiarski wrote: Those two concepts are really separate. Since GuC is writing data into its own buffer and we even provide a way for userspace to read directly from it using i915_guc_log_dump debugfs, there's no real reason to tie log level with relay creation.

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm/i915/error: remove unused gen8_engine_sync_index

== Series Details == Series: series starting with [v2,1/3] drm/i915/error: remove unused gen8_engine_sync_index URL : https://patchwork.freedesktop.org/series/39403/ State : failure == Summary == Possible new issues: Test gem_eio: Subgroup in-flight-external:

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm: Make sure at least one plane supports the fb format (rev3)

== Series Details == Series: series starting with [v2,1/3] drm: Make sure at least one plane supports the fb format (rev3) URL : https://patchwork.freedesktop.org/series/39383/ State : failure == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup

Re: [Intel-gfx] [PULL] drm-misc-next

On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote: > On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote: >> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote: >>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul wrote: >>> > >>>

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

On 3/5/2018 7:44 PM, Michał Winiarski wrote: On Mon, Mar 05, 2018 at 04:01:18PM +0530, Sagar Arun Kamble wrote: On 2/27/2018 6:22 PM, Michał Winiarski wrote: Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using

Re: [Intel-gfx] [PATCH 02/15] drm/i915/guc: Create common entry points for log register/unregister

On 3/5/2018 7:08 PM, Michał Winiarski wrote: On Mon, Mar 05, 2018 at 12:39:58PM +0530, Sagar Arun Kamble wrote: Overall change looks good. Could you please clarify on below: intel_uc_log_register|unregister are removed in patch later in the series. Should we just stay with inner functions

Re: [Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

On 3/5/2018 5:40 PM, Michał Winiarski wrote: On Mon, Mar 05, 2018 at 05:28:33PM +0530, Sagar Arun Kamble wrote: On 2/27/2018 6:22 PM, Michał Winiarski wrote: Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter

On 3/5/2018 6:43 PM, Piotr Piórkowski wrote: It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter where we are passing GT type and Core family values. Lets stop setup this parameter and remove related definitions. Minor change to sentence above: Let's stop/remove setup of this

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add schedule out notification of preempted but completed request (rev2)

== Series Details == Series: drm/i915: add schedule out notification of preempted but completed request (rev2) URL : https://patchwork.freedesktop.org/series/38903/ State : success == Summary == Series 38903v2 drm/i915: add schedule out notification of preempted but completed request

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

== Series Details == Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating URL : https://patchwork.freedesktop.org/series/39410/ State : success == Summary == Series 39410v1 drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

[Intel-gfx] [PATCH v3] drm/i915: add schedule out notification of preempted but completed request

There is one corner case missing schedule out notification of the preempted request. The preempted request is just completed when preemption happen, then it will be canceled and won't be resubmitted later, GVT-g will lost the schedule out notification. Here add schedule out notification if found

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: document WaVFUnitClockGatingDisable

== Series Details == Series: drm/i915/cnl: document WaVFUnitClockGatingDisable URL : https://patchwork.freedesktop.org/series/39409/ State : success == Summary == Series 39409v1 drm/i915/cnl: document WaVFUnitClockGatingDisable

Re: [Intel-gfx] [PATCH] drm/i915/cnl: document WaVFUnitClockGatingDisable

On Mon, Mar 05, 2018 at 05:20:00PM -0800, Rodrigo Vivi wrote: > No functional change. WA is already properly applied. > but in different databases it has different names. > Let's document all of them to avoid future confusion. Works for me. Reviewed-by: Rafael Antognolli

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Add Wa_2201832410

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 URL : https://patchwork.freedesktop.org/series/39408/ State : success == Summary == Series 39408v1 drm/i915/cnl: Add Wa_2201832410 https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/1/mbox/ Known issues: Test

[Intel-gfx] [PATCH] drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

No functional change since WA is already applied. But since it has different names on different databases, let's document it here to avoid future confusion. Cc: Radhakrishna Sripada Signed-off-by: Rodrigo Vivi ---

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

On 3/5/2018 2:21 PM, Daniele Ceraolo Spurio wrote: some of the static functions used from capture() have the "i915_" prefix while other don't; most of them take i915 as a parameter, but one of them derives it internally from error->i915. Let's be consistent by avoiding prefix for static

[Intel-gfx] [PATCH] drm/i915/cnl: document WaVFUnitClockGatingDisable

No functional change. WA is already properly applied. but in different databases it has different names. Let's document all of them to avoid future confusion. Cc: Rafael Antognolli Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

"Clock gating bug in GWL may not clear barrier state when an EOT is received, causing a hang the next time that barrier is used." HSDES: 2201832410 Cc: Rafael Antognolli Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 3

[Intel-gfx] linux-next: manual merge of the mali-dp tree with the drm-misc tree

Hi Liviu, Today's linux-next merge of the mali-dp tree got a conflict in: drivers/gpu/drm/arm/malidp_planes.c between commit: 81af63a4af82 ("drm: Don't pass clip to drm_atomic_helper_check_plane_state()") from the drm-misc tree and commit: 4968211e7b8f ("drm: mali-dp: Uninitialized

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

== Series Details == Series: drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+ URL : https://patchwork.freedesktop.org/series/39393/ State : warning == Summary == Possible new issues: Test kms_concurrent: Subgroup pipe-b: pass -> SKIP

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

On Wed, Feb 28, 2018 at 03:10:24PM -0500, Lyude Paul wrote: > On Wed, 2018-02-28 at 11:57 -0800, Manasi Navare wrote: > > On Wed, Feb 28, 2018 at 02:41:06PM -0500, Lyude Paul wrote: > > > On Wed, 2018-02-28 at 11:27 -0800, Manasi Navare wrote: > > > > On Wed, Feb 28, 2018 at 02:07:34PM -0500,

Re: [Intel-gfx] [PULL] drm-misc-next

On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote: > On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote: >> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul wrote: >> > >> > Hi Dave, >> > Here's this weeks pull, relatively small when you pull out the

Re: [Intel-gfx] Question about latest skl_dmc_ver1_27.bin and kernel version.

Hi Paul, The use of symbolic links was deprecated exactly to avoid this kind of situation you faced when blindly replacing dmc 1.26 per 1.27. We never tested that kernel version with that DMC so we don't know what to expect. As the regular end users concerns they should never touch any firmware

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

Ville Syrjälä writes: > On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >> Ville Syrjala writes: >> >> > From: Ville Syrjälä >> > >> > To make life easier for drivers, let's have the core

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On 2018-03-05 04:33 PM, Alex Deucher wrote: > On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä > wrote: >> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >>> Ville Syrjala writes: >>> From: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/error: remove unused gen8_engine_sync_index

== Series Details == Series: series starting with [v2,1/3] drm/i915/error: remove unused gen8_engine_sync_index URL : https://patchwork.freedesktop.org/series/39403/ State : success == Summary == Series 39403v1 series starting with [v2,1/3] drm/i915/error: remove unused

[Intel-gfx] [PATCH v2 1/3] drm/i915/error: remove unused gen8_engine_sync_index

Leftover from Gen8 ringbuffer support removal Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gpu_error.c | 21 - 1 file

[Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

some of the static functions used from capture() have the "i915_" prefix while other don't; most of them take i915 as a parameter, but one of them derives it internally from error->i915. Let's be consistent by avoiding prefix for static functions and by getting i915 from error->i915. While at it,

[Intel-gfx] [PATCH v2 3/3] drm/i915/error: capture uc_state after gen_state

error->device_info.has_guc, which we check in capture_uc_state, is set in capture_gen_state, so the latter needs to be performed first. v2: rebased Reported-by: Vinay Belgaumkar Fixes: 7d41ef3479a6 (drm/i915: Add Guc/HuC firmware details to error state) Cc: Vinay

Re: [Intel-gfx] [PATCH 3/3] drm/i915/error: capture uc_state after gen_state

On 03/03/18 01:55, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2018-03-02 19:19:30) error->device_info.has_guc, which we check in capture_uc_state, is set in capture_gen_state, so the latter needs to be performed first. Reported-by: Vinay Belgaumkar Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Make sure at least one plane supports the fb format (rev3)

== Series Details == Series: series starting with [v2,1/3] drm: Make sure at least one plane supports the fb format (rev3) URL : https://patchwork.freedesktop.org/series/39383/ State : success == Summary == Series 39383v3 series starting with [v2,1/3] drm: Make sure at least one plane

[Intel-gfx] ✗ Fi.CI.IGT: warning for Test the plane formats on the Chamelium

== Series Details == Series: Test the plane formats on the Chamelium URL : https://patchwork.freedesktop.org/series/39380/ State : warning == Summary == Possible new issues: Test gem_exec_blt: Subgroup cold-max: pass -> DMESG-WARN (shard-hsw) Test kms_flip:

Re: [Intel-gfx] [PATCH v12 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

On 03/02/2018 12:04 AM, Sagar Arun Kamble wrote: Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Sagar Arun Kamble

[Intel-gfx] [PATCH v2 2/3] drm/i915: Eliminate the horrendous format check code

From: Ville Syrjälä Now that the core makes sure that the pixel format is supported by at least one plane, we can eliminate the hand rolled code for the same thing in i915. The way we were doing was extremely inconvenient because not only did you have to add the

[Intel-gfx] [PATCH v2 1/3] drm: Make sure at least one plane supports the fb format

From: Ville Syrjälä To make life easier for drivers, let's have the core check that the requested pixel format is supported by at least one plane when creating a new framebuffer. v2: Accept anyformat if the driver doesn't do planes (Eric)

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä wrote: > On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >> Ville Syrjala writes: >> >> > From: Ville Syrjälä >> > >> > To make life easier for

[Intel-gfx] Question about latest skl_dmc_ver1_27.bin and kernel version.

I am trying to setup Intel's new open-source iHD driver on a Yocto environment. https://software.intel.com/en-us/articles/build-and-debug-open-source-media-stack The documentation says that skl_dmc_ver1_27.bin is required. Their documentation updates a symlink (skl_dmc_ver1.bin), as if the

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > To make life easier for drivers, let's have the core check that the > > requested pixel format is supported by at

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

Ville Syrjala writes: > From: Ville Syrjälä > > To make life easier for drivers, let's have the core check that the > requested pixel format is supported by at least one plane when creating > a new framebuffer. > > Signed-off-by:

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm: Make sure at least one plane supports the fb format

== Series Details == Series: series starting with [1/3] drm: Make sure at least one plane supports the fb format URL : https://patchwork.freedesktop.org/series/39383/ State : failure == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-a-ts-continuation-modeset:

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Check that the error state does hold the expected state

On 05/03/18 02:09, Chris Wilson wrote: Actually check the error state exists (!"No error state captured") and that it contains the expected engine dump. v2: Throw in some debug clues. Signed-off-by: Chris Wilson --- tests/drv_hangman.c | 12 1 file

Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as supported format for primary plane

On Fri, Feb 23, 2018 at 10:08:25AM +, Srinivas, Vidya wrote: > > > > -Original Message- > > From: Juha-Pekka Heikkila [mailto:juhapekka.heikk...@gmail.com] > > Sent: Friday, February 23, 2018 3:35 PM > > To: Srinivas, Vidya ; intel- > >

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_fbc parameter at runtime better.

On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst wrote: > If i915.enable_fbc is cleared at runtime, but FBC was previously enabled > then we don't disable FBC until the next time the crtc is disabled. > > Make sure that if the module param is changed, we disable FBC in >

Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote: > From: Gaurav Singh > > On Apollolake, with stress test warm reboot, audio card > was not getting enumerated after reboot. This was a > spurious issue happening on Apollolake. HW codec and > HD audio controller

[Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.

Only try to set those values if the properties are supported. This fixes the kms_chameium tests to run on vc4 again. Reported-by: Maxime Ripard Cc: Paul Kocialkowski Cc: Eric Anholt Cc: Boris Brezillon

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter

On 3/5/2018 5:13 AM, Piotr Piórkowski wrote: It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter where we are passing GT type and Core family values. Lets stop setup this parameter and remove related definitions. v2: (this time without squashed HAX) - New title and

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

== Series Details == Series: drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+ URL : https://patchwork.freedesktop.org/series/39393/ State : success == Summary == Series 39393v1 drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

[Intel-gfx] [PATCH] drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

From: Ville Syrjälä We don't use the enum i9xx_plane_id namespace on SKL+ anymore, so do not initialize the related plane_to_crtc_mapping[] table either. Actually the only remaining user of that table is the pre-g4x watermark code, but no harm in initializing the

[Intel-gfx] [PATCH igt v3] igt/gen7_forcewake_mt: Make the mmio register as volatile

Prevent the compiler from caching reads/writes to the hw register as we do want to perform mmio. Whilst fixing up the mmio access, also ensure that we do not leave the test with any other bits still set in the forcewake register to prevent affecting other tests, as spotted by Tvrtko. v2: Use

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Some plane init cleanups

== Series Details == Series: drm/i915: Some plane init cleanups URL : https://patchwork.freedesktop.org/series/39390/ State : failure == Summary == Series 39390v1 drm/i915: Some plane init cleanups https://patchwork.freedesktop.org/api/1.0/series/39390/revisions/1/mbox/ Possible new

Re: [Intel-gfx] [PATCH igt] Bump measure_ring_size() timer interval

On 05/03/18 03:03, Chris Wilson wrote: It appears that waiting for a 100us period whereby we are unable to submit another batch and proclaim the ring full, may have the false positive where the scheduler intervenes and we are signalled twice before having slept on ring space. Increasing the

[Intel-gfx] [PATCH 10/11] drm/i915: Extract skl_universal_plane_init()

From: Ville Syrjälä There's not much point in following the primary vs. sprite for the SKL+ universal plane init code. The only difference is of our own doing in the form of the .check_plane(). Let's make a small exception for that little detail and otherwise share

[Intel-gfx] [PATCH 07/11] drm/i915: Add missing pixel formats for skl+ "sprites"

From: Ville Syrjälä All SKL+ universal planes support the same set of formats (with the exception of NV12 which we don't expose yet). Make the format lists for primary and sprites the same. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 08/11] drm/i915: Move plane_state->scaler_id initialization into intel_create_plane_state()

From: Ville Syrjälä No point in having each caller of intel_create_plane_state() initialize the scaler_id to -1. Instead just do it in intel_create_plane_state(). Previously we left scaler_id at 0 for pre-SKL platforms, but I can't see how initializing it to -1

[Intel-gfx] [PATCH 05/11] drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes

From: Ville Syrjälä All CNL universal planes support horizontal mirroring. Currently we expose the capability only for the primary plane. Expose it for the overlay planes as well. Cc: Joonas Lahtinen Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 11/11] drm/i915: s/intel_plane/plane/ in sprite init

From: Ville Syrjälä Use a more familiar naming pattern for our variables in the sprite plane init function. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sprite.c | 78 ++--- 1 file

[Intel-gfx] [PATCH 09/11] drm/i915: Introduce intel_plane_alloc()

From: Ville Syrjälä Pull the common plane+plane_state allocation into a small helper. Reduces the amount of boilerplate in the plane initialization functions. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [PATCH 06/11] drm/i915: Disallow plane scaling with specific pixel formats

From: Ville Syrjälä Plane scaling is not supported with specific pixel formats. Disallow plane scaling when such a format is used. Currently the only such pixel format we expose is C8, but in case we add more in the future let's make it easy to deal with them.

[Intel-gfx] [PATCH 01/11] drm/i915: Constify intel_plane_funcs

From: Ville Syrjälä intel_plane funcs can be cosnt. Make it so. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 04/11] drm/i915: Don't populate plane->i9xx_plane for sprites

From: Ville Syrjälä enum i9xx_plane_id namespace is not valid for any sprite plane, so let's not even populate plane->i9xx_plane. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sprite.c | 1 - 1 file changed, 1

[Intel-gfx] [PATCH 02/11] drm/i915: Fix tabs vs. spaces

From: Ville Syrjälä The sprite code has a bunch of spaces where tabs should be used. Fix it up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sprite.c | 20 ++-- 1 file changed, 10 insertions(+), 10

[Intel-gfx] [PATCH 03/11] drm/i915: Populate possible_crtcs for primary/cursor planes

From: Ville Syrjälä We're currently not providing the possible_crtcs mask to drm_universal_plane_init() for primary/cursor planes. While that does work on account of drm_crtc_init_with_planes() filling those up for us, it's inconsisten with what we're doing for

[Intel-gfx] [PATCH 00/11] drm/i915: Some plane init cleanups

From: Ville Syrjälä Attempt at cleaning up some of plane init stuff. The main attraction is removing some of the code duplication in SKL+ "primary" vs. "sprite" init. Ville Syrjälä (11): drm/i915: Constify intel_plane_funcs drm/i915: Fix tabs vs. spaces

[Intel-gfx] ✓ Fi.CI.BAT: success for Test the plane formats on the Chamelium

== Series Details == Series: Test the plane formats on the Chamelium URL : https://patchwork.freedesktop.org/series/39380/ State : success == Summary == IGT patchset tested on top of latest successful build 23f7da18a92059610792299cfdb03d2c922a9948 lib/igt_pm: Restore runtime pm state on test

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle changing enable_fbc parameter at runtime better.

== Series Details == Series: drm/i915: Handle changing enable_fbc parameter at runtime better. URL : https://patchwork.freedesktop.org/series/39375/ State : success == Summary == Possible new issues: Test drv_suspend: Subgroup forcewake: skip -> PASS

Re: [Intel-gfx] [PATCH] drm/i915: Tell vga_switcheroo whether runtime PM is used

On Mon, 05 Mar 2018, Imre Deak wrote: > On Mon, Feb 26, 2018 at 04:57:11PM +0100, Lukas Wunner wrote: >> On Mon, Feb 26, 2018 at 04:41:09PM +0200, Imre Deak wrote: >> > On Sun, Feb 25, 2018 at 12:42:30AM +0100, Lukas Wunner wrote: >> > > DRM drivers need to tell

Re: [Intel-gfx] [PATCH v14 6/6] drm/i915: expose rcs topology through query uAPI

Quoting Lionel Landwerlin (2018-02-22 19:53:59) > With the introduction of asymmetric slices in CNL, we cannot rely on > the previous SUBSLICE_MASK getparam to tell userspace what subslices > are available. Here we introduce a more detailed way of querying the > Gen's GPU topology that doesn't

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Make sure at least one plane supports the fb format

== Series Details == Series: series starting with [1/3] drm: Make sure at least one plane supports the fb format URL : https://patchwork.freedesktop.org/series/39383/ State : success == Summary == Series 39383v1 series starting with [1/3] drm: Make sure at least one plane supports the fb

Re: [Intel-gfx] [PATCH] drm/i915: Tell vga_switcheroo whether runtime PM is used

On Mon, Feb 26, 2018 at 04:57:11PM +0100, Lukas Wunner wrote: > On Mon, Feb 26, 2018 at 04:41:09PM +0200, Imre Deak wrote: > > On Sun, Feb 25, 2018 at 12:42:30AM +0100, Lukas Wunner wrote: > > > DRM drivers need to tell vga_switcheroo whether they use runtime PM. > > > If they do use it,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Assert that the request is indeed complete when signaled from irq

== Series Details == Series: drm/i915: Assert that the request is indeed complete when signaled from irq URL : https://patchwork.freedesktop.org/series/39369/ State : success == Summary == Known issues: Test kms_chv_cursor_fail: Subgroup pipe-b-128x128-top-edge:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

== Series Details == Series: drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path URL : https://patchwork.freedesktop.org/series/39367/ State : success == Summary == Known issues: Test kms_chv_cursor_fail: Subgroup pipe-b-256x256-left-edge:

Re: [Intel-gfx] [PATCH v14 5/6] drm/i915: add query uAPI

On 05/03/18 14:54, Joonas Lahtinen wrote: Quoting Lionel Landwerlin (2018-02-22 19:53:58) There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are

Re: [Intel-gfx] [PATCH v14 5/6] drm/i915: add query uAPI

Quoting Lionel Landwerlin (2018-02-22 19:53:58) > There are a number of information that are readable from hardware > registers and that we would like to make accessible to userspace. One > particular example is the topology of the execution units (how are > execution units grouped in subslices

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] drm/i915/uc: Start preparing GuC/HuC for reset

== Series Details == Series: series starting with [v3,1/2] drm/i915/uc: Start preparing GuC/HuC for reset URL : https://patchwork.freedesktop.org/series/39381/ State : failure == Summary == Series 39381v1 series starting with [v3,1/2] drm/i915/uc: Start preparing GuC/HuC for reset

[Intel-gfx] [PATCH 3/3] drm: Fix some coding style issues

From: Ville Syrjälä Put an empty line between the variable declarations and the code, and use tabs for alignment. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_framebuffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[Intel-gfx] [PATCH 2/3] drm/i915: Eliminate the horrendous format check code

From: Ville Syrjälä Now that the core makes sure that the pixel format is supported by at least one plane, we can eliminate the hand rolled code for the same thing in i915. The way we were doing was extremely inconvenient because not only did you have to add the

[Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

From: Ville Syrjälä To make life easier for drivers, let's have the core check that the requested pixel format is supported by at least one plane when creating a new framebuffer. Signed-off-by: Ville Syrjälä ---

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/uc: Start preparing GuC/HuC for reset

Quoting Michal Wajdeczko (2018-03-05 14:29:16) > Right after GPU reset there will be a small window of time during which > some of GuC/HuC fields will still show state before reset. Let's start > to fix that by sanitizing firmware status as we will use it shortly. > > v2:

Re: [Intel-gfx] [PATCH igt 01/16] igt/gem_sync: Exercise and measure idle requests

Quoting Joonas Lahtinen (2018-03-05 13:43:33) > For some reason, I've reviewed these from the middle of the series > (maybe transport delay?). Are the rest still applicable or refreshed > somewhere? Virtually all, baring a couple have landed. The current unreviewed pile now has 7 patches, so in

Re: [Intel-gfx] [PATCH i-g-t v2 03/14] lib/igt_kms: Rework pipe properties to be more atomic, v7.

Hi, On Thu, Oct 12, 2017 at 01:54:24PM +0200, Maarten Lankhorst wrote: > In the future I want to allow tests to commit more properties, > but for this to work I have to fix all properties to work better > with atomic commit. Instead of special casing each > property make a bitmask for all

Re: [Intel-gfx] [PATCH] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

Quoting Chris Wilson (2018-03-05 14:34:42) > Quoting Mika Kuoppala (2018-03-05 13:59:43) > > Chris Wilson writes: > > > > > Similar to the staging around handling of engine->submit_request, we > > > need to stop adding to the execlists->queue prior to calling > > >

Re: [Intel-gfx] [PATCH] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

Quoting Mika Kuoppala (2018-03-05 13:59:43) > Chris Wilson writes: > > > Similar to the staging around handling of engine->submit_request, we > > need to stop adding to the execlists->queue prior to calling > > engine->cancel_requests. cancel_requests will move requests

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

v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] [PATCH v3 1/2] drm/i915/uc: Start preparing GuC/HuC for reset

Right after GPU reset there will be a small window of time during which some of GuC/HuC fields will still show state before reset. Let's start to fix that by sanitizing firmware status as we will use it shortly. v2: s/reset_prepare/prepare_to_reset (Michel) don't forget about gem_sanitize

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Extend partial vma coverage to check parallel creation

+ Abdiel Quoting Chris Wilson (2018-02-22 11:48:40) > Quoting Chris Wilson (2018-01-16 10:11:43) > > One important use of partial vma is to provide mappable access to the > > object while it is being used elsewhere (pinned entirely into the > > unmappable portion of the Global GTT, i.e. for use

Re: [Intel-gfx] [PATCH 2/2] drm/i915/breadcrumbs: Assert all missed breadcrumbs were signaled

Quoting Chris Wilson (2018-02-22 11:25:45) > When parking the engines and their breadcrumbs, if we have waiters left > then they missed their wakeup. Verify that each waiter's seqno did > complete. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/2] drm/i915/breadcrumbs: Reduce signaler rbtree to a sorted list

Quoting Chris Wilson (2018-02-22 11:25:44) > The goal here is to try and reduce the latency of signaling additional > requests following the wakeup from interrupt by reducing the list of > to-be-signaled requests from an rbtree to a sorted linked list. The > original choice of using an rbtree was

[Intel-gfx] [RFC PATCH i-g-t 3/3] tests: Add vc4 test suite

Add some various test suites relevant for the vc4 drm driver. Signed-off-by: Maxime Ripard --- tests/vc4_ci/vc4-chamelium-fast.testlist | 4 tests/vc4_ci/vc4-chamelium.testlist | 9 tests/vc4_ci/vc4.testlist| 35

[Intel-gfx] [RFC PATCH i-g-t 2/3] tests/chamelium: Add test case for plane formats

KMS can support a lot of different plane formats that are not being tested by the current chamelium tests. Add some preliminary tests to exert the RGB formats exposed by the KMS planes. Signed-off-by: Maxime Ripard --- tests/Makefile.am | 1 +

[Intel-gfx] [RFC PATCH i-g-t 1/3] tests/chamelium: Move some functions and structures to a common place

We are going to use a few functions already defined in kms_chamelium in other tests. Let's move them out in a separate file / header. Signed-off-by: Maxime Ripard --- tests/Makefile.sources| 5 ++ tests/helpers_chamelium.c | 165

[Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium

Hi, Here is an RFC at starting to test the plane formats using the Chamelium over the HDMI. This was tested using the vc4 DRM driver found on the RaspberryPi. This is still pretty rough around the edges at this point, but I'd like to get feedback on a few issues before getting any further. *

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

On Mon, Mar 05, 2018 at 04:01:18PM +0530, Sagar Arun Kamble wrote: > > > On 2/27/2018 6:22 PM, Michał Winiarski wrote: > > Currently, we're treating relay and mapping of GuC log as a separate > > concepts. We're also using inconsistent locking, sometimes using > > relay_lock, sometimes using

  1   2   >