[Intel-gfx] ✗ Fi.CI.BAT: failure for Convert the intel iommu driver to the dma-iommu api

== Series Details == Series: Convert the intel iommu driver to the dma-iommu api URL : https://patchwork.freedesktop.org/series/71260/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7620 -> Patchwork_15878 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915: Remove tautological compare in eb_relocate_vma

On Tue, Dec 03, 2019 at 10:45:22AM -0800, Nick Desaulniers wrote: > On Tue, Dec 3, 2019 at 5:42 AM Chris Wilson wrote: > > > > Quoting Nick Desaulniers (2019-12-02 19:18:20) > > > On Sat, Nov 23, 2019 at 12:05 PM Chris Wilson > > > wrote: > > > > > > > > Quoting Nathan Chancellor (2019-11-23

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Convert the intel iommu driver to the dma-iommu api

== Series Details == Series: Convert the intel iommu driver to the dma-iommu api URL : https://patchwork.freedesktop.org/series/71260/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4a2327b5e2dd iommu/vt-d: clean up 32bit si_domain assignment -:189: CHECK:PARENTHESIS_ALIGNMENT:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Add support for DP 1.4 Compliance edid corruption test (rev3)

Hi All: I got CI check failures. Among those, hdmi-hpd-fast seems related, but I am not sure why. Please take a brief review and help to determine if it is a real false-positive again. Thanks a lot. Regards, Jerry -Original Message- From: Patchwork Sent: December 9, 2019

[Intel-gfx] [PATCH 5/8] iommu: Add iommu_dma_free_cpu_cached_iovas function

to dma-iommu ops Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which use the dma-iommu ops to free cached cpu iovas. Signed-off-by: Tom Murphy --- drivers/iommu/dma-iommu.c | 9 + include/linux/dma-iommu.h | 3 +++ 2 files changed, 12 insertions(+) diff --git

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Add support for DP 1.4 Compliance edid corruption test (rev3)

On 2019-12-20 2:40 p.m., Zuo, Jerry wrote: > Hi All: > > I got CI check failures. Among those, hdmi-hpd-fast seems related, but I > am not sure why. Please take a brief review and help to determine if it is a > real false-positive again. > It looks like the hdmi-hpd-fast failures are

[Intel-gfx] [PATCH 2/8] iommu/vt-d: Use default dma_direct_* mapping functions for direct mapped devices

We should only assign intel_dma_ops to devices which will actually use the iommu and let the default fall back dma_direct_* functions handle all other devices. This won't change any behaviour but will just use the generic implementations for direct mapped devices rather than intel specific ones.

[Intel-gfx] [PATCH 7/8] iommu/vt-d: Convert intel iommu driver to the iommu ops

Convert the intel iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the intel iommu driver. Signed-off-by: Tom Murphy --- drivers/iommu/Kconfig | 1 + drivers/iommu/intel-iommu.c | 742 +++-

[Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here:

[Intel-gfx] [PATCH 8/8] DO NOT MERGE: iommu: disable list appending in dma-iommu

ops __finalise_sg Disable combining sg segments in the dma-iommu api. Combining the sg segments exposes a bug in the intel i915 driver which causes visual artifacts and the screen to freeze. This is most likely because of how the i915 handles the returned list. It probably doesn't respect the

Re: [Intel-gfx] [PATCH 1/8] iommu/vt-d: clean up 32bit si_domain assignment

On Sat, Dec 21, 2019 at 03:03:53PM +, Tom Murphy wrote: > In the intel iommu driver devices which only support 32bit DMA can't be > direct mapped. The implementation of this is weird. Currently we assign > it a direct mapped domain and then remove the domain later and replace > it with a

[Intel-gfx] [PATCH 1/8] iommu/vt-d: clean up 32bit si_domain assignment

In the intel iommu driver devices which only support 32bit DMA can't be direct mapped. The implementation of this is weird. Currently we assign it a direct mapped domain and then remove the domain later and replace it with a domain of type IOMMU_DOMAIN_IDENTITY. We should just assign it a domain

[Intel-gfx] [PATCH 4/8] iommu: Handle freelists when using deferred flushing in iommu drivers

Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This is useful for iommu drivers (in this case the intel iommu driver) which need to wait for the ioTLB to be flushed before newly free/unmapped page table pages can be

[Intel-gfx] [PATCH 6/8] iommu: allow the dma-iommu api to use bounce buffers

Allow the dma-iommu api to use bounce buffers for untrusted devices. This is a copy of the intel bounce buffer code. Signed-off-by: Tom Murphy --- drivers/iommu/dma-iommu.c | 93 --- drivers/iommu/iommu.c | 10 + include/linux/iommu.h | 9 +++- 3

[Intel-gfx] [PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path

Remove all IOVA handling code from the non-dma_ops path in the intel iommu driver. There's no need for the non-dma_ops path to keep track of IOVAs. The whole point of the non-dma_ops path is that it allows the IOVAs to be handled separately. The IOVA handling code removed in this patch is

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Move i915_gem_init_contexts() earlier

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move i915_gem_init_contexts() earlier URL : https://patchwork.freedesktop.org/series/71255/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7619 -> Patchwork_15877

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move i915_gem_init_contexts() earlier

== Series Details == Series: drm/i915: Move i915_gem_init_contexts() earlier URL : https://patchwork.freedesktop.org/series/71254/ State : success == Summary == CI Bug Log - changes from CI_DRM_7619 -> Patchwork_15876 Summary ---

[Intel-gfx] [CI 1/2] drm/i915: Move i915_gem_init_contexts() earlier

As the GEM global context setup is now independent of the GT state (although GT does currently still depend upon the global i915->kernel_context), we can move its init earlier, leaving the gt init ready to be extracted. Signed-off-by: Chris Wilson Cc: Andi Shyti Reviewed-by: Andi Shyti ---

[Intel-gfx] [CI 2/2] drm/i915/gt: Pull GT initialisation under intel_gt_init()

Begin pulling the GT setup underneath a single GT umbrella; let intel_gt take ownership of its engines! As hinted, the complication is the lifetime of the probed engine versus the active lifetime of the GT backends. We need to detect the engine layout early and keep it until the end so that we can

[Intel-gfx] [CI] drm/i915: Move i915_gem_init_contexts() earlier

As the GEM global context setup is now independent of the GT state (although GT does currently still depend upon the global i915->kernel_context), we can move its init earlier, leaving the gt init ready to be extracted. Signed-off-by: Chris Wilson Cc: Andi Shyti Reviewed-by: Andi Shyti ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Repeat wait_for_idle for retirement workers

== Series Details == Series: drm/i915/gt: Repeat wait_for_idle for retirement workers URL : https://patchwork.freedesktop.org/series/71252/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7618 -> Patchwork_15875 Summary

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Move i915_gem_init_contexts() earlier

== Series Details == Series: series starting with [CI,1/4] drm/i915: Move i915_gem_init_contexts() earlier URL : https://patchwork.freedesktop.org/series/71251/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7618 -> Patchwork_15874

[Intel-gfx] [PATCH] drm/i915/gt: Repeat wait_for_idle for retirement workers

Since we may retire timelines from secondary workers, intel_gt_retire_requests() is not always a reliable indicator that all pending retirements are complete. If we do detect secondary workers are in progress, recommend intel_gt_wait_for_idle() to repeat the retirement check. Signed-off-by: Chris

[Intel-gfx] [CI 3/4] drm/i915/gt: Pull intel_gt_init_hw() into intel_gt_resume()

Since intel_gt_resume() is always immediately proceeded by init_hw, pull the call into intel_gt_resume, where we have the rpm and fw already held. Signed-off-by: Chris Wilson Cc: Andi Shyti Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 20 +---

[Intel-gfx] [CI 1/4] drm/i915: Move i915_gem_init_contexts() earlier

As the GEM global context setup is now independent of the GT state (although GT does currently still depend upon the global i915->kernel_context), we can move its init earlier, leaving the gt init ready to be extracted. Signed-off-by: Chris Wilson Cc: Andi Shyti Reviewed-by: Andi Shyti ---

[Intel-gfx] [CI 4/4] drm/i915/gt: Merge engine init/setup loops

Now that we don't need to create GEM contexts in the middle of engine construction, we can pull the engine init/setup loops together. Signed-off-by: Chris Wilson Cc: Andi Shyti Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 118 +++---

[Intel-gfx] [CI 2/4] drm/i915/gt: Pull GT initialisation under intel_gt_init()

Begin pulling the GT setup underneath a single GT umbrella; let intel_gt take ownership of its engines! As hinted, the complication is the lifetime of the probed engine versus the active lifetime of the GT backends. We need to detect the engine layout early and keep it until the end so that we can

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove i915->kernel_context (rev3)

== Series Details == Series: drm/i915: Remove i915->kernel_context (rev3) URL : https://patchwork.freedesktop.org/series/71209/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7617 -> Patchwork_15873 Summary ---

Re: [Intel-gfx] [PATCH 15/15] drm/i915/tgl: Add Clear Color support for TGL Render Decompression

On Fri, Dec 20, 2019 at 02:58:12PM -0800, Matt Roper wrote: > On Wed, Dec 18, 2019 at 06:11:05PM +0200, Imre Deak wrote: > > From: Radhakrishna Sripada > > > > Render Decompression is supported with Y-Tiled main surface. The CCS is > > linear and has 4 bits of data for each main surface cache

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only retire requests when eviction is allowed to blocked

== Series Details == Series: drm/i915: Only retire requests when eviction is allowed to blocked URL : https://patchwork.freedesktop.org/series/71249/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7617 -> Patchwork_15872

[Intel-gfx] [CI] drm/i915: Remove i915->kernel_context

Allocate only an internal intel_context for the kernel_context, forgoing a global GEM context for internal use as we only require a separate address space (for our own protection). Now having weaned GT from requiring ce->gem_context, we can stop referencing it entirely. This also means we no

[Intel-gfx] ✓ Fi.CI.BAT: success for drn/i915: Break up long i915_buddy_free_list() with a cond_resched()

== Series Details == Series: drn/i915: Break up long i915_buddy_free_list() with a cond_resched() URL : https://patchwork.freedesktop.org/series/71248/ State : success == Summary == CI Bug Log - changes from CI_DRM_7617 -> Patchwork_15871

[Intel-gfx] [PATCH] drm/i915: Only retire requests when eviction is allowed to blocked

We want to keep the PIN_NONBLOCK search quick, avoiding evicting recently active nodes. To that end, skip performing the more laborious retirement prior to beginning the fast search. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_evict.c | 6 -- 1 file changed, 4

[Intel-gfx] [PATCH] drn/i915: Break up long i915_buddy_free_list() with a cond_resched()

In the selftests, we may feed very long lists of blocks to be freed on culmination of the tests. This coupled with kasan and other malloc-tracing can make the kmem_cache_free() operation time consuming, and doing many of time trigger soft lockup warnings. Break the list up with a cond_resched().

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Render/media decompression support (rev10)

== Series Details == Series: drm/i915/tgl: Render/media decompression support (rev10) URL : https://patchwork.freedesktop.org/series/71125/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7612_full -> Patchwork_15859_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Render decompression support

== Series Details == Series: drm/i915/tgl: Render decompression support URL : https://patchwork.freedesktop.org/series/71239/ State : success == Summary == CI Bug Log - changes from CI_DRM_7617 -> Patchwork_15870 Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Disable Port sync mode correctly on teardown (rev2)

== Series Details == Series: drm/i915/dp: Disable Port sync mode correctly on teardown (rev2) URL : https://patchwork.freedesktop.org/series/71196/ State : success == Summary == CI Bug Log - changes from CI_DRM_7612_full -> Patchwork_15856_full

[Intel-gfx] [PATCH 06/10] drm/i915/tgl: Gen-12 render decompression

From: Dhinakaran Pandiyan Gen-12 display decompression operates on Y-tiled compressed main surface. The CCS is linear and has 4 bits of metadata for each main surface cache line pair, a size ratio of 1:256. Gen-12 display decompression is incompatible with buffers compressed by earlier GPUs, so

[Intel-gfx] [PATCH 07/10] drm/i915/tgl: Make sure FBs have a correct CCS plane stride

The CCS plane stride must be fixed on TGL, as it's not configurable for the display. Instead the HW has a hardwired logic to determine it from the main plane stride. Make sure userspace passes in the correct stride. Cc: Dhinakaran Pandiyan Cc: Ville Syrjälä Cc: Mika Kahola Signed-off-by: Imre

[Intel-gfx] [PATCH 09/10] drm/i915: Make sure Y slave planes get all the required state

Y planes program the offset and stride of the AUX plane, so make sure we copy the required info for this into their plane state. Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Dhinakaran Pandiyan Cc: Mika Kahola Signed-off-by: Imre Deak Reviewed-by: Mika Kahola ---

[Intel-gfx] [PATCH 05/10] drm/framebuffer: Format modifier for Intel Gen-12 render compression

From: Dhinakaran Pandiyan Gen-12 has a new compression format, add a new modifier to indicate that. Cc: Ville Syrjälä Cc: Matt Roper Cc: Nanley G Chery Cc: Jason Ekstrand Cc: Mika Kahola Cc: dri-de...@lists.freedesktop.org Signed-off-by: Dhinakaran Pandiyan Signed-off-by: Lucas De Marchi

[Intel-gfx] [PATCH 08/10] drm/i915: Skip rotated offset adjustment for unsupported modifiers

From: Dhinakaran Pandiyan During framebuffer creation, we pre-compute offsets for 90/270 plane rotation. However, only Y and Yf modifiers support 90/270 rotation. So, skip the calculations for other modifiers. To keep the gem buffer size check still working for tiled planes, factor out the

[Intel-gfx] [PATCH 10/10] drm/i915: Make sure CCS YUV semiplanar format checks work

For CCS formats, the current DRM core check for YUV semiplanar formats doesn't work; use an i915 specific function for that. v2: Fix checkpatch warnings. Cc: Dhinakaran Pandiyan Cc: Ville Syrjälä Cc: Mika Kahola Signed-off-by: Imre Deak Reviewed-by: Mika Kahola ---

[Intel-gfx] [PATCH 01/10] drm/i915: Use intel_tile_height() instead of re-implementing

From: Dhinakaran Pandiyan intel_tile_dims() computes tile height using size and width, when there is already a function to do just that - intel_tile_height() Cc: Ville Syrjälä Cc: Matt Roper Cc: Mika Kahola Signed-off-by: Dhinakaran Pandiyan Signed-off-by: Imre Deak Reviewed-by: Mika

[Intel-gfx] [PATCH 00/10] drm/i915/tgl: Render decompression support

This is the first part of [1] with only render decompression enabled. I left the second part with media decompression and render decompression color clear functionality for later - once we have the IGT tests for them in place. Cc: Dhinakaran Pandiyan Cc: Radhakrishna Sripada Cc: Ville Syrjala

[Intel-gfx] [PATCH 02/10] drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment

From: Dhinakaran Pandiyan Easier to read if all the alignment changes are in one place and contained within a function. Cc: Ville Syrjälä Cc: Matt Roper Cc: Mika Kahola Signed-off-by: Dhinakaran Pandiyan Signed-off-by: Imre Deak Reviewed-by: Mika Kahola Reviewed-by: Matt Roper ---

[Intel-gfx] [PATCH 04/10] drm/i915: Add helpers to select correct ccs/aux planes

Using helpers instead of open coding this to select a CCS plane for a main plane makes the code cleaner and less error-prone when the location of CCS plane can be different based on the format (packed vs. YUV semiplanar). The same applies to selecting an AUX plane which can be a UV plane (for an

[Intel-gfx] [PATCH 03/10] drm/i915: Extract framebufer CCS offset checks into a function

From: Dhinakaran Pandiyan intel_fill_fb_info() has grown quite large and wrapping the offset checks into a separate function makes the loop a bit easier to follow. v2: Skip the check for non-CCS planes. (Mika) Cc: Ville Syrjälä Cc: Matt Roper Cc: Mika Kahola Signed-off-by: Dhinakaran

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Render/media decompression support (rev3)

Imre, Acknowledged and re-reported. https://patchwork.freedesktop.org/series/71125/ Lakshmi. -Original Message- From: Imre Deak Sent: Friday, December 20, 2019 5:32 PM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/tgl:

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/selftests: make mock_context.h self-contained (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: make mock_context.h self-contained (rev2) URL : https://patchwork.freedesktop.org/series/71178/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7612_full -> Patchwork_15854_full