Re: [Intel-gfx] [PATCH I-G-T 1/2] igt/kms_pipe_crc_basic: Print pipe name when skipping

The series is Reviewed-by: Petri Latvala On Tue, Jun 20, 2017 at 01:11:27AM -0300, Gabriel Krisman Bertazi wrote: > Signed-off-by: Gabriel Krisman Bertazi > --- > tests/kms_pipe_crc_basic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/kms_pipe_crc_basic.c

Re: [Intel-gfx] [PATCH] [RFC] drm/i915/skl+: enable PF_ID interlace mode in SKL

Hi, On Monday 19 June 2017 06:35 PM, Ville Syrjälä wrote: On Mon, Jun 19, 2017 at 05:50:28PM +0530, Mahesh Kumar wrote: Hi Ville, Thanks for review On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote: On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote: In previous GEN default I

Re: [Intel-gfx] [Bug Report] Weekly progress report WW24

I like this new report. Thank you Elizabeth and whoever has been working with you in order to make this happen. BR, Jari From: De La Torre Mena, ElizabethX Sent: Monday, June 19, 2017 5:48 PM To: intel-gfx@lists.freedesktop.org; linux-...@eclists.intel.com; otc gfx qa ; Parenteau, Paul A ; Gi

Re: [Intel-gfx] [PATCH 10/37] drm/doc: vblank cleanup

On Thu, Jun 15, 2017 at 02:58:15PM +0200, Thierry Reding wrote: > On Wed, May 24, 2017 at 04:51:45PM +0200, Daniel Vetter wrote: > [...] > > -Resources allocated by :c:func:`drm_vblank_init()` must be freed > > -with a call to :c:func:`drm_vblank_cleanup()` in the driver unload > > -operation handl

Re: [Intel-gfx] [PATCH 30/37] drm/sti: Drop drm_vblank_cleanup

On Thu, Jun 01, 2017 at 03:37:33PM +, Vincent ABRIOU wrote: > > > On 05/24/2017 04:52 PM, Daniel Vetter wrote: > > Seems entirely cargo-culted. > > > > Cc: Benjamin Gaignard > > Cc: Vincent Abriou > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/sti/sti_drv.c | 1 - > > 1 f

Re: [Intel-gfx] [PATCH 33/37] drm/tegra: Drop drm_vblank_cleanup

On Thu, Jun 15, 2017 at 03:00:08PM +0200, Thierry Reding wrote: > On Wed, May 24, 2017 at 04:52:08PM +0200, Daniel Vetter wrote: > > Again, doesn't seem to serve a purpose. > > > > Cc: Thierry Reding > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/tegra/drm.c | 5 + > > 1 file

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Hi, > > Hmm, plane isn't really an ID, it is a type, with type being either > > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think > > the > > flage above make sense. > > The intention was that ..._REGION_ID and ...PLANE_ID are describing > what the vfio_device_query_gfx_plane.id

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Hi, Thanks for all the comments. Here are the summaries: 1. Modify the structures to make it more general. struct vfio_device_gfx_plane_info { __u64 start; __u64 drm_format_mod; __u32 drm_format; __u32 width; __u32 height; __u32 stride; __u3

[Intel-gfx] [PATCH i-g-t] igt/meta_test: Add a warn subtest to make sure warnings are caught as expected.

Cc: Marta Löfstedt Cc: Petri Latvala Signed-off-by: Maarten Lankhorst --- tests/intel-ci/meta.testlist | 1 + tests/meta_test.c| 6 ++ 2 files changed, 7 insertions(+) diff --git a/tests/intel-ci/meta.testlist b/tests/intel-ci/meta.testlist index b3e29235fac6..2ec3db58a409 1006

Re: [Intel-gfx] [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote: > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf > > Of Jeff Kirsher > > Sent: Tuesday, June 6, 2017 1:46 PM > > To: David Miller ; Nikula, Jani > > > > Cc: Ursulin, Tvrtko ; daniel.vet...@ffwll.ch; > >

Re: [Intel-gfx] [PATCH i-g-t] igt/meta_test: Add a warn subtest to make sure warnings are caught as expected.

This should be added to the tests/intel-ci/meta.testlist /Marta > -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Tuesday, June 20, 2017 11:44 AM > To: intel-gfx@lists.freedesktop.org > Cc: Maarten Lankhorst ; Lofstedt, > Marta ; Latvala, Pe

Re: [Intel-gfx] [PATCH i-g-t] igt/meta_test: Add a warn subtest to make sure warnings are caught as expected.

Reviewed-by: Marta Lofstedt > -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Tuesday, June 20, 2017 11:44 AM > To: intel-gfx@lists.freedesktop.org > Cc: Maarten Lankhorst ; Lofstedt, > Marta ; Latvala, Petri > Subject: [PATCH i-g-t] igt/me

Re: [Intel-gfx] [PATCH v9 3/7] drm: Extend the drm format

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Ville Syrjälä > Sent: Thursday, June 15, 2017 6:22 PM > To: Chen, Xiaoguang > Cc: intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; > kra...@redhat.com; intel-gvt-...@lists

Re: [Intel-gfx] [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver

On Mon, Jun 05, 2017 at 02:56:04PM -0700, Puthikorn Voravootivat wrote: > This patch set contain 3 patches which are already reviewed by DK. > Another 6 patches in previous version was already merged in v7 and v9. > - First patch sets the PWM freqency to match data in panel vbt. > - Next patch adds

Re: [Intel-gfx] [PATCH] drm: Restore GNOME monitors.xml support

On Tue, Jun 06, 2017 at 12:26:57PM +0300, Jani Nikula wrote: > On Sun, 04 Jun 2017, "H.J. Lu" wrote: > > Please CC me since I am not on this mailing list. > > Sorry, should've instructed you to send to dri-devel instead of > intel-gfx, because the patch touches drm helpers. Cc'd. > > BR, > Jani.

[Intel-gfx] [PATCH] drm: Fix GETCONNECTOR regression

In commit 91eefc05f0ac71902906b2058360e61bd25137fe Author: Daniel Vetter Date: Wed Dec 14 00:08:10 2016 +0100 drm: Tighten locking in drm_mode_getconnector I reordered the logic a bit in that IOCTL, but that broke userspace since it'll get the new mode list, but not the new property value

Re: [Intel-gfx] [PATCH i-g-t] igt/meta_test: Add a warn subtest to make sure warnings are caught as expected.

Op 20-06-17 om 10:57 schreef Lofstedt, Marta: > Reviewed-by: Marta Lofstedt Thanks, applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Fix GETCONNECTOR regression

On Tue, 20 Jun 2017, Daniel Vetter wrote: > In > > commit 91eefc05f0ac71902906b2058360e61bd25137fe > Author: Daniel Vetter > Date: Wed Dec 14 00:08:10 2016 +0100 > > drm: Tighten locking in drm_mode_getconnector > > I reordered the logic a bit in that IOCTL, but that broke userspace > since

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

On Mon, Jun 19, 2017 at 04:11:35PM -0400, Andrey Grodzovsky wrote: > > > On 06/19/2017 03:24 PM, Sean Paul wrote: > > On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote: > > > On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote: > > > > Problem: > > > > While running IGT kms_atomic_transi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix GETCONNECTOR regression

== Series Details == Series: drm: Fix GETCONNECTOR regression URL : https://patchwork.freedesktop.org/series/26034/ State : success == Summary == Series 26034v1 drm: Fix GETCONNECTOR regression https://patchwork.freedesktop.org/api/1.0/series/26034/revisions/1/mbox/ Test gem_exec_suspend:

[Intel-gfx] Per-engine reset

Next chunk from Michel finally reviewed, after a little hiatus as the series uncovered a deadlock with concurrent resets. Will apply if no objections, and move on to the guc enabling patches. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop

[Intel-gfx] [PATCH 1/9] drm/i915: Wait for concurrent global resets to complete

If we enter i915_handle_error() a second time and a global reset is already in progress, we can simply wait for completion of the first reset. Currently we exit early prior to the actual reset being performed -- the worst of both worlds! v2: Plug into the existing reset_queue, and remember that ks

[Intel-gfx] [PATCH 2/9] drm/i915: Look for active requests earlier in the reset path

From: Michel Thierry And store the active request so that we only search for it once. v2: Check for request completion inside _prepare_engine, don't use ECANCELED, remove unnecessary null checks (Chris). v3: Capture active requests during reset_prepare and store it the engine hangcheck obj. v4

[Intel-gfx] [PATCH 8/9] drm/i915/selftests: reset engine self tests

From: Michel Thierry Check that we can reset specific engines, also check the fallback to full reset if something didn't work. v2: rebase. v3: use RESET_ENGINE_IN_PROGRESS flag. v4: use I915_RESET_ENGINE flag. Signed-off-by: Michel Thierry Link: http://patchwork.freedesktop.org/patch/msgid/20

[Intel-gfx] [PATCH 4/9] drm/i915: Modify error handler for per engine hang recovery

From: Michel Thierry This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails a

[Intel-gfx] [PATCH 6/9] drm/i915: Add engine reset count to error state

From: Michel Thierry Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. A follow-up patch will provide this information in debugfs.

[Intel-gfx] [PATCH 7/9] drm/i915: Export per-engine reset count info to debugfs

From: Michel Thierry A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they are expected to trigger reset; these counts are checked before and after the test to ensure the same. v2: Include reset eng

[Intel-gfx] [PATCH 3/9] drm/i915: Update i915.reset to handle engine resets

From: Michel Thierry In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Arun Siluvery Signed-off-by: Michel Thierry Link: http://patchwork.freedesk

[Intel-gfx] [PATCH 5/9] drm/i915: Add support for per engine reset recovery

From: Michel Thierry This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards. Hangchecker determines which engines

[Intel-gfx] [PATCH 9/9] drm/i915: Enable Engine reset and recovery support

From: Michel Thierry This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery Signed-off-by: Michel Thierry Link: http://patchwork.freedesktop.org/patc

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify eb_lookup_vmas()

On 16/06/2017 17:02, Chris Wilson wrote: Since the introduction of being able to perform a lockless lookup of an object (i915_gem_object_get_rcu() in fbbd37b36fa5 ("drm/i915: Move object release to a freelist + worker") we no longer need to split the object/vma lookup into 3 phases and so combin

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

On 19/06/2017 13:22, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-06-19 13:06:18) On 16/06/2017 17:02, Chris Wilson wrote: @@ -520,7 +511,8 @@ static inline int use_cpu_reloc(const struct reloc_cache *cache, static int eb_reserve_vma(const struct i915_execbuffer *eb,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Wait for concurrent global resets to complete

== Series Details == Series: series starting with [1/9] drm/i915: Wait for concurrent global resets to complete URL : https://patchwork.freedesktop.org/series/26037/ State : success == Summary == Series 26037v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/26037

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote: > Hi, > > Thanks for all the comments. Here are the summaries: > > 1. Modify the structures to make it more general. > struct vfio_device_gfx_plane_info { > __u64 start; > __u64 drm_format_mod; > __u32 drm_format; > __u

Re: [Intel-gfx] Per-engine reset

On 20/06/2017 10:57, Chris Wilson wrote: Next chunk from Michel finally reviewed, after a little hiatus as the series uncovered a deadlock with concurrent resets. Will apply if no objections, and move on to the guc enabling patches. Go for it! :) Regards, Tvrtko

Re: [Intel-gfx] Atomic commit on planes with more than one possible CRTC's

On Fri, Jun 16, 2017 at 03:51:27PM -0400, Leo wrote: > Hello, > > > I'm looking for ideas and suggestions on how to enable IGT to work on > planes with multiple possible_crtcs during atomic commit. Amdgpu > currently has features that rely on this, and planes with multiple > crtc's are not being

[Intel-gfx] [CI 1/3] drm/i915: Group all the global context information together

Create a substruct to hold all the global context state under drm_i915_private. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +-- drivers/gpu/drm/i915/i915_drv.c | 9 +++--- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [CI 2/3] drm/i915: Allow contexts to be unreferenced locklessly

If we move the actual cleanup of the context to a worker, we can allow the final free to be called from any context and avoid undue latency in the caller. v2: Negotiate handling the delayed contexts free by flushing the workqueue before calling i915_gem_context_fini() and performing the final free

[Intel-gfx] [CI 3/3] drm/i915: Enable rcu-only context lookups

Whilst the contents of the context is still protected by the big struct_mutex, this is not much of an improvement. It is just one tiny step towards reducing our BKL. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h| 16 +-- drivers/gpu

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace execbuf vma ht with an idr

On 16/06/2017 17:02, Chris Wilson wrote: This was the competing idea long ago, but it was only with the rewrite of the idr as an radixtree and using the radixtree directly ourselves, and the realisation that we can store the vma directly in the radixtree and only need a list for the reverse mapp

Re: [Intel-gfx] [i-g-t] igt/gem_reset_stats: Fix pending batches status expectation

On Fri, Jun 09, 2017 at 10:54:13AM -0700, Michel Thierry wrote: > On 6/9/2017 10:02 AM, Antonio Argenziano wrote: > > Test expects pending batches to be discarded after a reset. That is no > > longer the case. Fixed to expect a normal execution. > > You could expand this to say: > after commit 821

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2)

On 19/06/2017 12:16, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2) URL : https://patchwork.freedesktop.org/series/25907/ State : success == Summary == Series 25907v2 Series without cover letter https://patchwork.freedes

[Intel-gfx] [PATCH] drm/i915: Assert the vma's active tracking is clear before free

In looking at a use-after-free on Baytrail, it looks like the VMA's activity tracking is suspect. Add some asserts to catch freeing the VMA before we have decoupled all of its i915_gem_active trackers. References: https://bugs.freedesktop.org/show_bug.cgi?id=101511 Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH 3/3] drm/i915: Assert the vma's active tracking is clear before free

In looking at a use-after-free on Baytrail, it looks like the VMA's activity tracking is suspect. Add some asserts to catch freeing the VMA before we have decoupled all of its i915_gem_active trackers. References: https://bugs.freedesktop.org/show_bug.cgi?id=101511 Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH 2/3] drm/i915: Pass the right flags to i915_vma_move_to_active()

i915_vma_move_to_active() takes the execobject flags and not a boolean! Instead of passing EXEC_OBJECT_WRITE we passed true [i.e. EXEC_OBJECT_NEEDS_FENCE] causing us to start tracking the vma->last_fence access and since we forgot to clear that on unbinding, we caused a use-after-free. [ 321.2638

[Intel-gfx] [PATCH 1/3] drm/i915: Retire the VMA's fence tracker before unbinding

Since we may track unfenced access (GPU access to the vma that explicitly requires no fence), vma->last_fence may be set without any attached fence (vma->fence) and so will not be flushed when we call i915_vma_put_fence(). Since we stopped doing a full retire of the activity trackers for unbind, we

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

Hi Dave, drm-intel-next-2017-06-19: Final pile of features for 4.13 New uabi: - batch bo in first slot, for faster execbuf assembly in userspace (Chris Wilson) - (sub)slice getparam, needed for mesa perf support (Robert Bragg) First pile of patches for cnl/cfl support, maintained by Rodrigo bu

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Group all the global context information together

== Series Details == Series: series starting with [CI,1/3] drm/i915: Group all the global context information together URL : https://patchwork.freedesktop.org/series/26039/ State : warning == Summary == Series 26039v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/serie

[Intel-gfx] [PATCH 4/5] drm/i915: Clean up some expressions

From: Ville Syrjälä Write the '!(SNB||IVB)' checks in the CPT/PPT detections as '!SNB && !IVB' to make it less messy looking, and clear out some useless parens the from the virtualization PCH detection case. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 14 +++---

[Intel-gfx] [PATCH 3/5] drm/i915: Document that PPT==CPT and WPT==LPT

From: Ville Syrjälä For our purposes PPT is equivalent to CPT, and WPT is equivalent to LPT. Document that fact. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gp

[Intel-gfx] [PATCH 5/5] drm/i915: Always use 9 bits of the LPC bridge device ID for PCH detection

From: Ville Syrjälä Make the code less confusiong by always using the top 9 bits of the LPC bridge device ID to detect the PCH type. We need to add a bit of new code for WPT, and we need to adjust the KBP ID as well. All the other pre-CNP IDs are fine as is. The CNP ID I guessed based on the KBP

[Intel-gfx] [PATCH 1/5] drm/i915: Use HAS_PCH_CPT() everywhere

From: Ville Syrjälä We have a few cases comparing pch_type directly. Let's just replace them with HAS_PCH_CPT() since CPT/PPT is what they're looking for. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_device_info.c | 2 +- drivers/gpu/drm/i915/intel_sdvo.c| 2 +- 2 files

[Intel-gfx] [PATCH 2/5] drm/i915: s/Couar/Cougar/

From: Ville Syrjälä Fix a typo in the PCH type debug message. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ee2325b180e7..aa99619bfc1b

[Intel-gfx] [PATCH 0/5] drm/i915: PCH detection cleanup

From: Ville Syrjälä During the recent discusison on the PCH detection details it was suggested that we should just always use the top 9 bits of the ISA/LPC bridge device ID to detect the PCH type. Currently we use either 8 or 9 bits depending on the PCH type. Series available here: git://github.

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Assert the vma's active tracking is clear before free

== Series Details == Series: drm/i915: Assert the vma's active tracking is clear before free URL : https://patchwork.freedesktop.org/series/26041/ State : warning == Summary == Series 26041v1 drm/i915: Assert the vma's active tracking is clear before free https://patchwork.freedesktop.org/api/

[Intel-gfx] [PATCH v6] drm/i915: Enable guest i915 48bit full ppgtt functionality

Enable the guest i915 48bit full ppgtt functionality when host can provide the capability. vgt_caps is introduced to guest i915 driver to get the vgpu capabilities from the device model. VGT_CAPS_FULL_PPGTT_48BIT is one of the capabilities type which let guest i915 dirver know that the guest 48bit

[Intel-gfx] [PATCH v6] drm/i915/gvt: Fix guest i915 48bit full ppgtt blocking issue

Guest i915 48bit full ppgtt functionality was blocking by an issue, which would lead to gpu hardware hang. Guest i915 driver may update the ppgtt table just before this workload is going to be submitted to the hardware by device model. This case wasn't handled well by device model before, due to th

Re: [Intel-gfx] [PATCH v2] lib/igt_kms: Fix override_mode handling

On Fri, Jun 16, 2017 at 03:00:06PM +0100, Liviu Dudau wrote: > From: Brian Starkey > > Changelog: > - v2: removed the forced overwrite of output->config.default_mode > - v1: original submission by Brian > > igt_display_commit isn't refreshing all outputs anymore, which means > that an override m

[Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color correction registers (brightness, contrast, and saturation). On CHV pipe B we w

[Intel-gfx] [PATCH v2 3/5] drm/i915: Add support for the YCbCr COLOR_ENCODING property

From: Ville Syrjälä Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can generally handle BT.601 and BT.709. CHV pipe B sprites have a fully programmable matrix, so in theory we could handle anything, but it

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Retire the VMA's fence tracker before unbinding

== Series Details == Series: series starting with [1/3] drm/i915: Retire the VMA's fence tracker before unbinding URL : https://patchwork.freedesktop.org/series/26045/ State : failure == Summary == Series 26045v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/260

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On 6/19/2017 8:25 PM, Alex Williamson wrote: > On Mon, 19 Jun 2017 08:38:32 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >>> My suggestion was to use vfio device fd for this ioctl and have >>> dmabuf >>> mgr fd as member in above query_plane structure, for region type it >>> would be set to 0.

[Intel-gfx] [PATCH v2 5/5] drm/i915: Add support for the YCbCr COLOR_RANGE property

From: Ville Syrjälä Add support for the COLOR_RANGE property on planes. This property selects whether the input YCbCr data is to treated as limited range or full range. On most platforms this is a matter of setting the "YUV range correction disable" bit, and on VLV/CHV we'll just have to program

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add support for the YCbCr COLOR_ENCODING property

R-B: Shashank Sharma > Regards Shashank On 6/20/2017 7:03 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Clean up some expressions

On Tue, 20 Jun 2017, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Write the '!(SNB||IVB)' checks in the CPT/PPT detections > as '!SNB && !IVB' to make it less messy looking, and clear out > some useless parens the from the virtualization PCH detection case. > > Signed-off-by: Vil

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: PCH detection cleanup

== Series Details == Series: drm/i915: PCH detection cleanup URL : https://patchwork.freedesktop.org/series/26046/ State : warning == Summary == Series 26046v1 drm/i915: PCH detection cleanup https://patchwork.freedesktop.org/api/1.0/series/26046/revisions/1/mbox/ Test gem_exec_suspend:

Re: [Intel-gfx] [igt PATCH] igt/pm_rps: Remove remaining assert on CUR <= MAX

On Wed, 2017-06-14 at 12:44 -0700, jeff.mc...@intel.com wrote: > From: Jeff McGee > > This completes the change started by: > > commit 39cccab83b7c515a2b57abe679a8cb304c8933ef > Author: Chris Wilson > Date:   Fri May 19 09:41:40 2017 +0100 > > igt/pm_rps: Allow CUR to be greater than MAX (

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On 6/20/2017 2:05 PM, Gerd Hoffmann wrote: > Hi, > >>> Hmm, plane isn't really an ID, it is a type, with type being either >>> DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think >>> the >>> flage above make sense. >> >> The intention was that ..._REGION_ID and ...PLANE_ID are de

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

Regards Shashank On 6/20/2017 7:02 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color c

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Enable guest i915 48bit full ppgtt functionality

== Series Details == Series: drm/i915: Enable guest i915 48bit full ppgtt functionality URL : https://patchwork.freedesktop.org/series/26048/ State : warning == Summary == Series 26048v1 drm/i915: Enable guest i915 48bit full ppgtt functionality https://patchwork.freedesktop.org/api/1.0/series

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix guest i915 48bit full ppgtt blocking issue

== Series Details == Series: drm/i915/gvt: Fix guest i915 48bit full ppgtt blocking issue URL : https://patchwork.freedesktop.org/series/26049/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/uts

[Intel-gfx] ✗ Fi.CI.BAT: failure for sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors (rev4)

== Series Details == Series: sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors (rev4) URL : https://patchwork.freedesktop.org/series/25505/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/gen

Re: [Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote: > This patch checks encoder level support for HDMI YCBCR outputs. > HDMI output mode is a connector property, this patch checks if > source and sink can support the HDMI output type selected by user. > And if they both can, it commits the hd

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Always use 9 bits of the LPC bridge device ID for PCH detection

On Tue, 20 Jun 2017, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the code less confusiong by always using the top 9 bits of the > LPC bridge device ID to detect the PCH type. We need to add a bit of > new code for WPT, and we need to adjust the KBP ID as well. All the > oth

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

On Tue, Jun 20, 2017 at 07:27:54PM +0530, Sharma, Shashank wrote: > Regards > Shashank > > On 6/20/2017 7:02 PM, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Turns out the VLV/CHV fixed function sprite CSC expects full range > > data as input. We've been feeding it limited

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

Regards Shashank On 6/20/2017 8:04 PM, Ville Syrjälä wrote: On Tue, Jun 20, 2017 at 07:27:54PM +0530, Sharma, Shashank wrote: Regards Shashank On 6/20/2017 7:02 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Always use 9 bits of the LPC bridge device ID for PCH detection

On Tue, Jun 20, 2017 at 05:34:42PM +0300, Jani Nikula wrote: > On Tue, 20 Jun 2017, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Make the code less confusiong by always using the top 9 bits of the > > LPC bridge device ID to detect the PCH type. We need to add a bit of > >

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

On Tue, Jun 20, 2017 at 08:13:42PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 6/20/2017 8:04 PM, Ville Syrjälä wrote: > > On Tue, Jun 20, 2017 at 07:27:54PM +0530, Sharma, Shashank wrote: > >> Regards > >> Shashank > >> > >> On 6/20/2017 7:02 PM, ville.syrj...@linux.intel.com

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Tue, 20 Jun 2017 12:57:36 +0200 Gerd Hoffmann wrote: > On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote: > > Hi, > > > > Thanks for all the comments. Here are the summaries: > > > > 1. Modify the structures to make it more general. > > struct vfio_device_gfx_plane_info { > > __u64 st

Re: [Intel-gfx] [i-g-t] igt/gem_reset_stats: Fix pending batches status expectation

On 20/06/17 04:45, Arkadiusz Hiler wrote: On Fri, Jun 09, 2017 at 10:54:13AM -0700, Michel Thierry wrote: On 6/9/2017 10:02 AM, Antonio Argenziano wrote: Test expects pending batches to be discarded after a reset. That is no longer the case. Fixed to expect a normal execution. You could exp

[Intel-gfx] drm-misc-next for 4.13

Hi Dave, One more -misc-next pull for 4.13 from drm-misc-next. These 3 patches came less than an hour after my last PR, so we'll sneak these in and cut over to next-fixes after this. All 3 are vc4. 2 add tiling support to vc4 and the other replaces hand-rolled atomic commit code with the helpers.

Re: [Intel-gfx] [i-g-t] igt/gem_reset_stats: Fix pending batches status expectation

On Tue, Jun 20, 2017 at 08:01:37AM -0700, Antonio Argenziano wrote: > > > On 20/06/17 04:45, Arkadiusz Hiler wrote: > > On Fri, Jun 09, 2017 at 10:54:13AM -0700, Michel Thierry wrote: > > > On 6/9/2017 10:02 AM, Antonio Argenziano wrote: > > > > Test expects pending batches to be discarded after

Re: [Intel-gfx] [igt PATCH] igt/pm_rps: Remove remaining assert on CUR <= MAX

On Tue, Jun 20, 2017 at 01:54:54PM +, Szwichtenberg, Radoslaw wrote: > On Wed, 2017-06-14 at 12:44 -0700, jeff.mc...@intel.com wrote: > > From: Jeff McGee > > > > This completes the change started by: > > > > commit 39cccab83b7c515a2b57abe679a8cb304c8933ef > > Author: Chris Wilson > > Date:

Re: [Intel-gfx] [PATCH v2] lib/igt_kms: Fix override_mode handling

On Tue, Jun 20, 2017 at 04:28:14PM +0300, Arkadiusz Hiler wrote: > On Fri, Jun 16, 2017 at 03:00:06PM +0100, Liviu Dudau wrote: > > From: Brian Starkey > > > > Changelog: > > - v2: removed the forced overwrite of output->config.default_mode > > - v1: original submission by Brian > > > > igt_disp

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

Hi Dave, a mixed bag of i915 fixes. The memory allocation changes from Chris and deadlock fixes from Ville are the important ones. BR, Jani. The following changes since commit c380f681245d7ae57f17d9ebbbe8f8f1557ee1fb: drm/i915: Fix GVT-g PVINFO version compatibility check (2017-06-13 11:19:22

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Pass the right flags to i915_vma_move_to_active()

On 20/06/2017 13:43, Chris Wilson wrote: i915_vma_move_to_active() takes the execobject flags and not a boolean! Instead of passing EXEC_OBJECT_WRITE we passed true [i.e. EXEC_OBJECT_NEEDS_FENCE] causing us to start tracking the vma->last_fence access and since we forgot to clear that on unbindi

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Assert the vma's active tracking is clear before free

On 20/06/2017 13:43, Chris Wilson wrote: In looking at a use-after-free on Baytrail, it looks like the VMA's activity tracking is suspect. Add some asserts to catch freeing the VMA before we have decoupled all of its i915_gem_active trackers. References: https://bugs.freedesktop.org/show_bug.cg

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Retire the VMA's fence tracker before unbinding

On 20/06/2017 13:43, Chris Wilson wrote: Since we may track unfenced access (GPU access to the vma that explicitly requires no fence), vma->last_fence may be set without any Is this the gen < 4 code path? There is no actual fence in this case? attached fence (vma->fence) and so will not be f

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Retire the VMA's fence tracker before unbinding

Quoting Tvrtko Ursulin (2017-06-20 16:55:12) > > On 20/06/2017 13:43, Chris Wilson wrote: > > Since we may track unfenced access (GPU access to the vma that > > explicitly requires no fence), vma->last_fence may be set without any > > Is this the gen < 4 code path? There is no actual fence in thi

[Intel-gfx] [PATCH] drm/i915: Break modeset deadlocks on reset

Trying to do a modeset from within a reset is fraught with danger. We can fall into a cyclic deadlock where the modeset is waiting on a previous modeset that is waiting on a request, and since the GPU hung that request completion is waiting on the reset. As modesetting doesn't allow its locks to be

Re: [Intel-gfx] [PATCH] drm: Fix GETCONNECTOR regression

On Tue, Jun 20, 2017 at 2:32 AM, Jani Nikula wrote: > On Tue, 20 Jun 2017, Daniel Vetter wrote: >> In >> >> commit 91eefc05f0ac71902906b2058360e61bd25137fe >> Author: Daniel Vetter >> Date: Wed Dec 14 00:08:10 2016 +0100 >> >> drm: Tighten locking in drm_mode_getconnector >> >> I reordered

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On 6/20/2017 8:30 PM, Alex Williamson wrote: > On Tue, 20 Jun 2017 12:57:36 +0200 > Gerd Hoffmann wrote: > >> On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote: >>> Hi, >>> >>> Thanks for all the comments. Here are the summaries: >>> >>> 1. Modify the structures to make it more general. >>>

Re: [Intel-gfx] Per-engine reset

On 20/06/17 04:03, Tvrtko Ursulin wrote: On 20/06/2017 10:57, Chris Wilson wrote: Next chunk from Michel finally reviewed, after a little hiatus as the series uncovered a deadlock with concurrent resets. Will apply if no objections, and move on to the guc enabling patches. Go for it! :) A

Re: [Intel-gfx] [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver

On Tue, 2017-06-20 at 11:03 +0200, Daniel Vetter wrote: > On Mon, Jun 05, 2017 at 02:56:04PM -0700, Puthikorn Voravootivat wrote: > > This patch set contain 3 patches which are already reviewed by DK. > > Another 6 patches in previous version was already merged in v7 and v9. > > - First patch se

[Intel-gfx] [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Problem : While running IGT kms_atomic_transition test suite i encountered a hang in drmHandleEvent immediately following an atomic_commit. After dumping the atomic state I relized that in this case there was not even one CRTC attached to the state and only disabled planes. This probably due to a

[Intel-gfx] [PATCH i-g-t 2/3] lib: Add reset-type helper in ioctl_wrappers

Soon we will have tests that are only for platforms with reset-engine (GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl. Signed-off-by: Michel Thierry --- lib/ioctl_wrappers.c | 22 ++ lib/ioctl_wrappers.h | 1 + 2 files changed, 23 insertions(+) di

[Intel-gfx] [PATCH i-g-t 3/3] tests/gem_reset_stats: Enforce full chip reset mode before run

Platforms with per-engine reset enabled (i915.reset=2) are unlikely to perform a full chip reset, keeping the reset_count unmodified. In order to keep the expectations of this test, enforce that full GPU reset is enabled (i915.reset=1). Later on, we can expand the reset_stats ioctl to also return

[Intel-gfx] [PATCH i-g-t 1/3] lib: Force global reset + uevents for hang detector

From: Chris Wilson The hang detector relies on a uevent for notification and aborting the test. As proposed, fine-grained resets may not produce a global uevent and so this hang detection becomes void. As we don't expect any hang, we can just reduce the reset to only a global + uevent and so main

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/core: Fail atomic IOCTL with no CRTC state but with signaling. (rev2)

== Series Details == Series: drm/core: Fail atomic IOCTL with no CRTC state but with signaling. (rev2) URL : https://patchwork.freedesktop.org/series/25591/ State : success == Summary == Series 25591v2 drm/core: Fail atomic IOCTL with no CRTC state but with signaling. https://patchwork.freed

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Always use 9 bits of the LPC bridge device ID for PCH detection

On Tue, 2017-06-20 at 16:03 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the code less confusiong by always using the top 9 bits of the > LPC bridge device ID to detect the PCH type. We need to add a bit of > new code for WPT, and we need to adjust the KBP ID as w

  1   2   >