[Intel-gfx] ✓ Fi.CI.BAT: success for Use drm_clflush* instead of clflush

== Series Details == Series: Use drm_clflush* instead of clflush URL : https://patchwork.freedesktop.org/series/100717/ State : success == Summary == CI Bug Log - changes from CI_DRM_11285 -> Patchwork_22408 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/psr: Set "SF Partial Frame Enable" also on full update (rev4)

== Series Details == Series: drm/i915/psr: Set "SF Partial Frame Enable" also on full update (rev4) URL : https://patchwork.freedesktop.org/series/100633/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separa

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Set "SF Partial Frame Enable" also on full update (rev4)

== Series Details == Series: drm/i915/psr: Set "SF Partial Frame Enable" also on full update (rev4) URL : https://patchwork.freedesktop.org/series/100633/ State : success == Summary == CI Bug Log - changes from CI_DRM_11285 -> Patchwork_22409 ===

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev4)

> From: Saarinen, Jani > > From: Navare, Manasi D > > Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR > capable > > property on a long hpd (rev4) > > > > Hi, > > > > > > > > I fixed the regression in this patch and resent it, it still has BAT > > failures, I > wanted > > to

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Do not try loading wrong DMC version

== Series Details == Series: drm/i915/dmc: Do not try loading wrong DMC version URL : https://patchwork.freedesktop.org/series/100664/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11279_full -> Patchwork_22393_full Summary

Re: [Intel-gfx] [PATCH v6 1/2] drm/vrr: Set VRR capable prop only if it is attached to connector

On Thu, Feb 24, 2022 at 05:30:54PM -0800, Manasi Navare wrote: > VRR capable property is not attached by default to the connector > It is attached only if VRR is supported. > So if the driver tries to call drm core set prop function without > it being attached that causes NULL dereference. > > Cc:

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/display/vrr: Reset VRR capable property on a long hpd

On Thu, Feb 24, 2022 at 05:30:55PM -0800, Manasi Navare wrote: > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel > settings. > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore > MSA bit > in the DPCD. Currently the driver parses that onevery HPD

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 25.02.2022 06:03, Jordan Justen wrote: > John Harrison writes: > >> On 2/22/2022 02:36, Jordan Justen wrote: >>> From: John Harrison >>> >>> Implement support for fetching the hardware description table from the >>> GuC. The call is made twice - once without a destination buffer to >>> que

[Intel-gfx] [bug report] drm/i915: Extract intel_bw_check_data_rate()

Hello Ville Syrjälä, The patch 6d8ebef53c2c: "drm/i915: Extract intel_bw_check_data_rate()" from Feb 18, 2022, leads to the following Smatch static checker warning: drivers/gpu/drm/i915/display/intel_bw.c:922 intel_bw_atomic_check() error: we previously assumed 'new_bw_state' coul

[Intel-gfx] [PATCH] drm/i915: apply PM_EARLY for non-GTT mappable objects

On DG2 we allow objects that are smaller than the min_page_size, under the premise that these are never mapped by the GTT, like with the paging structures. Currently the suspend-resume path will try to map such objects through the migration vm, which hits: [ 560.529217] kernel BUG at drivers/gpu/

Re: [Intel-gfx] [PATCH] drm/i915: apply PM_EARLY for non-GTT mappable objects

On 2/25/22 11:34, Matthew Auld wrote: On DG2 we allow objects that are smaller than the min_page_size, under the premise that these are never mapped by the GTT, like with the paging structures. Currently the suspend-resume path will try to map such objects through the migration vm, which hits:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: apply PM_EARLY for non-GTT mappable objects

== Series Details == Series: drm/i915: apply PM_EARLY for non-GTT mappable objects URL : https://patchwork.freedesktop.org/series/100733/ State : success == Summary == CI Bug Log - changes from CI_DRM_11285 -> Patchwork_22410 Summary --

Re: [Intel-gfx] [PATCH 2/2] hda/i915: split the wait for the component binding

On Thu, 24 Feb 2022 17:34:54 +0100, Kai Vehmanen wrote: > > Hi, > > On Thu, 24 Feb 2022, Ramalingam C wrote: > > > Split the wait for component binding from i915 in multiples of > > sysctl_hung_task_timeout_secs. This helps to avoid the possible kworker > > thread hung detection given below. >

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Do not try loading wrong DMC version

On 2022-02-25 at 08:47:05 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/dmc: Do not try loading wrong DMC version > URL : https://patchwork.freedesktop.org/series/100664/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11279_full -> Patchwork_2239

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev4)

== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev4) URL : https://patchwork.freedesktop.org/series/100136/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11282_full -> Patchwork_22396_full

[Intel-gfx] [PATCH 0/2] Fix prime_mmap to work when using LMEM

The current implementation of i915 prime mmap only worked when initializing drm_i915_gem_object with shmem_region. When using LMEM, drm_i915_gem_object is initialized with ttm_system_region. In order to make prime mmap work even this case, when using LMEM (when using ttm in i915), dma_buf_ops.mmap

[Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: Update dma_buf_ops.unmap_dma_buf callback to use drm_gem_unmap_dma_buf()

The dma_buf_ops.unmap_dma_buf callback used in i915, i915_gem_unmap_dma_buf(), has the same code as drm_gem_unmap_dma_buf(). In order to eliminate defining and using duplicate function, it updates the dma_buf_ops.unmap_dma_buf callback to use drm_gem_unmap_dma_buf(). Signed-off-by: Gwan-gyeong Mun

[Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: Fix prime_mmap to work when using LMEM

The current implementation of i915 prime mmap only works when initializing drm_i915_gem_object with shmem_region. When using LMEM, drm_i915_gem_object is initialized with ttm_system_region. In order to make prime mmap work even this case, when using LMEM (when using ttm in i915), dma_buf_ops.mmap c

[Intel-gfx] [PATCH 1/3] drm/doc: Fix typos and update outdated structure and API names

It fixes typo and updates outdated struct and API names that are currently deprecated or in use but have changed on the kernel documents of DRM section and comments. Signed-off-by: Gwan-gyeong Mun --- Documentation/gpu/drm-mm.rst | 8 drivers/gpu/drm/drm_file.c| 10

[Intel-gfx] [PATCH 3/3] drm/prime: Update docs

It updates the name of the structure with the target function callback is incorrect : drm_gem_object_funcs.gem_prime_import_sg_table to drm_driver.gem_prime_import_sg_table And it updates the part where the description and the function callback name are different. : drm_gem_object_funcs.pin to d

[Intel-gfx] [PATCH 2/3] drm/i915: Update mismatched structure name

It updates i915_gem_ctx to i915_gem_ww_ctx and adds missing indefinite article to doc. Signed-off-by: Gwan-gyeong Mun --- Documentation/gpu/i915.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index bcaefc952764.

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 25/02/2022 09:44, Michal Wajdeczko wrote: On 25.02.2022 06:03, Jordan Justen wrote: John Harrison writes: On 2/22/2022 02:36, Jordan Justen wrote: From: John Harrison Implement support for fetching the hardware description table from the GuC. The call is made twice - once without a de

Re: [Intel-gfx] [PATCH] drm/i915: s/JSP2/ICP2/ PCH

Works fine, thanks. Tested-by: Tomas Bzatek On Thu, 2022-02-24 at 15:21 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > This JSP2 PCH actually seems to to be some special Apple > specific ICP variant rather than a JSP. Make it so. Or at > least all the references to it seem to be some A

[Intel-gfx] [PATCH topic/core-for-CI] iommu/vt-d: Add RPLS to quirk list to skip TE disabling

The VT-d spec requires (10.4.4 Global Command Register, TE field) that: Hardware implementations supporting DMA draining must drain any in-flight DMA read/write requests queued within the Root-Complex before completing the translation enable command and reflecting the status of the command through

[Intel-gfx] [PATCH topic/core-for-CI] PCI: vmd: Prevent recursive locking on interrupt allocation

From: Thomas Gleixner Tejas reported the following recursive locking issue: swapper/0/1 is trying to acquire lock: 8881074fd0a0 (&md->mutex){+.+.}-{3:3}, at: msi_get_virq+0x30/0xc0 but task is already holding lock: 8881017cd6a0 (&md->mutex){+.+.}-{3:3}, at: __pci_enable_msi_range+0

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev4)

On 25/02/2022 12:56, Patchwork wrote: *Patch Details* *Series:* drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev4) *URL:* https://patchwork.freedesktop.org/series/100136/ *State:*failure *Details:*

[Intel-gfx] [CI 1/7] drm/i915: add io_size plumbing

With small LMEM-BAR we need to be able to differentiate between the total size of LMEM, and how much of it is CPU mappable. The end goal is to be able to utilize the entire range, even if part of is it not CPU accessible. v2: also update intelfb_create Signed-off-by: Matthew Auld Cc: Thomas Hell

[Intel-gfx] [CI 3/7] drm/i915: add I915_BO_ALLOC_GPU_ONLY

If the user doesn't require CPU access for the buffer, then ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the non-mappable portion of LMEM, on devices with small BAR. v2(Thomas): - The BO_ALLOC_TOPDOWN naming here is poor, since this is pure lies on systems that don't e

[Intel-gfx] [CI 2/7] drm/i915/ttm: require mappable by default

On devices with non-mappable LMEM ensure we always allocate the pages within the mappable portion. For now we assume that all LMEM buffers will require CPU access, which is also inline with pretty much all current kernel internal users. In the next patch we will introduce a new flag to override thi

[Intel-gfx] [CI 5/7] drm/i915/buddy: adjust res->start

Differentiate between mappable vs non-mappable resources, also if this is an actual range allocation ensure we set res->start as the starting pfn. Later when we need to do non-mappable -> mappable moves then we want TTM to see that the current placement is not compatible, which should result in an

[Intel-gfx] [CI 4/7] drm/i915/buddy: track available visible size

Track the total amount of available visible memory, and also track per-resource the amount of used visible memory. For now this is useful for our debug output, and deciding if it is even worth calling into the buddy allocator. In the future tracking the per-resource visible usage will be useful for

[Intel-gfx] [CI 6/7] drm/i915/buddy: tweak 2big check

Otherwise we get -EINVAL, instead of the more useful -E2BIG if the allocation doesn't fit within the pfn range, like with mappable lmem. The hugepages selftest, for example, needs this to know if a smaller size is needed. Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hells

[Intel-gfx] [CI 7/7] drm/i915/selftests: mock test io_size

Check that mappable vs non-mappable matches our expectations. Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström --- .../drm/i915/selftests/intel_memory_region.c | 143 ++ 1 file changed, 143 insertions(+) diff --git a/drivers/gpu/drm/i915/selftest

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Be more gentle when exiting non-persistent contexts (rev3)

== Series Details == Series: drm/i915: Be more gentle when exiting non-persistent contexts (rev3) URL : https://patchwork.freedesktop.org/series/93420/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11283_full -> Patchwork_22399_full

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix prime_mmap to work when using LMEM

== Series Details == Series: Fix prime_mmap to work when using LMEM URL : https://patchwork.freedesktop.org/series/100737/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Do not try loading wrong DMC version

On Fri, Feb 25, 2022 at 08:47:05AM +, Patchwork wrote: == Series Details == Series: drm/i915/dmc: Do not try loading wrong DMC version URL : https://patchwork.freedesktop.org/series/100664/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11279_full -> Patchwork_22393_full

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: s/JSP2/ICP2/ PCH

== Series Details == Series: drm/i915: s/JSP2/ICP2/ PCH URL : https://patchwork.freedesktop.org/series/100689/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11283_full -> Patchwork_22400_full Summary --- **FAILURE**

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

On 25/02/2022 03:24, Michael Cheng wrote: Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou performs a flush by first performing a clean, follow by an invalidation operation. v2 (Michael Cheng): Use correct macro for cleaning and invalidation the dcache.

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix prime_mmap to work when using LMEM

== Series Details == Series: Fix prime_mmap to work when using LMEM URL : https://patchwork.freedesktop.org/series/100737/ State : success == Summary == CI Bug Log - changes from CI_DRM_11286 -> Patchwork_22411 Summary --- **SUCCESS*

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

On 24/02/2022 20:02, John Harrison wrote: On 2/23/2022 04:00, Tvrtko Ursulin wrote: On 23/02/2022 02:22, John Harrison wrote: On 2/22/2022 01:53, Tvrtko Ursulin wrote: On 18/02/2022 21:33, john.c.harri...@intel.com wrote: From: John Harrison Compute workloads are inherently not pre-emptib

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 2/25/2022 05:26, Tvrtko Ursulin wrote: On 25/02/2022 09:44, Michal Wajdeczko wrote: On 25.02.2022 06:03, Jordan Justen wrote: John Harrison writes: On 2/22/2022 02:36, Jordan Justen wrote: From: John Harrison Implement support for fetching the hardware description table from the GuC.

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

Hi Tvrtko, It seems without cacheflush.h being included, when I build for arm64 or x86, it stills pulls in cacheflush.h: ./.drm_cache.o.cmd:838: include/linux/cacheflush.h \ ./.drm_cache.o.cmd:839: arch/x86/include/asm/cacheflush.h \ ./.drm_cache.o.cmd:920: include/asm-generic/cacheflush.h \ .

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: Do not try loading wrong DMC version

== Series Details == Series: drm/i915/dmc: Do not try loading wrong DMC version URL : https://patchwork.freedesktop.org/series/100664/ State : success == Summary == CI Bug Log - changes from CI_DRM_11279_full -> Patchwork_22393_full Summary

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

On 24/02/2022 19:19, John Harrison wrote: [snip] ./gt/uc/intel_guc_fwif.h:   u32 execution_quantum; ./gt/uc/intel_guc_submission.c: desc->execution_quantum = engine->props.timeslice_duration_ms * 1000; ./gt/intel_engine_types.h:  unsigned long timeslice_duration_ms; tim

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/display/intel_snps_phy.c between commit: 28adef861233c ("drm/i915/dg2: Print PHY name properly on calibration error") from the drm-intel-fixes tree and commits: 84073e568eec7 ("drm/i915/dg2: P

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

On 2/25/2022 08:36, Tvrtko Ursulin wrote: On 24/02/2022 20:02, John Harrison wrote: On 2/23/2022 04:00, Tvrtko Ursulin wrote: On 23/02/2022 02:22, John Harrison wrote: On 2/22/2022 01:53, Tvrtko Ursulin wrote: On 18/02/2022 21:33, john.c.harri...@intel.com wrote: From: John Harrison Comput

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 25/02/2022 16:46, John Harrison wrote: driver we don't care that much that we failed to load HWconfig and 'notice' is enough. but I'm fine with all messages being drm_err (as we will not have to change that once again after HWconfig will be mandatory for the driver as well) I would be ag

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

On 25/02/2022 16:52, Michael Cheng wrote: Hi Tvrtko, It seems without cacheflush.h being included, when I build for arm64 or x86, it stills pulls in cacheflush.h: ./.drm_cache.o.cmd:838: include/linux/cacheflush.h \ ./.drm_cache.o.cmd:839: arch/x86/include/asm/cacheflush.h \ ./.drm_cache.o.

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

On 2/25/2022 09:06, Tvrtko Ursulin wrote: On 24/02/2022 19:19, John Harrison wrote: [snip] ./gt/uc/intel_guc_fwif.h: u32 execution_quantum; ./gt/uc/intel_guc_submission.c: desc->execution_quantum = engine->props.timeslice_duration_ms * 1000; ./gt/intel_engine_types.h:  unsigne

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

On 25/02/2022 17:11, John Harrison wrote: On 2/25/2022 08:36, Tvrtko Ursulin wrote: On 24/02/2022 20:02, John Harrison wrote: On 2/23/2022 04:00, Tvrtko Ursulin wrote: On 23/02/2022 02:22, John Harrison wrote: On 2/22/2022 01:53, Tvrtko Ursulin wrote: On 18/02/2022 21:33, john.c.harri...@i

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

Ah, thanks for pointing that out, when I do include it though, it causes a few warning other systems such as h8300 and s390. Since it is already pulled is, would it be OK to leave it out for this case? Or we could use something like !IS_H8300 and !IS_S390 around the header file? On 2022-02-2

[Intel-gfx] [PATCH 2/2] dma-resv: Fix dma_resv_held

From: Tvrtko Ursulin Avoid false positives if lock state is unknown. Signed-off-by: Tvrtko Ursulin --- include/linux/dma-resv.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index afdfdfac729f..f475814c0d7a 100644 ---

[Intel-gfx] [PATCH 1/2] drm/i915: Fix assert in i915_ggtt_pin

From: Tvrtko Ursulin Use lockdep_assert_not_held to simplify and correct the code. Otherwise false positive are hit if lock state is uknown like after a previous taint. Signed-off-by: Tvrtko Ursulin Reported-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_vma.c | 4 +--- 1 file changed, 1 ins

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

On 24/02/2022 19:51, John Harrison wrote: On 2/24/2022 11:19, John Harrison wrote: [snip] I'll change it to _uses_ and repost, then. [    7.683149] kernel BUG at drivers/gpu/drm/i915/gt/uc/intel_guc.h:367! Told you that one went bang. intel_guc_is_used ? My suggestion was intel_engine_u

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix assert in i915_ggtt_pin

On Fri, Feb 25, 2022 at 05:41:17PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Use lockdep_assert_not_held to simplify and correct the code. Otherwise > false positive are hit if lock state is uknown like after a previous > taint. > > Signed-off-by: Tvrtko Ursulin > Reported-by: Vil

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

On 2/25/2022 09:39, Tvrtko Ursulin wrote: On 25/02/2022 17:11, John Harrison wrote: On 2/25/2022 08:36, Tvrtko Ursulin wrote: On 24/02/2022 20:02, John Harrison wrote: On 2/23/2022 04:00, Tvrtko Ursulin wrote: On 23/02/2022 02:22, John Harrison wrote: On 2/22/2022 01:53, Tvrtko Ursulin wrote

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 25.02.2022 18:18, Tvrtko Ursulin wrote: > > On 25/02/2022 16:46, John Harrison wrote: > driver we don't care that much that we failed to load HWconfig and 'notice' is enough. but I'm fine with all messages being drm_err (as we will not have to change that once again

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

I'll try to simplify the discussion here: On 24/02/2022 19:45, John Harrison wrote: On 2/24/2022 03:41, Tvrtko Ursulin wrote: On 23/02/2022 20:00, John Harrison wrote: On 2/23/2022 05:58, Tvrtko Ursulin wrote: On 23/02/2022 02:45, John Harrison wrote: On 2/22/2022 03:19, Tvrtko Ursulin wro

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

On 25/02/2022 17:40, Michael Cheng wrote: Ah, thanks for pointing that out, when I do include it though, it causes a few warning other systems such as h8300 and s390. Errors look like? I haven't heard that kernel code is not allowed to include something from linux/ on some arch yet. Since

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

These seem to be pretty old arch and are day0 warnings, please refer to [1] to see the warnings. Also I am not sure why my patch series didn't append to the old one. [1] https://patchwork.freedesktop.org/patch/475829/?series=99450&rev=11 2022-02-25 10:19 a.m., Tvrtko Ursulin wrote: On 25/02/

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

On 25/02/2022 18:01, John Harrison wrote: On 2/25/2022 09:39, Tvrtko Ursulin wrote: On 25/02/2022 17:11, John Harrison wrote: On 2/25/2022 08:36, Tvrtko Ursulin wrote: On 24/02/2022 20:02, John Harrison wrote: On 2/23/2022 04:00, Tvrtko Ursulin wrote: On 23/02/2022 02:22, John Harrison wro

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 25/02/2022 18:05, Michal Wajdeczko wrote: On 25.02.2022 18:18, Tvrtko Ursulin wrote: On 25/02/2022 16:46, John Harrison wrote: driver we don't care that much that we failed to load HWconfig and 'notice' is enough. but I'm fine with all messages being drm_err (as we will not have to chan

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Do not try loading wrong DMC version

Re-reported after addressing all the failures. See below for bug id's. -Original Message- From: De Marchi, Lucas Sent: Friday, February 25, 2022 8:05 AM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/dmc: Do not try loading

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

On 25/02/2022 18:23, Michael Cheng wrote: These seem to be pretty old arch and are day0 warnings, please refer to [1] to see the warnings. Also I am not sure why my patch series didn't append to the old one. [1] https://patchwork.freedesktop.org/patch/475829/?series=99450&rev=11 include/

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

On 2/25/2022 10:14, Tvrtko Ursulin wrote: I'll try to simplify the discussion here: On 24/02/2022 19:45, John Harrison wrote: On 2/24/2022 03:41, Tvrtko Ursulin wrote: On 23/02/2022 20:00, John Harrison wrote: On 2/23/2022 05:58, Tvrtko Ursulin wrote: On 23/02/2022 02:45, John Harrison wrot

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/doc: Fix typos and update outdated structure and API names

== Series Details == Series: series starting with [1/3] drm/doc: Fix typos and update outdated structure and API names URL : https://patchwork.freedesktop.org/series/100738/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4d0e0b8642d8 drm/doc: Fix typos and update outdated struc

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/doc: Fix typos and update outdated structure and API names

== Series Details == Series: series starting with [1/3] drm/doc: Fix typos and update outdated structure and API names URL : https://patchwork.freedesktop.org/series/100738/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

On Fri, Feb 25, 2022 at 06:42:37PM +, Tvrtko Ursulin wrote: > Matthew, what do you think fix for this build warning on h8300 and s390 > should be? Or perhaps a build environment issue with kernel test robot? I'd suggest this should do the job: +++ b/include/linux/cacheflush.h @@ -4,6 +4,8 @@

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

On 2/25/2022 10:29, Tvrtko Ursulin wrote: On 25/02/2022 18:01, John Harrison wrote: On 2/25/2022 09:39, Tvrtko Ursulin wrote: On 25/02/2022 17:11, John Harrison wrote: On 2/25/2022 08:36, Tvrtko Ursulin wrote: On 24/02/2022 20:02, John Harrison wrote: On 2/23/2022 04:00, Tvrtko Ursulin wrote

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/doc: Fix typos and update outdated structure and API names

== Series Details == Series: series starting with [1/3] drm/doc: Fix typos and update outdated structure and API names URL : https://patchwork.freedesktop.org/series/100738/ State : success == Summary == CI Bug Log - changes from CI_DRM_11288 -> Patchwork_22412 ===

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Move power well code to a separate file (rev2)

On Thu, Feb 24, 2022 at 12:01:18PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Move power well code to a separate file (rev2) > URL : https://patchwork.freedesktop.org/series/100591/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11276_full ->

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev5)

== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev5) URL : https://patchwork.freedesktop.org/series/100136/ State : warning == Summary == $ dim checkpatch origin/drm-tip 903b15672dab drm/mm: Add an iterator to optimally walk over

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev5)

== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev5) URL : https://patchwork.freedesktop.org/series/100136/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Optimize CSC updates for ilk+

== Series Details == Series: drm/i915: Optimize CSC updates for ilk+ URL : https://patchwork.freedesktop.org/series/100693/ State : success == Summary == CI Bug Log - changes from CI_DRM_11285_full -> Patchwork_22402_full Summary ---

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

Hi Robin, [ +arm64 maintainers for their awareness, which would have been a good thing to do from the start ] * Thanks for adding the arm64 maintainer and sorry I didn't rope them in sooner. Why does i915 need to ensure the CPU's instruction cache is coherent with its data cache? Is it a

Re: [Intel-gfx] [PATCH V3] drm/i915/dg2: add Wa_14014947963

On Thu, Feb 17, 2022 at 03:54:09PM -0800, Matt Roper wrote: > On Thu, Feb 10, 2022 at 09:23:33PM -0800, clinton.a.tay...@intel.com wrote: > > From: Clint Taylor > > > > BSPEC: 46123 > > v2: Address review feedback [MattR] > > v3: move register definition to gt_regs [MattR] > > Cc: Matt Roper > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev5)

== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev5) URL : https://patchwork.freedesktop.org/series/100136/ State : success == Summary == CI Bug Log - changes from CI_DRM_11288 -> Patchwork_22413 ==

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Allow users to disable PSR2 (rev2)

== Series Details == Series: drm/i915/display: Allow users to disable PSR2 (rev2) URL : https://patchwork.freedesktop.org/series/100658/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11285_full -> Patchwork_22403_full Summa

[Intel-gfx] [PATCH v2 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

From: John Harrison Compute workloads are inherently not pre-emptible for long periods on current hardware. As a workaround for this, the pre-emption timeout for compute capable engines was disabled. This is undesirable with GuC submission as it prevents per engine reset of hung contexts. Hence t

[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

From: John Harrison GuC converts the pre-emption timeout and timeslice quantum values into clock ticks internally. That significantly reduces the point of 32bit overflow. On current platforms, worst case scenario is approximately 110 seconds. Rather than allowing the user to set higher values and

[Intel-gfx] [PATCH v2 0/3] Improve anti-pre-emption w/a for compute workloads

From: John Harrison Compute workloads are inherently not pre-emptible on current hardware. Thus the pre-emption timeout was disabled as a workaround to prevent unwanted resets. Instead, the hang detection was left to the heartbeat and its (longer) timeout. This is undesirable with GuC submission

[Intel-gfx] [PATCH v2 3/3] drm/i915: Improve long running OCL w/a for GuC submission

From: John Harrison A workaround was added to the driver to allow OpenCL workloads to run 'forever' by disabling pre-emption on the RCS engine for Gen12. It is not totally unbound as the heartbeat will kick in eventually and cause a reset of the hung engine. However, this does not work well in G

[Intel-gfx] ✓ Fi.CI.IGT: success for Prep work for next GuC release (rev3)

== Series Details == Series: Prep work for next GuC release (rev3) URL : https://patchwork.freedesktop.org/series/99805/ State : success == Summary == CI Bug Log - changes from CI_DRM_11285_full -> Patchwork_22404_full Summary --- **

[Intel-gfx] ✓ Fi.CI.BAT: success for iommu/vt-d: Add RPLS to quirk list to skip TE disabling (rev2)

== Series Details == Series: iommu/vt-d: Add RPLS to quirk list to skip TE disabling (rev2) URL : https://patchwork.freedesktop.org/series/100165/ State : success == Summary == CI Bug Log - changes from CI_DRM_11289 -> Patchwork_22414 Summa

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for PCI: vmd: Prevent recursive locking on interrupt allocation

== Series Details == Series: PCI: vmd: Prevent recursive locking on interrupt allocation URL : https://patchwork.freedesktop.org/series/100743/ State : warning == Summary == $ dim checkpatch origin/drm-tip cfcb4f87270d PCI: vmd: Prevent recursive locking on interrupt allocation -:12: WARNING:C

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Set "SF Partial Frame Enable" also on full update

JFYI I've been running the patch on my laptop for about a day now, flickering is totally gone and also I'm a bit astonished at the power savings! Tested-by: Lyude Paul On Thu, 2022-02-24 at 15:02 -0500, Lyude Paul wrote: > Also - I realized this is missing an appropriate Fixes: tag for the commi

[Intel-gfx] [PATCH 1/5] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v2)

Vtotal is wrong in the BIOS supplied modeline for the DSI panel on the Asus TF103C leading to the last line of the display being shown as the first line. Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa Fixed:"1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x

[Intel-gfx] [PATCH 2/5] drm/i915/vlv_dsi: Add DMI quirk for wrong panel size on Lenovo Yoga Tablet 2 series

On the Lenovo Yoga Tablet 2 830 / 1050 the VBT contains a bogus 192mm x 120mm size. This is especially a problem on the 8" 830 version which uses a 10:16 portrait screen where as the bogus size is 16:10. Add a DMI quirk to override the wrong panel size with the correct one. Note both the 10" 1050

[Intel-gfx] [PATCH 3/5] drm/i915/dsi: Add some debug logging to mipi_exec_i2c

Add some debug logging to mipi_exec_i2c, to make debugging various issues seen with it easier. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH 4/5] drm/i915/dsi: Skip MIPI I2C sequences if not listed as a I2cSerialBus resource

The current mipi_exec_i2c code uses 2 methods to find the I2C bus / adapter to use: 1) Search for an ACPI I2cSerialBus resource matching the client address from the MIPI sequence 2) Fall back to searching the adapter by the I2C bus number from the MIPI sequence if 1) fails. 1 is fine, 2 however

[Intel-gfx] [PATCH 5/5] drm/i915/vlv_dsi: Skip MIPI I2C sequences on Microsoft Surface 3

The VBT DSI MIPI sequences of the panel on the Microsoft Surface 3 contain a couple of I2c writes to what seems to be a non existing TI LP855x backlight controller, leading to the following errors: i915 :00:02.0: [drm] mipi_exec_i2c bus 5 client-addr 0x2c reg 0x01 data 01 i2c_designware 808622

[Intel-gfx] [PATCH 0/1] Fix i915 error_state_read ptr use

Fix pointer offset usage in error_state_read when there is no i915_gpu_coredump but buf offset is non-zero. Alan Previn (1): drm/i915/reset: Fix error_state_read ptr + offset use drivers/gpu/drm/i915/i915_sysfs.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.25.1

[Intel-gfx] [PATCH 1/1] drm/i915/reset: Fix error_state_read ptr + offset use

Fix our pointer offset usage in error_state_read when there is no i915_gpu_coredump but buf offset is non-zero. This fixes a kernel page fault can happen when multiple tests are running concurrently in a loop and one is producing engine resets and consuming the i915 error_state dump while the othe

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,1/2] drm/vrr: Set VRR capable prop only if it is attached to connector

== Series Details == Series: series starting with [v6,1/2] drm/vrr: Set VRR capable prop only if it is attached to connector URL : https://patchwork.freedesktop.org/series/100712/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11285_full -> Patchwork_22405_full ===

Re: [Intel-gfx] [PATCH 3/5] drm/i915/dsi: Add some debug logging to mipi_exec_i2c

Hello Hans, On 2/25/22 22:49, Hans de Goede wrote: > Add some debug logging to mipi_exec_i2c, to make debugging various > issues seen with it easier. > > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4 > 1 file changed, 4 insertions(+) > Reviewed-by

[Intel-gfx] ✓ Fi.CI.BAT: success for PCI: vmd: Prevent recursive locking on interrupt allocation

== Series Details == Series: PCI: vmd: Prevent recursive locking on interrupt allocation URL : https://patchwork.freedesktop.org/series/100743/ State : success == Summary == CI Bug Log - changes from CI_DRM_11289 -> Patchwork_22415 Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/7] drm/i915: add io_size plumbing

== Series Details == Series: series starting with [CI,1/7] drm/i915: add io_size plumbing URL : https://patchwork.freedesktop.org/series/100746/ State : warning == Summary == $ dim checkpatch origin/drm-tip b11f6dc03213 drm/i915: add io_size plumbing -:139: CHECK:PARENTHESIS_ALIGNMENT: Alignme

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/7] drm/i915: add io_size plumbing

== Series Details == Series: series starting with [CI,1/7] drm/i915: add io_size plumbing URL : https://patchwork.freedesktop.org/series/100746/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/7] drm/i915: add io_size plumbing

== Series Details == Series: series starting with [CI,1/7] drm/i915: add io_size plumbing URL : https://patchwork.freedesktop.org/series/100746/ State : success == Summary == CI Bug Log - changes from CI_DRM_11289 -> Patchwork_22416 Summary

Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.

On 2022-02-14 19:59:08 [+0100], To intel-gfx@lists.freedesktop.org wrote: > There are a few sections in the driver which are not compatible with > PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime. > > Disable the i915 driver on a PREEMPT_RT enabled kernel. This way > PREEMPT_

  1   2   >