[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound

== Series Details == Series: series starting with [1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound URL : https://patchwork.freedesktop.org/series/39448/ State : warning == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup

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

On Tue, Mar 06, 2018 at 09:07:52PM +0200, Ville Syrjälä wrote: > On Tue, Mar 06, 2018 at 02:01:21PM -0500, Sean Paul wrote: > > On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote: > > > On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote: > > > > On Mon, Mar 5, 2018

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote: > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms > to be safe. > > v3: Update GLK too. (Ville) > Longer variable names. > if-else in place of ternary operator. > v2: Use local variables for

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

On Tue, Mar 06, 2018 at 02:01:21PM -0500, Sean Paul wrote: > On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote: > > 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

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

On Mon, Mar 05, 2018 at 05:28:12PM -0800, Rodrigo Vivi wrote: > 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 >

Re: [Intel-gfx] [PATCH 5/6] drm: Make property flags u32

On Tue, Mar 06, 2018 at 06:48:48PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The property flags are part of the uabi and we have 32 bits for them. > Pass them around as u32 internally as well, instead of a signed int. > > Signed-off-by: Ville Syrjälä

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

On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote: > 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

[Intel-gfx] [PATCH v6] drm/i915/skl+: Add and enable DP AUX CH mutex

When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it self, so lets use the mutex register that is available in gen9+ to avoid concurrent access by hardware and driver. Older gen handling will be done separated. Reference:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable pipe CRC before disabling the pipe. (rev2)

== Series Details == Series: drm/i915: Disable pipe CRC before disabling the pipe. (rev2) URL : https://patchwork.freedesktop.org/series/39454/ State : failure == Summary == Possible new issues: Test kms_busy: Subgroup extended-pageflip-hang-oldfb-render-a: pass

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

On 2018-03-06 12:13 PM, Daniel Vetter wrote: > On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote: >> On 2018-03-06 07:18 AM, Ville Syrjälä wrote: >>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote: On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:

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

On Tue, Mar 06, 2018 at 11:22:16AM +0100, Maarten Lankhorst wrote: > Op 05-03-18 om 19:50 schreef Rodrigo Vivi: > > 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

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

Op 06-03-18 om 21:02 schreef Rodrigo Vivi: > On Tue, Mar 06, 2018 at 11:22:16AM +0100, Maarten Lankhorst wrote: >> Op 05-03-18 om 19:50 schreef Rodrigo Vivi: >>> 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

Re: [Intel-gfx] [PATCH 1/6] drm: Reject replacing property enum values

On Tue, Mar 06, 2018 at 06:48:44PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > If the property already has the enum value WARN and bail. > Replacing enum values doesn't make sense to me. > > Throw out the pointless list_empty() while at it. > > Cc:

Re: [Intel-gfx] [PATCH 2/6] drm: WARN when trying add enum values to non-enum/bitmask properties

On Tue, Mar 06, 2018 at 06:48:45PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Trying to add enum values to non-enum/bitmask properties is a > programmer mistake. WARN to make sure the developers notice > their mistake. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 6/6] drm: Reject bad property flag combinations

On Tue, Mar 06, 2018 at 06:48:49PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Pimp drm_property_type_valid() to check for more fails with the > property flags. Also make the check before adding the property, > and bail out if things look bad. > > Since

[Intel-gfx] [PATCH v3] drm/i915/psr: Update PSR2 resolution check for Cannonlake

In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms to be safe. v3: Update GLK too. (Ville) Longer variable names. if-else in place of ternary operator. v2: Use local variables for resolution limits and print them (Ville) Cc: Ville Syrjälä

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8 bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, for panels that use this new feature, this would cause a wait interval for clock recovery of at least 512 ms,

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound

Quoting Patchwork (2018-03-06 18:53:28) > == Series Details == > > Series: series starting with [1/2] drm/i915: Stop kicking the signaling > thread on seqno wraparound > URL : https://patchwork.freedesktop.org/series/39448/ > State : warning > > == Summary == > > Possible new issues: >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

== Series Details == Series: drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4 URL : https://patchwork.freedesktop.org/series/39473/ State : success == Summary == Series 39473v1 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote: > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote: > > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms > > to be safe. > > > > v3: Update GLK too. (Ville) > > Longer variable names. > >

Re: [Intel-gfx] [PATCH 4/6] drm/uapi: Deprecate DRM_MODE_PROP_PENDING

On Tue, Mar 06, 2018 at 06:48:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > DRM_MODE_PROP_PENDING is not used anywhere (except printed out > by libdrm proptest/modetest). > > This seems to be yet another thing blindly copied from xrandr. > Quoting

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/39446/ State : failure == Summary == Possible new issues: Test pm_sseu: Subgroup full-enable: pass -> FAIL (shard-apl) Known

Re: [Intel-gfx] [PATCH 3/6] drm: WARN when trying to add enum value > 63 to a bitmask property

On Tue, Mar 06, 2018 at 06:48:46PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Enum values >63 with a bitmask property is a programmer error. WARN > when someone is attempting this. > > Signed-off-by: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev3)

== Series Details == Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev3) URL : https://patchwork.freedesktop.org/series/39238/ State : success == Summary == Series 39238v3 drm/i915/psr: Update PSR2 resolution check for Cannonlake

Re: [Intel-gfx] [PATCH 2/6] drm/i915/icl: Correctly initialize the Gen11 engines

On 02/03/18 08:14, Mika Kuoppala wrote: From: Oscar Mateo Gen11 has up to 4 VCS and up to 2 VECS engines, this patch adds mmio base definitions for all of them. Bspec: 20944 Bspec: 7021 v2: Set the correct mmio_base in intel_engines_init_mmio; updating the base mmio

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Tue, Mar 06, 2018 at 11:24:15PM +0200, Ville Syrjälä wrote: > On Tue, Mar 06, 2018 at 08:45:44PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote: > > > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote: > > > > In

[Intel-gfx] [PATCH v3 3/6] cgroup: Introduce cgroup_permission()

Non-controller kernel subsystems may base access restrictions for cgroup-related syscalls/ioctls on a process' access to the cgroup. Let's make it easy for other parts of the kernel to check these cgroup permissions. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt

[Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data

There are cases where other parts of the kernel may wish to store data associated with individual cgroups without building a full cgroup controller. Let's add interfaces to allow them to register and lookup this private data for individual cgroups. A kernel system (e.g., a driver) that wishes to

[Intel-gfx] [PATCH v3 0/6] DRM/i915 cgroup integration

This is the third iteration of the work previously posted here: (v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html (v2) https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html The high level goal of this work is to allow non-cgroup-controller

[Intel-gfx] [PATCH v3 2/6] cgroup: Introduce task_get_dfl_cgroup()

Wraps task_dfl_cgroup() to also take a reference to the cgroup. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper --- include/linux/cgroup.h | 23 +++ 1 file changed, 23 insertions(+) diff --git

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/6] drm: Reject replacing property enum values

== Series Details == Series: series starting with [1/6] drm: Reject replacing property enum values URL : https://patchwork.freedesktop.org/series/39465/ State : warning == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-a-64x64-top-edge:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev3)

== Series Details == Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev3) URL : https://patchwork.freedesktop.org/series/39238/ State : success == Summary == Possible new issues: Test kms_busy: Subgroup extended-modeset-hang-newfb-render-b:

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/skl+: Add and enable DP AUX CH mutex (rev2)

== Series Details == Series: drm/i915/skl+: Add and enable DP AUX CH mutex (rev2) URL : https://patchwork.freedesktop.org/series/39067/ State : warning == Summary == Series 39067v2 drm/i915/skl+: Add and enable DP AUX CH mutex

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

On Tue, Mar 06, 2018 at 11:56:35AM -0800, Radhakrishna Sripada wrote: > On Mon, Mar 05, 2018 at 05:28:12PM -0800, Rodrigo Vivi wrote: > > 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

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

On Mon, Mar 05, 2018 at 05:40:01PM -0800, Rafael Antognolli wrote: > 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

Re: [Intel-gfx] [PATCH v6] drm/i915/skl+: Add and enable DP AUX CH mutex

On Tue, Mar 06, 2018 at 12:11:03PM -0800, José Roberto de Souza wrote: > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it > self, so lets use the mutex register that is available in gen9+ to > avoid concurrent access by hardware and driver. > Older gen handling will be done

[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/ fi-bdw-5557u total:288

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Tue, 2018-03-06 at 16:48 -0800, Dhinakaran Pandiyan wrote: > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote: > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote: > > > From: Matt Atwood > > > > > >

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Tue, Mar 06, 2018 at 08:45:44PM +, Pandiyan, Dhinakaran wrote: > > > > On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote: > > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote: > > > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms > > >

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Tue, 2018-03-06 at 23:24 +0200, Ville Syrjälä wrote: > On Tue, Mar 06, 2018 at 08:45:44PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote: > > > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote: > > > > In fact,

[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] ✗ Fi.CI.SPARSE: warning for DRM/i915 cgroup integration

== Series Details == Series: DRM/i915 cgroup integration URL : https://patchwork.freedesktop.org/series/39489/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: cgroup: Allow registration and lookup of cgroup private data Okay! Commit: cgroup: Introduce task_get_dfl_cgroup()

[Intel-gfx] ✓ Fi.CI.BAT: success for DRM/i915 cgroup integration

== Series Details == Series: DRM/i915 cgroup integration URL : https://patchwork.freedesktop.org/series/39489/ State : success == Summary == Series 39489v1 DRM/i915 cgroup integration https://patchwork.freedesktop.org/api/1.0/series/39489/revisions/1/mbox/ Known issues: Test

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote: > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote: > > From: Matt Atwood > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8 > > bits to 7 bits in DPCD

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

== Series Details == Series: drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4 URL : https://patchwork.freedesktop.org/series/39473/ State : success == Summary == Possible new issues: Test kms_busy: Subgroup extended-modeset-hang-newfb-render-b:

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8 > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, for > panels that use this

[Intel-gfx] [PATCH v3 4/6] drm/i915: cgroup integration (v2)

Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow userspace to set i915-specific parameters for individual cgroups. i915 cgroup data will be registered and later looked up via the new cgroup_priv infrastructure. v2: - Large rebase/rewrite for new cgroup_priv interface

[Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

There are cases where a system integrator may wish to raise/lower the priority of GPU workloads being submitted by specific OS process(es), independently of how the software self-classifies its own priority. Exposing "priority offset" as an i915-specific cgroup parameter will enable such

[Intel-gfx] [PATCH v3 6/6] drm/i915: Add context priority & priority offset to debugfs (v2)

Update i915_context_status to include priority information. v2: - Clarify that the offset is based on cgroup (Chris) Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

On Mon, 2018-03-05 at 03:12 -0800, Piorkowski, Piotr wrote: > On Fri, 2018-03-02 at 12:53 +0530, Sagar Arun Kamble wrote: > > > > > > On 3/2/2018 12:44 AM, John Spotswood wrote: > > > > > > On Thu, 2018-03-01 at 17:35 +0530, Sagar Arun Kamble wrote: > > > > > > > > On 3/1/2018 1:32 PM, Chris

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

On Tue, Mar 06, 2018 at 09:12:02PM +0100, Maarten Lankhorst wrote: > Op 06-03-18 om 21:02 schreef Rodrigo Vivi: > > On Tue, Mar 06, 2018 at 11:22:16AM +0100, Maarten Lankhorst wrote: > >> Op 05-03-18 om 19:50 schreef Rodrigo Vivi: > >>> On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst

[Intel-gfx] [PATCH i-g-t 1/2] tools: Introduce intel_cgroup tool

intel_cgroup is used to modify i915 cgroup parameters. At the moment only a single parameter is supported (GPU priority offset). In the future the driver may support additional parameters as well (e.g., limits on memory usage). Signed-off-by: Matt Roper ---

[Intel-gfx] [PATCH i-g-t 2/2] tests: Introduce drv_cgroup

drv_cgroup exercises both valid and invalid usage of the i915 cgroup parameter ioctl. Signed-off-by: Matt Roper --- tests/Makefile.sources | 1 + tests/drv_cgroup.c | 236 + 2 files changed, 237 insertions(+)

[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 3/6] drm/i915/icl: new context descriptor support

On 3/2/2018 8:14 AM, Mika Kuoppala wrote: From: Daniele Ceraolo Spurio Starting from Gen11 the context descriptor format has been updated in the HW. The hw_id field has been considerably reduced in size and engine class and instance fields have been added.

[Intel-gfx] ✗ Fi.CI.IGT: failure for DRM/i915 cgroup integration

== Series Details == Series: DRM/i915 cgroup integration URL : https://patchwork.freedesktop.org/series/39489/ State : failure == Summary == Possible new issues: Test kms_draw_crc: Subgroup draw-method-rgb565-pwrite-untiled: pass -> DMESG-WARN (shard-hsw)

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote: > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote: > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com > > > wrote: > >

[Intel-gfx] ✓ Fi.CI.IGT: 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 == Possible new issues: Test kms_busy: Subgroup extended-modeset-hang-newfb-render-b: dmesg-warn ->

Re: [Intel-gfx] [PATCH 2/5] drm/i915/psr: Use more PSR HW tracking.

On Fri, 2018-02-16 at 08:54 +, Chris Wilson wrote: > Quoting Dhinakaran Pandiyan (2018-02-16 04:33:19) > > From: Rodrigo Vivi > > > > So far we are using frontbuffer tracking for everything > > and ignoring that PSR has a HW capable HW tracking for many > > modern

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

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 URL : https://patchwork.freedesktop.org/series/39408/ State : failure == Summary == Possible new issues: Test gem_exec_create: Subgroup madvise: pass -> INCOMPLETE (shard-snb) Test kms_busy:

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Improve PSR activation timing

On Tue, 2018-02-27 at 16:14 -0800, Rodrigo Vivi wrote: > From: Andy Lutomirski > > The current PSR code has a two call sites that each schedule delayed > work to activate PSR. As far as I can tell, each call site intends > to keep PSR inactive for the given amount of time

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

== Series Details == Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating URL : https://patchwork.freedesktop.org/series/39410/ State : warning == Summary == Possible new issues: Test kms_busy: Subgroup extended-modeset-hang-newfb-render-b: dmesg-warn

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

== Series Details == Series: series starting with [v2,1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display URL : https://patchwork.freedesktop.org/series/39502/ State : success == Summary == Series 39502v1 series starting with [v2,1/3] drm/i915/frontbuffer: Pull

[Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor plane MMIOs are written to. But this flush should not be necessary for PSR as hardware tracking triggers PSR exit when MMIOs are written. As for FBC, the spec says "Flips or changes to plane size and panning" cause FBC to be

[Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

From: "Pandiyan, Dhinakaran" i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to DIRTYFB. The callers however are at a vantage point to decide if hardware frontbuffer tracking can do the flush for us. For example, legacy cursor updates, like

[Intel-gfx] [PATCH v2 3/3] drm/i915/psr: Use more PSR HW tracking.

From: Rodrigo Vivi So far we are using frontbuffer tracking for everything and ignoring that PSR has a HW capable HW tracking for many modern usages of GPU on Core platforms and newer Atom ones. One reason for that is that we were trying to keep same infrastructure in

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

== Series Details == Series: series starting with [v2,1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display URL : https://patchwork.freedesktop.org/series/39502/ State : success == Summary == Known issues: Test kms_chv_cursor_fail: Subgroup

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote: > > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote: > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote: > > > From: Matt Atwood > > > > > >

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote: > On 2018-03-06 07:18 AM, Ville Syrjälä wrote: > > On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote: > >> On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote: > >>> From: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm: Reject replacing property enum values

== Series Details == Series: series starting with [1/6] drm: Reject replacing property enum values URL : https://patchwork.freedesktop.org/series/39465/ State : success == Summary == Series 39465v1 series starting with [1/6] drm: Reject replacing property enum values

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

Quoting Michal Wajdeczko (2018-03-06 16:15:26) > Header intel_ringbuffer.h is using definitions from i915_reg.h > but forget to include it. Remove this hidden dependency by > explicitly include missing header. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/guc: Removed unused GuC parameters. (rev3)

== Series Details == Series: drm/i915/guc: Removed unused GuC parameters. (rev3) URL : https://patchwork.freedesktop.org/series/39154/ State : warning == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: pass ->

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

On 06/03/2018 17:33, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-03-06 16:15:26) Header intel_ringbuffer.h is using definitions from i915_reg.h but forget to include it. Remove this hidden dependency by explicitly include missing header. Signed-off-by: Michal Wajdeczko

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

== Series Details == Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating URL : https://patchwork.freedesktop.org/series/39410/ State : failure == Summary == Possible new issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE

Re: [Intel-gfx] [RFC][PATCH 10/11] drm: Fix debugfs edid_override locking

On Tue, Feb 27, 2018 at 02:56:59PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The edid is protected by mode_config.mutex. Grab the lock when frobbing > the debugfs edid_override thing. > > Cc: Keith Packard > Cc: Daniel Vetter

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

On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote: > 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

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

On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote: > 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

Re: [Intel-gfx] [RFC v3 11/12] drm/client: Add bootsplash client

On Thu, Feb 22, 2018 at 09:06:52PM +0100, Noralf Trønnes wrote: > Just a hack to test the client API. > > Signed-off-by: Noralf Trønnes Adding the suse folks who submitted the bootsplash a while ago, would be great if they could pick this up and run with it. > --- >

Re: [Intel-gfx] [PATCH 10/15] drm/i915/guc: Get rid of GuC log runtime

I think keeping the distinction between base/mandatory members and runtime/optional members is okay as they are handled differently. What do others think? another related query, should we alloc/dealloc guc_log work queue in relay_open/release? On 2/27/2018 6:22 PM, Michał Winiarski wrote:

Re: [Intel-gfx] [RFC][PATCH 06/11] drm/edid: Don't call drm_add_display_info() with an invalid EDID

On Tue, Feb 27, 2018 at 02:56:55PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_mode_connector_update_edid_property() will call > drm_add_display_info() if an invalid edid is passed in. > This differs from the behaviour of drm_add_edid_modes() which >

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

Quoting Michal Wajdeczko (2018-03-06 09:48:14) > On Mon, 05 Mar 2018 23:21:21 +0100, Daniele Ceraolo Spurio > > static __always_inline void dup_param(const char *type, void *x) > > @@ -1749,13 +1744,12 @@ static int capture(void *data) > > capture_params(error); > >

[Intel-gfx] ✓ Fi.CI.IGT: 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 == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-c-256x256-bottom-edge:

Re: [Intel-gfx] [PATCH 1/3] drm: Don't create properties without names

On Fri, Mar 02, 2018 at 03:25:42PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Creating a property that doesn't have a name makes no sense to me. Don't > allow it. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel

Re: [Intel-gfx] [PATCH v2 2/3 drm: Check property/enum name length

On Fri, Mar 02, 2018 at 04:03:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Reject requests to add properties/enums with an overly long name. > Previously we would have just silently truncated the string and exposed > it userspace. > > v2:

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

Op 05-03-18 om 19:50 schreef Rodrigo Vivi: > 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

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

Quoting Chris Wilson (2018-03-06 10:41:41) > static void *thread(void *arg) > { > + static const char acquire_error[] = "acquire"; > + static const char release_error[] = "release"; > + > struct thread *t = arg; > - uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio

[Intel-gfx] [PATCH igt 2/2] igt: Remoe gen7_forcewake_mt

Having demonstrated that FORCEWAKE_MT is suspect to the same old concurrent mmio access bug that stalks gen7, we have shown that it is not viable for userspace to poke around inside FORCEWAKE_MT directly. As it can not work correctly, remove the test. Signed-off-by: Chris Wilson

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

Re: [Intel-gfx] [PATCH 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

On 2/27/2018 6:22 PM, Michał Winiarski wrote: If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter reason for this? I think this was needed for verifying log flushes. and tidy the debugfs

Re: [Intel-gfx] [RFC][PATCH 07/11] drm/probe-helper: Avoid iterating the list twice on ww backoff

On Tue, Feb 27, 2018 at 02:56:56PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > If we have to backoff there's no point in going over the mode list again > to mark all the modes as stale. We can defer that until we're ready to > refresh the mode list.

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

On Mon, 05 Mar 2018 23:21:21 +0100, 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

Re: [Intel-gfx] [RFC][PATCH 09/11] drm: Fix getconnector locking

On Tue, Feb 27, 2018 at 02:56:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The edid is protected by mode_config.mutex so extend the locking to > protect the property readout part as well. > > Cc: Keith Packard > Cc: Daniel Vetter

[Intel-gfx] [PATCH] drm/i915/icl: do not save DDI A/E sharing bit for ICL

We don't want to preserve the DDI A 4 lane bit on ICL. Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing limitation.") Cc: Mahesh Kumar Cc: Paulo Zanoni Signed-off-by: Jani Nikula ---

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel-gpu-overlay: Update for renamed tracepoints

Quoting Tvrtko Ursulin (2018-03-05 12:41:58) > From: Tvrtko Ursulin > > Request tracepoints have been renames so update the tool to be able to > find them. > > Also support falling back to the old name for compatibility. > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

On Tue, Feb 27, 2018 at 02:56:53PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new

Re: [Intel-gfx] [RFC][PATCH 05/11] drm/edid: Clear display info fully

On Tue, Mar 06, 2018 at 10:33:31AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:56:54PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Now that we have split the display info into static and dynamic parts, > > we can just zero out the

Re: [Intel-gfx] [RFC][PATCH 05/11] drm/edid: Clear display info fully

On Tue, Mar 06, 2018 at 10:33:31AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:56:54PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Now that we have split the display info into static and dynamic parts, > > we can just zero out the

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

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > edid and display_info are protected by mode_config.mutex. Add lockdep > asserts to make sure we're not accessing things w/o the lock. > > FIXME: pretty sure this will blow up

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

Quoting Tvrtko Ursulin (2018-03-06 09:37:50) > > On 05/03/2018 17:30, Chris Wilson wrote: > > -static void *igfx_get_mmio(void) > > +static volatile uint32_t *igfx_mmio_forcewake_mt(void) > > I think its overkill to bother with volatile all throughout the chain, > it's not like it's const. But

  1   2   >