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

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

On Tue, 06 Mar 2018, Paulo Zanoni wrote: > Em Ter, 2018-03-06 às 12:41 +0200, Jani Nikula escreveu: >> We don't want to preserve the DDI A 4 lane bit on ICL. >> > > Why not review https://patchwork.freedesktop.org/patch/206118/ instead? > :) Because Mahesh posted his

[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

[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 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.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

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:

[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 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] [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] ✓ 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] 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: 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

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 > > > > > >

[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.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, 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] 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.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

[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()

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

[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] [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 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 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 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

[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 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] [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

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

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

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/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] 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 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

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.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 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

[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.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:

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,

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 > > >

[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

[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 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. > >

[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] [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

[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 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:

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

[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] 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/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] [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] ✗ 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: >

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] [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] ✗ 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

[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] [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 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

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] [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 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 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ä

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:

[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

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.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] [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] [PATCH 5/6] drm: Make property flags u32

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ä --- drivers/gpu/drm/drm_property.c | 41

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

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 from the protocol spec: "If 'pending' is TRUE, changes made to property values

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

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 we're now chekcing for more than the type let's also change the function name

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

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ä --- drivers/gpu/drm/drm_property.c | 4 ++-- 1 file changed, 2 insertions(+), 2

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

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ä --- drivers/gpu/drm/drm_property.c | 4 ++--

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

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: Daniel Vetter Suggested-by: Daniel Vetter

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

On 06/03/2018 16:15, Michal Wajdeczko wrote: 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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make header i915_pmu.h more robust

On 06/03/2018 16:15, Michal Wajdeczko wrote: Definitions in i915_pmu.h header depend on other types and declarations that were not explicitly included. Fix that by adding related headers and forward declarations. Oopsie. While here, change license text to SPDX format. Signed-off-by: Michal

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

On Tue, 06 Mar 2018 17:20:18 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-03-06 16:15:25) Function i915_gem_batch_pool_init() failed to follow obj-verb naming schema. Fix that by swapping function parameters. While here, change license text to SPDX

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

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ä >>> >>> edid and display_info are protected by mode_config.mutex.

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

Quoting Michal Wajdeczko (2018-03-06 16:15:25) > Function i915_gem_batch_pool_init() failed to follow obj-verb > naming schema. Fix that by swapping function parameters. > While here, change license text to SPDX format. > > Signed-off-by: Michal Wajdeczko > Cc: Chris

[Intel-gfx] [PATCH 4/4] drm/i915: Move i915_gpu_error into its own header

Error state management code was moved into separate .c unit but we didn't move related definitions into own header. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 330

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

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 Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 1/4] drm/i915: Make header i915_pmu.h more robust

Definitions in i915_pmu.h header depend on other types and declarations that were not explicitly included. Fix that by adding related headers and forward declarations. While here, change license text to SPDX format. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson

[Intel-gfx] [PATCH 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

Function i915_gem_batch_pool_init() failed to follow obj-verb naming schema. Fix that by swapping function parameters. While here, change license text to SPDX format. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson ---

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

On 2018-03-06 05:35 AM, Daniel Vetter wrote: > 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,

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

Hi, On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote: > 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

[Intel-gfx] ✓ Fi.CI.BAT: success 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 : success == Summary == Series 39454v2 drm/i915: Disable pipe CRC before disabling the pipe.

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

On 6 March 2018 at 13:54, Ville Syrjälä wrote: > On Tue, Mar 06, 2018 at 01:35:11PM +, Emil Velikov wrote: >> Hi Ville, >> >> On 2 March 2018 at 13:25, Ville Syrjala >> wrote: >> > From: Ville Syrjälä

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

On 2018-03-06 02:51 AM, Daniel Vetter wrote: > 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 >>>

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

Thanks for CCing! I like the idea of this patchset. As far as I understand, this multiplexing is exactly what I would have had to write in order to port the bootsplash to DRM. And we finally get rid of the driver-specific FB emulation hacks, too. Good riddance. Thanks for the initiative,

[Intel-gfx] [PATCH] drm/i915: Disable pipe CRC before disabling the pipe.

[ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound

On Tue, 2018-03-06 at 13:01 +, Chris Wilson wrote: > Since commit fd10e2ce9905 ("drm/i915/breadcrumbs: Ignore unsubmitted > signalers"), we cancel the signaler when retiring the request and so > upon wraparound, where we wait for all requests to be retired, we no > longer need to spin waiting

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush waiters on seqno wraparound

On Tue, 2018-03-06 at 13:01 +, Chris Wilson wrote: > Previously, we would spin waiting for all waiters to wake up and notice > their request had completed before we would reset the seqno upon > wraparound. However, we can mark their waits as complete and wake them > up directly using the

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/icl: do not save DDI A/E sharing bit for ICL

== Series Details == Series: drm/i915/icl: do not save DDI A/E sharing bit for ICL URL : https://patchwork.freedesktop.org/series/39439/ State : warning == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-c-64x64-top-edge: pass ->

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

On Tue, Feb 20, 2018 at 04:31:40PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2018-02-20 15:44:38) > > On Tue, Feb 20, 2018 at 02:33:08PM +, Chris Wilson wrote: > > > PSR may not exit instantaneously, so while asserting that PSR is > > > disabled after an action, we may have to wait a

  1   2   >