[Intel-gfx] [RFC i-g-t] tests/gem_exec_basic: Documentation for subtests

This is an RFC for adding documentation to IGT subtests. Each subtest can have something similar to a WHAT - explaining what the subtest actually does, and a WHY - which explains a use case, if applicable. Additionally, include comments for anything in the subtest code which can help explain HOW

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init (rev2)

== Series Details == Series: drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init (rev2) URL : https://patchwork.freedesktop.org/series/28507/ State : success == Summary == Series 28507v2 drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

On 9 August 2017 at 09:42, Joe Kniss wrote: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle()

Re: [Intel-gfx] [PATCH v2 14/16] drm/i915/guc: Enable GuC interrupts when using CT

On 08/07/2017 09:14 AM, Michal Wajdeczko wrote: We will need them in G2H communication to properly handle responses and requests from the Guc. Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Daniele Ceraolo Spurio

[Intel-gfx] [PATCH i-g-t] igt: add syncobj_basic.

From: Dave Airlie Some basic sync object interface tests Signed-off-by: Dave Airlie --- tests/Makefile.sources | 1 + tests/syncobj_basic.c | 260 + 2 files changed, 261 insertions(+) create mode

Re: [Intel-gfx] [PATCH i-g-t] igt: add syncobj_basic.

A bunch of these tests assume that the handle is looked up after the other parameters are checked. Other than that, looks good. Reviewed-by: Jason Ekstrand On Tue, Aug 8, 2017 at 4:09 PM, Dave Airlie wrote: > From: Dave Airlie > >

[Intel-gfx] [PATCH v2] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

Bit 29 of SRD_CTL needs to have its value preserved according to the B-Spec, so right before we write out the register we go ahead and read the register and preserve the value of that bit before we write out the configured register value. v2: Spaces => tabs, minor name change, and commit message

Re: [Intel-gfx] [PATCH] drm/i915: Clear lost context-switch interrupts across reset

> -Original Message- > From: Thierry, Michel > Sent: Tuesday, August 8, 2017 1:40 AM > To: Chris Wilson ; intel-gfx@lists.freedesktop.org > Cc: Dong, Chuanxiao ; Ursulin, Tvrtko > ; Winiarski, Michal

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_exec_basic: Documentation for subtests

== Series Details == Series: tests/gem_exec_basic: Documentation for subtests URL : https://patchwork.freedesktop.org/series/28524/ State : success == Summary == IGT patchset tested on top of latest successful build 27ff12f00c94a5363f581a4353f08bfde62c59c4 lib: Remove illegal instructions

Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

I didn't mean to add libdrm, sorry, there is a separate change for that. I'll double check and test the drivers that don't implement the virtual. Thanks for the quick reply! -j On Tue, Aug 8, 2017 at 4:50 PM, Dave Airlie wrote: > On 9 August 2017 at 09:42, Joe Kniss

Re: [Intel-gfx] [PATCH i-g-t] tests/kms: increase max threshold time for edid read

On 08/08/2017 12:51 AM, Lofstedt, Marta wrote: Thanks Clinton! If you add: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100047 You have my Rb. /Marta Thanks Marta, However I'm going to extend the functionality to read the EDID block size like Daniel suggested. During testing

Re: [Intel-gfx] [PATCH] drm/i915: add register macro definition style guide

On Mon, 07 Aug 2017, Daniel Vetter wrote: > On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote: >> This is not to try to force a new style; this is my interpretation of >> what the most common existing style is. >> >> With hopes I don't need to answer so many questions

Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb

On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-07 17:26:56) >> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: >> > Quoting Daniel Vetter (2017-08-04 17:07:22) >> > > We now have full (or a lot at least) igt running in

Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb

Quoting Daniel Vetter (2017-08-08 10:01:59) > On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-08-07 17:26:56) > >> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: > >> > Quoting Daniel Vetter (2017-08-04 17:07:22) > >> >

Re: [Intel-gfx] [PATCH i-g-t] tests/kms: increase max threshold time for edid read

Thanks Clinton! If you add: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100047 You have my Rb. /Marta > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of clinton.a.tay...@intel.com > Sent: Friday, August 4, 2017 9:23 PM > To:

Re: [Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

On 8/7/2017 11:13 PM, Alex Williamson wrote: > On Mon, 7 Aug 2017 08:11:43 + > "Zhang, Tina" wrote: > >> After going through the previous discussions, here are some summaries may be >> related to the current discussion: >> 1. How does user mode figure the device

[Intel-gfx] [PATCH] dim: Fix the broken rerere changes

I screwed up: - a '/' at the end makes readlink follow the link before testing it. - only delete everything when it's not a symlink. Cc: Jani Nikula Acked-by: Jani Nikula Signed-off-by: Daniel Vetter --- dim |

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_kms: Remove vblank wait after plane update.

On Mon, 2017-08-07 at 10:42 +0200, Maarten Lankhorst wrote: > Op 04-08-17 om 10:07 schreef Mika Kahola: > > > > On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote: > > > > > > With the conversion to atomic, this is already handled in the > > > core. > > > > > > Signed-off-by: Maarten

[Intel-gfx] [PATCH 2/3] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

Blocking in a worker is ok, that's what the unbound_wq is for. And it unifies the paths between the blocking and nonblocking commit, giving me just one path where I have to implement the deadlock avoidance trickery in the next patch. I first tried to implement the following patch without this

[Intel-gfx] [PATCH 1/3] drm/i915: Avoid the gpu reset vs. modeset deadlock

... using the biggest hammer we have. This is essentially a weaponized version of the timeout-based wedging Chris added in commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 Author: Chris Wilson Date: Thu Jun 22 11:56:25 2017 +0100 drm/i915: Break modeset deadlocks

Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb

On Tue, Aug 8, 2017 at 11:25 AM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-08 10:01:59) >> On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson >> wrote: >> > Quoting Daniel Vetter (2017-08-07 17:26:56) >> >> On Fri, Aug 04, 2017 at

[Intel-gfx] [PATCH 3/3] drm/i915: More surgically unbreak the modeset vs reset deadlock

There's no reason to entirely wedge the gpu, for the minimal deadlock bugfix we only need to unbreak/decouple the atomic commit from the gpu reset. The simplest way to fix that is by replacing the unconditional fence wait a the top of commit_tail by a wait which completes either when the fences

Re: [Intel-gfx] [PATCH] drm/i915: add register macro definition style guide

On Mon, 07 Aug 2017, Rodrigo Vivi wrote: > good idea. > > > On Mon, Aug 7, 2017 at 9:10 AM, Daniel Vetter wrote: >> On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote: >> >>> + * >>> + * For bit fields, define a _MASK and a _SHIFT macro. Define

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Convert gen4- watermarks to atomic. (rev2)

Op 07-08-17 om 14:17 schreef Patchwork: > == Series Details == > > Series: drm/i915: Convert gen4- watermarks to atomic. (rev2) > URL : https://patchwork.freedesktop.org/series/23954/ > State : failure > > == Summary == > > Series 23954v2 drm/i915: Convert gen4- watermarks to atomic. >

Re: [Intel-gfx] [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr

On 13/07/17 05:27 PM, Michel Dänzer wrote: > On 18/04/17 07:07 PM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Signed-off-by: Michel Dänzer >> --- >> >> Chris / Ilia / Ben, this should be manageable for the intel/nouveau >> drivers, right? >

Re: [Intel-gfx] [PATCH 01/21] mm/shmem: introduce shmem_file_setup_with_mnt

Hi Hugh, Could we get this patch merged? Or would you prefer us to merge through drm-tip? For what it's worth, this is: Reviewed-by: Joonas Lahtinen Regards, Joonas On pe, 2017-07-28 at 16:12 +0300, Kirill A. Shutemov wrote: > On Tue, Jul 25, 2017 at

Re: [Intel-gfx] [PATCH igt 1/2] lib: Add hooks for enabling ftrace

Quoting Petri Latvala (2017-08-08 13:54:46) > On Tue, Aug 08, 2017 at 12:27:11PM +0100, Chris Wilson wrote: > > *snip* > > > +#define BIT(x) (1ul << (x)) > > + > > +/* Only a single tracer in the kernel, so we can use a singleton */ > > +struct igt_ftrace { > > + int dir; > > + > > +

Re: [Intel-gfx] [PATCH igt 1/2] lib: Add hooks for enabling ftrace

On Tue, Aug 08, 2017 at 12:27:11PM +0100, Chris Wilson wrote: *snip* > +#define BIT(x) (1ul << (x)) > + > +/* Only a single tracer in the kernel, so we can use a singleton */ > +struct igt_ftrace { > + int dir; > + > + unsigned long flags; > +#define PID_SET BIT(0) > +#define INCLUDE_SET

[Intel-gfx] [PATCH] drm/i915: Allow HW status page to be bound high

At the time of commit 1f767e02d69f ("drm/i915: HWS must be in the mappable region for g33"), drm_mm insertion would often default to placing a new object high in the zone forcing us to specify that certain HWSP must be bound within the low mappable region. Since then, drm_mm has gained more

[Intel-gfx] [PATCH v3 15/16] drm/i915/guc: Trace messages from CT while in debug

During debug we may want to investigate all communication from the Guc. Add proper tracing macros in debug config. v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal) v3: use dedicated Kconfig (Daniele) Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo

Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

Hi Daniel, Thank you for the patch. On Tuesday 25 Jul 2017 10:01:19 Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. I assume you meant drm_atomic_plane_set_property. With that fixed,

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Calculate gen3- watermarks semi-atomically.

Hi, On Monday 07 August 2017 04:18 PM, Maarten Lankhorst wrote: The gen3 watermark calculations are converted to atomic, but the wm update calls are still done through the legacy functions. This will make it easier to bisect things if they go wrong. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Use drm_open_driver, don't need drm master

On Mon, Aug 07, 2017 at 03:23:29PM +0300, Petri Latvala wrote: > Signed-off-by: Petri Latvala Reviewed-by: Arkadiusz Hiler -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.

DDI_E is not supported on CNL-U and CNL-Y When adding the inital support we noticed DDI_E wasn't supported and removed it on v4 and v5 of that patch. However for some reason I missed or put back these 2 chunks. Time to clean it up to avoid later confusion. Fixes: 8bcd3dd41766 ("drm/i915/cnl:

Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Use drm_open_driver, don't need drm master

On 08/08/2017 12:55 PM, Arkadiusz Hiler wrote: On Mon, Aug 07, 2017 at 03:23:29PM +0300, Petri Latvala wrote: Signed-off-by: Petri Latvala Reviewed-by: Arkadiusz Hiler Thanks, pushed. -- Petri Latvala

[Intel-gfx] [PATCH] drm/i915: Calculate gen3- watermarks semi-atomically, v2.

The gen3 watermark calculations are converted to atomic, but the wm update calls are still done through the legacy functions. This will make it easier to bisect things if they go wrong. CI was having issues on the kms_cursor_legacy tests with too much debug info printed out, in order to reduce

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add has_psr-flag to gen9lp

== Series Details == Series: drm/i915: Add has_psr-flag to gen9lp URL : https://patchwork.freedesktop.org/series/28488/ State : failure == Summary == Series 28488v1 drm/i915: Add has_psr-flag to gen9lp https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Convert gen4- watermarks to atomic. (rev3)

== Series Details == Series: drm/i915: Convert gen4- watermarks to atomic. (rev3) URL : https://patchwork.freedesktop.org/series/23954/ State : failure == Summary == Series 23954v3 drm/i915: Convert gen4- watermarks to atomic.

Re: [Intel-gfx] [PATCH 3/3] drm/etnaviv: add thermal dependency

Hi Arnd, Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann: > When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is > built-in, we get a link error: > > drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': >

Re: [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_connector_set_property. > > The only special case is nouveau which used one function for both > pre-nv50 legacy modeset code and post-nv50

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2:

[Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp

While testing Jim Bride's latest batch of PSR patches I noticed that gen9lp doesn't include the has_psr flag, and that our GLK system thus reported PSR as unsupported. This patch simply adds has_psr. Signed-off-by: David Weinehall ---

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s

> -Original Message- > From: Zanoni, Paulo R > Sent: Monday, August 7, 2017 5:54 PM > To: Lofstedt, Marta ; intel- > g...@lists.freedesktop.org > Cc: Latvala, Petri > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase

[Intel-gfx] [PATCH igt 1/2] lib: Add hooks for enabling ftrace

If the kernel has tracing support builtin, we can enable around troublesome tests to obtain greater detail from the kernel that may prove invaluable in debugging the problem. Signed-off-by: Chris Wilson --- lib/Makefile.sources | 2 + lib/igt_core.c | 5 ++

[Intel-gfx] [PATCH igt 2/2] lib: Enable automatic ftrace dumping for suspend failures

Supplement dmesg with the function call graph to try and help identify why the suspend failed. On the other hand, it may be very noisy and perturb the system due to its overhead... Signed-off-by: Chris Wilson --- lib/igt_aux.c | 15 +++ 1 file changed, 11

Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_cursor.c|

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add has_psr-flag to gen9lp

On Tue, Aug 08, 2017 at 10:34:46AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add has_psr-flag to gen9lp > URL : https://patchwork.freedesktop.org/series/28488/ > State : failure > > == Summary == > > Series 28488v1 drm/i915: Add has_psr-flag to gen9lp >

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.

On Thu, Aug 03, 2017 at 03:51:37PM -0700, Rodrigo Vivi wrote: > DDI_E is not supported on CNL-U and CNL-Y > > When adding the inital support we noticed DDI_E wasn't supported > and removed it on v4 and v5 of that patch. > However for some reason I missed or put back these 2 chunks. > > Time to

[Intel-gfx] [PATCH igt] tools/null_state_gen: Don't upload color calc and depth stencil on gen6

We were pointing the color calc and depth stencil states blindly to an offset of 1k from bb start. This was foolhardy as it collides with other state in the batch and results in a wrecked state upload. Chris noticed that with snb gt1, it takes 10 seconds for renderstate batch to complete. However

Re: [Intel-gfx] [PATCH] drm/i915/renderstate: Sandybridge golden renderstate is b0rked

Chris Wilson writes: > In the null state batch, we try to load the CC_STATE_POINTERS, but pass > in a pointer to invalid state for the color-calc and depth-stencil > state. In the rendercopy batch this was imported from, the 1024 offset > used is known to be 64bytes of

Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate

Chris Wilson writes: > As we may have just bound the renderstate into the GGTT for execution, we > need to ensure that the GTT TLB are also flushed. > > On snb-gt2, this would cause a random GPU hang at the start of a new > context (e.g. boot) and on snb-gt1, it was

Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate

Mika Kuoppala writes: > Mika Kuoppala writes: > >> Chris Wilson writes: >> >>> As we may have just bound the renderstate into the GGTT for execution, we >>> need to ensure that the GTT TLB are also flushed.

[Intel-gfx] [PATCH 6/6] drm/i915/cnl: Fix DP max voltage

On clock recovery this function is called to find out the max voltage swing level that we could go. However gen 9 functions use the old buffer translation tables to figure that out. That table is not valid for CNL causing an invalid number of entries and an invalid selection on the max voltage

[Intel-gfx] [PATCH 4/6] drm/i915/cnl: Move ddi buf trans related functions up.

No functional changes. But those functions will be needed to get max level for HDMI and DP, so let's move those up closer to other similar functions existent for previous platforms. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_ddi.c | 122

[Intel-gfx] [PATCH 1/6] drm/i915: Introduce intel_ddi_dp_level.

No functional changes. This only moves the DP level selection to a separated function that will be later used to organize better the vswing sequences. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_ddi.c | 16 ++-- 1 file changed, 10

[Intel-gfx] [PATCH 5/6] drm/i915/cnl: Fix DDI hdmi level selection.

Let's get a proper HDMI DDI entry level for vswing programming sequences on CNL. Spec doesn't specify any default for HDMI tables, so let's pick the last entry as the default for now. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_ddi.c | 5 - 1 file

[Intel-gfx] [PATCH 2/6] drm/i915: Align vswing sequences with old ddi buffer registers.

Vswing sequences on BXT and CNL are equivalent to the ddi buffer registers setting on other platforms. For some reason it got aligned with skl_ddi_set_iboost what is semantically incorrect. This forced us to keep skipping ddi buffer translation tables on the platforms that has the vswing

Re: [Intel-gfx] [PATCH igt] tools/null_state_gen: Don't upload color calc and depth stencil on gen6

Mika Kuoppala writes: > We were pointing the color calc and depth stencil states blindly > to an offset of 1k from bb start. This was foolhardy as it collides > with other state in the batch and results in a wrecked state upload. > > Chris noticed that with snb

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Perform an invalidate prior to executing golden renderstate

== Series Details == Series: drm/i915: Perform an invalidate prior to executing golden renderstate URL : https://patchwork.freedesktop.org/series/28497/ State : success == Summary == Series 28497v1 drm/i915: Perform an invalidate prior to executing golden renderstate

Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate

Quoting Mika Kuoppala (2017-08-08 14:36:39) > Chris Wilson writes: > > > As we may have just bound the renderstate into the GGTT for execution, we > > need to ensure that the GTT TLB are also flushed. > > > > On snb-gt2, this would cause a random GPU hang at the start

Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate

Quoting Mika Kuoppala (2017-08-08 14:36:39) > Chris Wilson writes: > > > As we may have just bound the renderstate into the GGTT for execution, we > > need to ensure that the GTT TLB are also flushed. > > > > On snb-gt2, this would cause a random GPU hang at the start

Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

On 4 August 2017 at 12:20, Lionel Landwerlin wrote: > From: Robert Bragg > > Signed-off-by: Robert Bragg > Signed-off-by: Lionel Landwerlin > --- > tests/perf.c | 806 >

[Intel-gfx] [PATCH 3/6] drm/i915/cnl: Move voltage check into ddi buf trans functions.

Let's start converging CNL buf translations to same style used on previous platforms. So first thing is to use the standard signature so we don't need to propagate the voltage check into other parts of the code, but only on the parts that it is really useful. Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate

As we may have just bound the renderstate into the GGTT for execution, we need to ensure that the GTT TLB are also flushed. On snb-gt2, this would cause a random GPU hang at the start of a new context (e.g. boot) and on snb-gt1, it was causing the renderstate batch to take ~10s. It was the GPU

Re: [Intel-gfx] [PATCH igt 2/2] lib: Remove illegal instructions from hang injection

On Mon, Aug 07, 2017 at 04:33:40PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > The idea behind using an illegal instruction was to hang the GPU must > > faster than simply using the recursive batch. However, we stopped doing > > so on gen8+ as the CS parser

Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate

Mika Kuoppala writes: > Chris Wilson writes: > >> As we may have just bound the renderstate into the GGTT for execution, we >> need to ensure that the GTT TLB are also flushed. >> >> On snb-gt2, this would cause a random GPU hang at the

Re: [Intel-gfx] [PATCH igt] tools/null_state_gen: Don't upload color calc and depth stencil on gen6

Quoting Mika Kuoppala (2017-08-08 14:36:59) > Mika Kuoppala writes: > > > We were pointing the color calc and depth stencil states blindly > > to an offset of 1k from bb start. This was foolhardy as it collides > > with other state in the batch and results in a

[Intel-gfx] ✓ Fi.CI.BAT: success for tools/null_state_gen: Don't upload color calc and depth stencil on gen6

== Series Details == Series: tools/null_state_gen: Don't upload color calc and depth stencil on gen6 URL : https://patchwork.freedesktop.org/series/28496/ State : success == Summary == IGT patchset tested on top of latest successful build eeff6a1d9c4e2c195b30ad95ee36a58ef6ca3387

Re: [Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

On Tue, 8 Aug 2017 14:18:07 +0530 Kirti Wankhede wrote: > On 8/7/2017 11:13 PM, Alex Williamson wrote: > > On Mon, 7 Aug 2017 08:11:43 + > > "Zhang, Tina" wrote: > > > >> After going through the previous discussions, here are some summaries may

Re: [Intel-gfx] [PATCH] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

On Tue, 2017-08-08 at 08:51 -0700, Jim Bride wrote: > Bit 29 of SRD_CTL needs to have its value preserved, probably good to kind of quote spec somehow: "This field is used for hardware communication. Software must not change this field." > so right before we > write out the register we go

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev3)

== Series Details == Series: drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev3) URL : https://patchwork.freedesktop.org/series/28341/ State : success == Summary == Series 28341v3 drm/i915/cnl: Removing missing DDI_E bits from CNL.

Re: [Intel-gfx] [PATCH] drm/i915/cnl: DDIA Lane capability bit not set in clone mode

we confirmed that with current supported CNL skus using IS_CANNONLAKE is enogh for now. So feel free to change that if and use Reviewed-by: Rodrigo Vivi on the v2 On Tue, Aug 1, 2017 at 1:23 PM, Vivi, Rodrigo wrote: > + Art, couple

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev2)

== Series Details == Series: drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev2) URL : https://patchwork.freedesktop.org/series/28341/ State : warning == Summary == Series 28341v2 drm/i915/cnl: Removing missing DDI_E bits from CNL.

[Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.

DDI_E is not supported on CNL-U and CNL-Y When adding the inital support we noticed DDI_E wasn't supported and removed it on v4 and v5 of that patch. However for some reason I missed or put back these 2 chunks. Time to clean it up to avoid later confusion. Fixes: 8bcd3dd41766 ("drm/i915/cnl:

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

Hi Dave, Here's the pull for the last week and a bit. It's rather large as I was on vacation/moving last week. Although the patch count/diffstat is higher than normal, we have a lot of medium-large sets included. That also explains why the summary might seem a bit light. Among the aforementioned

Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp

a long time ago I had agreed with Daniel that we would only add new platforms after it was enabled by default on previous platforms. a big reason for that is that we was willing to reduce the platforms to validate and do better validation one by one before enabling. However now I believe it would

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.

merged to dinq, thanks for the review. On Tue, Aug 8, 2017 at 4:36 AM, Imre Deak wrote: > On Thu, Aug 03, 2017 at 03:51:37PM -0700, Rodrigo Vivi wrote: >> DDI_E is not supported on CNL-U and CNL-Y >> >> When adding the inital support we noticed DDI_E wasn't supported >> and

Re: [Intel-gfx] [PATCH] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

On Tue, Aug 08, 2017 at 07:42:50PM +, Vivi, Rodrigo wrote: > On Tue, 2017-08-08 at 08:51 -0700, Jim Bride wrote: > > Bit 29 of SRD_CTL needs to have its value preserved, > > probably good to kind of quote spec somehow: > "This field is used for hardware communication. Software must not >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Introduce intel_ddi_dp_level.

== Series Details == Series: series starting with [1/6] drm/i915: Introduce intel_ddi_dp_level. URL : https://patchwork.freedesktop.org/series/28499/ State : success == Summary == Series 28499v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

Bit 29 of SRD_CTL needs to have its value preserved, so right before we write out the register we go ahead and read the register and preserve the value of that bit before we write out the configured register value. Cc: Rodrigo Vivi Cc: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] lib: Add hooks for enabling ftrace

== Series Details == Series: series starting with [1/2] lib: Add hooks for enabling ftrace URL : https://patchwork.freedesktop.org/series/28491/ State : failure == Summary == Making check in lib make[1]: Entering directory '/home/cidrm/intel-gpu-tools/lib' make check-recursive make[2]:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

== Series Details == Series: drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init URL : https://patchwork.freedesktop.org/series/28507/ State : success == Summary == Series 28507v1 drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init

[Intel-gfx] [PATCH i-g-t 8/8] tests/kms_ccs: Test CCS on sprite planes

Also try to test CCS on available non-primary planes. However, as there is not enough bandwidth to scan out both the primary and sprite planes when using CCS (or even Y-tiled), fall back to linear for the primary plane when using CCS for a sprite/cursor plane. Signed-off-by: Daniel Stone

[Intel-gfx] [PATCH i-g-t 3/8] tests/kms_ccs: Remove excessive FB alignment

We don't need to align the framebuffer dimensions to the tile size. As long as the pitch is aligned to the tile width, and the BO dimensions can fit full tiles of both aligned pitch and aligned height, we don't need to claim the FB itself is larger. Signed-off-by: Daniel Stone

[Intel-gfx] [PATCH i-g-t 4/8] tests/kms_ccs: Paramaterize color for framebuffer

Will be used in later patches. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c index c02a0433..50bb2ad6 100644 --- a/tests/kms_ccs.c +++ b/tests/kms_ccs.c @@

[Intel-gfx] [PATCH i-g-t 2/8] tests/kms_ccs: Split FB generation into helper

Create a new helper for generating and rendering the framebuffer, rather than doing it inline with applying the configuration. This will be used later to generate a different plane configuration. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 73

[Intel-gfx] [PATCH i-g-t 1/8] tests/kms_ccs: Convert int/bool to enum

Rather than using TEST_UNCOMPRESSED / TEST_COMPRESSED as alternately either an int or a bool, change it to a bitfield enum. This will let us add more parameters later to control framebuffer generation. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 29

[Intel-gfx] [PATCH i-g-t 5/8] tests/kms_ccs: Reshuffle test name and loop

In preparation for also testing sprites. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c index 50bb2ad6..1a5cdcd4 100644 --- a/tests/kms_ccs.c +++

[Intel-gfx] [PATCH i-g-t 6/8] tests/kms_ccs: Test for supported modifier

Make sure the CCS modifier is supported on our plane, before we try to use it on that plane. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 117 +++- 1 file changed, 116 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH i-g-t 7/8] tests/kms_ccs: Split all tests into subtests

Some subtests were magically doing a for-each-pipe loop. Remove that, and have all multi-pipe tests actually work across all pipes. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 62 +++-- 1 file changed, 20

Re: [Intel-gfx] [PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers

Hi, On 3 August 2017 at 12:00, Daniel Stone wrote: > On 1 August 2017 at 17:58, Ben Widawsky wrote: >> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private >> *dev_priv, >> plane_formats = skl_plane_formats; >>