[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: (near)atomic gamma LUT updates via vblank workers

== Series Details == Series: drm/i915: (near)atomic gamma LUT updates via vblank workers URL : https://patchwork.freedesktop.org/series/96089/ State : success == Summary == CI Bug Log - changes from CI_DRM_10767_full -> Patchwork_21399_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp: Use DP2.0 DPCD 248h updated register/field names for DP PHY CTS

== Series Details == Series: drm/dp: Use DP2.0 DPCD 248h updated register/field names for DP PHY CTS URL : https://patchwork.freedesktop.org/series/96096/ State : success == Summary == CI Bug Log - changes from CI_DRM_10767_full -> Patchwork_21400_full =

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

Hi Dave, New drm-misc-fixes without the vc4 changes. I feel that needs some more discussion first. drm-misc-fixes-2021-10-21-1: drm-misc-fixes for v5.15-rc7: - Rebased, to remove vc4 patches. - Fix mxsfb crash on unload. - Use correct sync parameters for Feixin K101-IM2BYL02. - Assorted kmb mode

Re: [Intel-gfx] [RFC PATCH 1/4] drm/dp: Rename DPCD 248h according to DP 2.0 specs

On Wed, 20 Oct 2021, Khaled Almahallawy wrote: > DPCD 248h name was changed from “PHY_TEST_PATTERN” in DP 1.4 to > “LINK_QUAL_PATTERN_SELECT” in DP 2.0. Please use ASCII double quotes ". Please reflow the commit message to limit line lenghts to about 72 characters. > Also, DPCD 248h [6:0] is th

Re: [Intel-gfx] [RFC PATCH 0/4] drm/dp: Use DP2.0 DPCD 248h updated register/field names for DP PHY CTS

On Wed, 20 Oct 2021, Khaled Almahallawy wrote: > This series updates DPCD 248h register name and PHY test patterns names to > follow DP 2.0 Specs. > Also updates the DP PHY CTS codes of the affected drivers (i915, amd, msm) > No functional changes expected. > > Reference: “DPCD 248h/10Bh/10Ch/1

[Intel-gfx] [PATCH 0/2] Selective fetch support for biplanar formats

These patches are implementing selective update configuration for biplanar formats. Also workaround to do full fetch for multi-planar formats is reverted. Jouni Högander (2): drm/i915/display: Add initial selective fetch support for biplanar formats Revert "drm/i915/display/psr: Do full fe

[Intel-gfx] [PATCH 1/2] drm/i915/display: Add initial selective fetch support for biplanar formats

Biplanar formats are using two planes (Y and UV). This patch adds handling of Y selective fetch area by utilizing existing linked plane mechanism. Also UV plane Y offset configuration is modified according to Bspec. Signed-off-by: Jouni Högander --- drivers/gpu/drm/i915/display/intel_psr.c | 30

[Intel-gfx] [PATCH 2/2] Revert "drm/i915/display/psr: Do full fetch when handling multi-planar formats"

This reverts commit 1f61f0655b95d5b89589390e6f83c4a61d9b1e8d. Now we are supporting selective fetch for biplanar formats. We can revert WA patch which forced using full fetch for biplanar formats. Signed-off-by: Jouni Högander --- drivers/gpu/drm/i915/display/intel_psr.c | 4 1 file change

Re: [Intel-gfx] [PATCH v4 01/11] drm/i915: Add a table with a descriptor for all i915 modifiers

On Wed, 20 Oct 2021, Imre Deak wrote: > Add a table describing all the framebuffer modifiers used by i915 at one > place. This has the benefit of deduplicating the listing of supported > modifiers for each platform and checking the support of these modifiers > on a given plane. This also simplifie

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Selective fetch support for biplanar formats

== Series Details == Series: Selective fetch support for biplanar formats URL : https://patchwork.freedesktop.org/series/96113/ State : warning == Summary == $ dim checkpatch origin/drm-tip c3d07cfdcd88 drm/i915/display: Add initial selective fetch support for biplanar formats 7164a9803ffc Re

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Add initial selective fetch support for biplanar formats

On Thu, 21 Oct 2021, Jouni Högander wrote: > Biplanar formats are using two planes (Y and UV). This patch adds handling > of Y selective fetch area by utilizing existing linked plane mechanism. > Also UV plane Y offset configuration is modified according to Bspec. FYI, it's fine to add the bspec

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move function prototypes to the correct header

On Thu, 21 Oct 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > A bunch of function prototypes were left behind when the > plane/crtc code got reshuffled to new files. Move the > prototypes as well. Reviewed-by: Jani Nikula > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/d

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use vblank workers for gamma updates

On Thu, 21 Oct 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > The pipe gamma registers are single buffered so they should only > be updated during the vblank to avoid screen tearing. In fact they > really should only be updated between start of vblank and frame > start because that is the o

[Intel-gfx] [PATCH 04/28] drm/i915: Remove unused bits of i915_vma/active api

When reworking the code to move the eviction fence to the object, the best code is removed code. Remove some functions that are unused, and change the function definition if it's only used in 1 place. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura --- drivers/gpu/drm/i

[Intel-gfx] [PATCH 02/28] drm/i915: use new iterator in i915_gem_object_wait_reservation

From: Christian König Simplifying the code a bit. Signed-off-by: Christian König [mlankhorst: Handle timeout = 0 correctly, use new i915_request_wait_timeout.] Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 65 1 file changed, 20 inser

[Intel-gfx] [PATCH 06/28] drm/i915: Remove gen6_ppgtt_unpin_all

gen6_ppgtt_unpin_all is unused, kill it. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 --- drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 1 - 2 files changed, 12 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c b/driv

[Intel-gfx] [PATCH 01/28] drm/i915: Fix i915_request fence wait semantics

The i915_request fence wait behaves differently for timeout = 0 compared to expected dma-fence behavior. i915 behavior: - Unsignaled: -ETIME - Signaled: 0 (= timeout) Expected: - Unsignaled: 0 - Signaled: 1 Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_request.c | 57 +

[Intel-gfx] [PATCH 08/28] drm/i915: Create a full object for mock_ring, v2.

This allows us to finally get rid of all the assumptions that vma->obj is NULL. Changes since v1: - Ensure the mock_ring vma is pinned to prevent a fault. - Pin it high to avoid failure in evict_for_vma selftest. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/mock_engine.c | 38 ++

[Intel-gfx] [PATCH 03/28] drm/i915: Remove dma_resv_prune

The signaled bit is already used for quick testing if a fence is signaled. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/Makefile| 1 - drivers/gpu/drm/i915/dma_resv_utils.c| 17 - drivers/gpu/drm/i915/dma_resv_utils.h| 13

[Intel-gfx] [PATCH 07/28] drm/i915: Create a dummy object for gen6 ppgtt

We currently have to special case vma->obj being NULL because of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon be able to remove a few checks. As the object only exists as a fake object pointing to ggtt, we have no backing storage, so no real object is created. It just has to look real

[Intel-gfx] [PATCH 05/28] drm/i915: Slightly rework EXEC_OBJECT_CAPTURE handling, v2.

Use a single null-terminated array for simplicity instead of a linked list. This might slightly speed up execbuf when many vma's may be marked as capture, but definitely removes an allocation from a signaling path. We are not allowed to allocate memory in eb_move_to_gpu, but we can't enforce it ye

[Intel-gfx] [PATCH 12/28] drm/i915: Remove resv from i915_vma

It's just an alias to vma->obj->base.resv, no need to duplicate it. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++-- drivers/gpu/drm/i915/i915_vma.c| 9 - drivers/gpu/drm/i915/i915_vma.h

[Intel-gfx] [PATCH 10/28] drm/i915: Change shrink ordering to use locking around unbinding.

Call drop_pages with the gem object lock held, instead of the other way around. This will allow us to drop the vma bindings with the gem object lock held. We plan to require the object lock for unpinning in the future, and this is an easy target. Signed-off-by: Maarten Lankhorst Reviewed-by: Nir

[Intel-gfx] [PATCH 23/28] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors

Now that we cannot unbind kill the currently locked object directly because we're removing short term pinning, we may have to unbind the object from gtt manually, using a i915_gem_evict_vm() call. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18

[Intel-gfx] [PATCH 13/28] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members

Big delta, but boils down to moving set_pages to i915_vma.c, and removing the special handling, all callers use the defaults anyway. We only remap in ggtt, so default case will fall through. Because we still don't require locking in i915_vma_unpin(), handle this by using xchg in get_pages(), as it

[Intel-gfx] [PATCH 15/28] drm/i915: Add lock for unbinding to i915_gem_object_ggtt_pin_ww

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_gem.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 981e383d1a5d..6aa9e465b48e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/dr

[Intel-gfx] [PATCH 18/28] drm/i915: Take trylock during eviction, v2.

Now that freeing objects takes the object lock when destroying the backing pages, we can confidently take the object lock even for dead objects. Use this fact to take the object lock in the shrinker, without requiring a reference to the object, so all calls to unbind take the object lock. This is

[Intel-gfx] [PATCH 11/28] drm/i915/pm: Move CONTEXT_VALID_BIT check

Resetting will clear the CONTEXT_VALID_BIT, so wait until after that to test. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura --- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/in

[Intel-gfx] [PATCH 16/28] drm/i915: Rework context handling in hugepages selftests

In the next commit, we don't evict when refcount = 0, so we need to call drain freed objects, because we want to pin new bo's in the same place, causing a test failure. Furthermore, since each subtest is separated, it's a lot better to use i915_live_selftests, so each subtest starts with a clean s

[Intel-gfx] [PATCH 09/28] drm/i915: vma is always backed by an object.

vma->obj and vma->resv are now never NULL, and some checks can be removed. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 48 --- dr

[Intel-gfx] [PATCH 17/28] drm/i915: Ensure gem_contexts selftests work with unbind changes.

In the next commit, we don't evict when refcount = 0. igt_vm_isolation() continuously tries to pin/unpin at same address, but also calls put() on the object, which means the object may not be unpinned in time. Instead of this, re-use the same object over and over, so they can be unbound as requir

[Intel-gfx] [PATCH 24/28] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind

We want to remove more members of i915_vma, which requires the locking to be held more often. Start requiring gem object lock for i915_vma_unbind, as it's one of the callers that may unpin pages. Some special care is needed when evicting, because the last reference to the object may be held by th

[Intel-gfx] [PATCH 20/28] drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes.

Now that we require locking to evict, multiple vmas from the same object might not be evicted. This is expected and required, because execbuf will move to short-term pinning by using the lock only. This will cause these tests to fail, because they create a ton of vma's for the same object. Unbind

[Intel-gfx] [PATCH 19/28] drm/i915: Pass trylock context to callers

Signed-off-by: Maarten Lankhorst --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 -- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 4 +-- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +- drivers/gpu/drm/i915/gt/intel_engin

[Intel-gfx] [PATCH 25/28] drm/i915: Require object lock when freeing pages during destruction

TTM already requires this, and we require it for delayed destroy. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c inde

[Intel-gfx] [PATCH 14/28] drm/i915: Take object lock in i915_ggtt_pin if ww is not set

i915_vma_wait_for_bind needs the vma lock held, fix the caller. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_vma.c | 40 +++-- 1 file changed, 28 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915

[Intel-gfx] [PATCH 28/28] drm/i915: Remove short-term pins from execbuf, v4.

Add a flag PIN_VALIDATE, to indicate we don't need to pin and only protected by the object lock. This removes the need to unpin, which is done by just releasing the lock. eb_reserve is slightly reworked for readability, but the same steps are still done: - First pass pins with NONBLOCK. - Second

[Intel-gfx] [PATCH 22/28] drm/i915: Make i915_gem_evict_vm work correctly for already locked objects

i915_gem_execbuf will call i915_gem_evict_vm() after failing to pin all objects in the first round. We are about to remove those short-term pins, but even without those the objects are still locked. Add a special case to allow i915_gem_evict_vm to evict locked objects as well. This might also allo

[Intel-gfx] [PATCH 26/28] drm/i915: Remove assert_object_held_shared

This duck tape workaround is no longer required, unbind and destroy are fixed to take the obj->resv mutex before destroying and obj->mm.lock has been removed, always requiring obj->resv as well. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 ++-- drivers/g

[Intel-gfx] [PATCH 21/28] drm/i915: Drain the ttm delayed workqueue too

Be thorough.. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 22c891720c6d..7c5ed5957fe2 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu

[Intel-gfx] [PATCH 27/28] drm/i915: Remove support for unlocked i915_vma unbind

Now that we require the object lock for all ops, some code handling race conditions can be removed. This is required to not take short-term pins inside execbuf. Signed-off-by: Maarten Lankhorst Acked-by: Niranjana Vishwanathapura --- drivers/gpu/drm/i915/i915_vma.c | 40 +--

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use vblank workers for gamma updates

On Thu, Oct 21, 2021 at 01:35:12PM +0300, Jani Nikula wrote: > On Thu, 21 Oct 2021, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The pipe gamma registers are single buffered so they should only > > be updated during the vblank to avoid screen tearing. In fact they > > really should only b

Re: [Intel-gfx] [PATCH v4 01/11] drm/i915: Add a table with a descriptor for all i915 modifiers

On Thu, Oct 21, 2021 at 01:14:59PM +0300, Jani Nikula wrote: > On Wed, 20 Oct 2021, Imre Deak wrote: > > Add a table describing all the framebuffer modifiers used by i915 at one > > place. This has the benefit of deduplicating the listing of supported > > modifiers for each platform and checking t

[Intel-gfx] ✓ Fi.CI.BAT: success for Selective fetch support for biplanar formats

== Series Details == Series: Selective fetch support for biplanar formats URL : https://patchwork.freedesktop.org/series/96113/ State : success == Summary == CI Bug Log - changes from CI_DRM_10768 -> Patchwork_21401 Summary --- **SUC

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/28] drm/i915: Fix i915_request fence wait semantics

== Series Details == Series: series starting with [01/28] drm/i915: Fix i915_request fence wait semantics URL : https://patchwork.freedesktop.org/series/96115/ State : warning == Summary == $ dim checkpatch origin/drm-tip ddb763fd10e7 drm/i915: Fix i915_request fence wait semantics 0c036c1715

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/28] drm/i915: Fix i915_request fence wait semantics

== Series Details == Series: series starting with [01/28] drm/i915: Fix i915_request fence wait semantics URL : https://patchwork.freedesktop.org/series/96115/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked

[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [01/28] drm/i915: Fix i915_request fence wait semantics

== Series Details == Series: series starting with [01/28] drm/i915: Fix i915_request fence wait semantics URL : https://patchwork.freedesktop.org/series/96115/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_gem_evict.c:110: warning: Func

[Intel-gfx] [PATCH v3] drm/i915/display: program audio CDCLK-TS for keepalives

XE_LPD display adds support for display audio codec keepalive feature. This feature works also when display codec is in D3 state and the audio link is off (BCLK off). To enable this functionality, display driver must update the AUD_TS_CDCLK_M/N registers whenever CDCLK is changed. Actual timestamps

Re: [Intel-gfx] [PATCH 02/28] drm/i915: use new iterator in i915_gem_object_wait_reservation

Op 21-10-2021 om 12:38 schreef Christian König: > Am 21.10.21 um 12:35 schrieb Maarten Lankhorst: >> From: Christian König >> >> Simplifying the code a bit. >> >> Signed-off-by: Christian König >> [mlankhorst: Handle timeout = 0 correctly, use new >> i915_request_wait_timeout.] >> Signed-off-by:

Re: [Intel-gfx] [PATCH] Revert "drm/i915/bios: gracefully disable dual eDP for now"

On Tue, 19 Oct 2021, "Souza, Jose" wrote: > On Tue, 2021-10-19 at 14:43 +0300, Jani Nikula wrote: >> This reverts commit 05734ca2a8f76c9eb3890b3c9dfc3467f03105c1. >> >> It's not graceful, instead it leads to boot time warning splats in the >> case it is supposed to handle gracefully. Apparently t

Re: [Intel-gfx] [PATCH 02/28] drm/i915: use new iterator in i915_gem_object_wait_reservation

On 21/10/2021 12:06, Maarten Lankhorst wrote: Op 21-10-2021 om 12:38 schreef Christian König: Am 21.10.21 um 12:35 schrieb Maarten Lankhorst: From: Christian König Simplifying the code a bit. Signed-off-by: Christian König [mlankhorst: Handle timeout = 0 correctly, use new i915_request_wa

[Intel-gfx] [drm-intel:drm-intel-gt-next 5/10] drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:3: error: implicit declaration of function 'wbinvd_on_all_cpus'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next head: ab5d964c001b9efffcbfa4d67a30186b67d79771 commit: a035154da45d19e09dc68454673ff257a660aece [5/10] drm/i915/dmabuf: add paranoid flush-on-acquire config: x86_64-randconfig-a004-20211021 (attached as .config) compiler: clang

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/28] drm/i915: Fix i915_request fence wait semantics

== Series Details == Series: series starting with [01/28] drm/i915: Fix i915_request fence wait semantics URL : https://patchwork.freedesktop.org/series/96115/ State : success == Summary == CI Bug Log - changes from CI_DRM_10768 -> Patchwork_21402 =

Re: [Intel-gfx] [PATCH 12/28] drm/amdgpu: use new iterator in amdgpu_ttm_bo_eviction_valuable

On Tue, Oct 19, 2021 at 12:30:40PM -0400, Felix Kuehling wrote: > Am 2021-10-19 um 7:36 a.m. schrieb Christian König: > > Am 13.10.21 um 16:07 schrieb Daniel Vetter: > >> On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote: > >>> Simplifying the code a bit. > >>> > >>> Signed-off-by: Ch

Re: [Intel-gfx] [PATCH 14/28] drm/msm: use new iterator in msm_gem_describe

On Tue, Oct 19, 2021 at 01:49:08PM +0200, Christian König wrote: > Am 13.10.21 um 16:14 schrieb Daniel Vetter: > > On Tue, Oct 05, 2021 at 01:37:28PM +0200, Christian König wrote: > > > Simplifying the code a bit. Also drop the RCU read side lock since the > > > object is locked anyway. > > > > >

Re: [Intel-gfx] [PATCH 24/28] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2

On Tue, Oct 19, 2021 at 05:51:38PM +0200, Christian König wrote: > Am 19.10.21 um 16:30 schrieb Daniel Vetter: > > On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote: > > > Am 13.10.21 um 16:23 schrieb Daniel Vetter: > > > > On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wro

Re: [Intel-gfx] [PATCH 24/28] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2

On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote: > Makes the handling a bit more complex, but avoids the use of > dma_resv_get_excl_unlocked(). > > v2: improve coding and documentation > > Signed-off-by: Christian König > --- > drivers/gpu/drm/drm_gem_atomic_helper.c | 13 ++

[Intel-gfx] [PATCH 1/4] drm/i915/clflush: fixup handling of cache_dirty

In theory if clflush_work_create() somehow fails here, and we don't yet have mm.pages populated then we end up resetting cache_dirty, which is likely wrong, since that will potentially skip the flush-on-acquire, if it was needed. It looks like intel_user_framebuffer_dirty() can arrive here before

[Intel-gfx] [PATCH 4/4] drm/i915: stop setting cache_dirty on discrete

Should not be needed. Even with non-coherent display, we should be using device local-memory there, and not system memory. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 10 ++ drivers/gpu/drm/i915/gem/i915_gem_object.c | 7 +-- dr

[Intel-gfx] [PATCH 2/4] drm/i915/clflush: disallow on discrete

We seem to have an unfortunate issue where we arrive from: i915_gem_object_flush_if_display+0x86/0xd0 [i915] intel_user_framebuffer_dirty+0x1a/0x50 [i915] drm_mode_dirtyfb_ioctl+0xfb/0x1b0 Which can be before the pages are populated(and pinned for display), and so i915_gem_object_has_

[Intel-gfx] [PATCH 3/4] drm/i915: move cpu_write_needs_clflush

Move it next to its partner in crime; gpu_write_needs_clflush. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 12 drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ++- drivers/gpu/drm/i915/i915_gem.c| 2 +-

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Update boost sysfs hooks for SLPC

Please fix code style related warnings and errors from checkpatch result. On 21-10-2021 01:22, Vinay Belgaumkar wrote: Add a helper to sort through the SLPC/RPS cases of get/set methods. Boost frequency will be modified as long as it is within the constraints of RP0 and if it is different from t

Re: [Intel-gfx] [PATCH] drm/i915/gem: stop using PAGE_KERNEL_IO

On Wed, Oct 20, 2021 at 02:06:25AM -0700, Lucas De Marchi wrote: > PAGE_KERNEL_IO is only defined for x86 and is the same as PAGE_KERNEL. > Use the latter since that is also available on other archs, which should > help us getting i915 there. > > This is the same that was done done in commit 80c33

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 2/2] dma-buf: Fix dma_resv_test_signaled.

On Fri, Oct 15, 2021 at 02:56:59PM +0200, Christian König wrote: > > > Am 15.10.21 um 14:52 schrieb Maarten Lankhorst: > > Op 15-10-2021 om 14:07 schreef Christian König: > > > Am 15.10.21 um 13:57 schrieb Maarten Lankhorst: > > > > Commit 7fa828cb9265 ("dma-buf: use new iterator in > > > > dma_

[Intel-gfx] ✗ Fi.CI.IGT: failure for Selective fetch support for biplanar formats

== Series Details == Series: Selective fetch support for biplanar formats URL : https://patchwork.freedesktop.org/series/96113/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10768_full -> Patchwork_21401_full Summary --

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use vblank workers for gamma updates

On Thu, 21 Oct 2021, Ville Syrjälä wrote: > On Thu, Oct 21, 2021 at 01:35:12PM +0300, Jani Nikula wrote: >> On Thu, 21 Oct 2021, Ville Syrjala wrote: >> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c >> > b/drivers/gpu/drm/i915/display/intel_display.c >> > index 79a7552af7b5..1375d9

[Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: fix broken build

wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to include asm/smp.h here. Reported-by: kernel test robot Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/dr

[Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: drop the flush on discrete

We were overzealous here; even though discrete is non-LLC, it should still be always coherent. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/28] drm/i915: Fix i915_request fence wait semantics

== Series Details == Series: series starting with [01/28] drm/i915: Fix i915_request fence wait semantics URL : https://patchwork.freedesktop.org/series/96115/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10768_full -> Patchwork_21402_full ===

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

Hi Dave & Daniel, Here comes the final feature PR for 5.16. As the biggest thing it adds multi-LRC (parallel) submission implementation for GuC and a simplified parallel submission uAPI to go with that (only works with GuC for now). It is has a similar mission to the bonded submission uAPI, take

Re: [Intel-gfx] [PATCH v3] drm/i915/display: Wait PSR2 get out of deep sleep to update pipe

On 10/14/21 12:03 AM, Souza, Jose wrote: On Wed, 2021-10-13 at 23:39 +0300, Gwan-gyeong Mun wrote: On 10/11/21 11:53 PM, Souza, Jose wrote: On Thu, 2021-10-07 at 12:31 +0300, Gwan-gyeong Mun wrote: On 10/6/21 11:04 PM, Souza, Jose wrote: On Wed, 2021-10-06 at 11:50 +0300, Gwan-gyeong Mun

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add struct to hold IP version

On Wed, 20 Oct 2021, "Souza, Jose" wrote: > On Wed, 2021-10-20 at 12:47 +0300, Jani Nikula wrote: >> On Tue, 19 Oct 2021, José Roberto de Souza wrote: >> > The constant platform display version is not using this new struct but >> > the runtime variant will definitely use it. >> >> Cc: Some more

[Intel-gfx] [PATCH] drm/i915/cdclk: put the cdclk vtables in const data

Add the const that was accidentally left out from the vtables. Fixes: 6b4cd9cba620 ("drm/i915: constify the cdclk vtable") Cc: Dave Airlie Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_cdclk.c | 44 +++--- 1 file changed, 22 insertions(+), 22 deletions(-) di

Re: [Intel-gfx] [PATCH] drm/i915/cdclk: put the cdclk vtables in const data

On Thu, Oct 21, 2021 at 04:34:08PM +0300, Jani Nikula wrote: > Add the const that was accidentally left out from the vtables. > > Fixes: 6b4cd9cba620 ("drm/i915: constify the cdclk vtable") > Cc: Dave Airlie > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä And if you're sufficiently bo

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: program audio CDCLK-TS for keepalives (rev4)

== Series Details == Series: drm/i915/display: program audio CDCLK-TS for keepalives (rev4) URL : https://patchwork.freedesktop.org/series/94551/ State : success == Summary == CI Bug Log - changes from CI_DRM_10769 -> Patchwork_21403 Summar

Re: [Intel-gfx] [PATCH] drm/i915/cdclk: put the cdclk vtables in const data

On Thu, Oct 21, 2021 at 04:37:02PM +0300, Ville Syrjälä wrote: > On Thu, Oct 21, 2021 at 04:34:08PM +0300, Jani Nikula wrote: > > Add the const that was accidentally left out from the vtables. > > > > Fixes: 6b4cd9cba620 ("drm/i915: constify the cdclk vtable") > > Cc: Dave Airlie > > Signed-off-b

Re: [Intel-gfx] [PATCH v3 13/13] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote: > drm_get_edid() internally calls to drm_connector_update_edid_property() > and then drm_add_display_info(), which parses the EDID. > This happens in the function intel_hdmi_set_edid() and > intel_sdvo_tmds_sink_detect() (via intel_sdv

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/clflush: fixup handling of cache_dirty

== Series Details == Series: series starting with [1/4] drm/i915/clflush: fixup handling of cache_dirty URL : https://patchwork.freedesktop.org/series/96119/ State : warning == Summary == $ dim checkpatch origin/drm-tip a73be2e8149b drm/i915/clflush: fixup handling of cache_dirty b9d957e084bd

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/clflush: fixup handling of cache_dirty

== Series Details == Series: series starting with [1/4] drm/i915/clflush: fixup handling of cache_dirty URL : https://patchwork.freedesktop.org/series/96119/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked se

[Intel-gfx] [PATCH v2 00/17] drm/i915/dg2: Enabling 64k page size and flat ccs

This series introduces the enabling patches for new memory compression feature Flat CCS and 64k page support for i915 local memory, along with documentation on the uAPI impact. Included the details of the feature and the implications on the uAPI below. Which is also added into Documentation/gpu/rfc

[Intel-gfx] [PATCH v2 01/17] drm/i915: Add has_64k_pages flag

From: Stuart Summers Add a new platform flag, has_64k_pages, for platforms supporting base page sizes of 64k. Signed-off-by: Stuart Summers Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_pci.c | 2 ++ drivers/gpu/drm/i915/in

[Intel-gfx] [PATCH v2 02/17] drm/i915/xehpsdv: set min page-size to 64K

From: Matthew Auld LMEM should be allocated at 64K granularity, since 4K page support will eventually be dropped for LMEM when using the PPGTT. Signed-off-by: Matthew Auld Signed-off-by: Stuart Summers Signed-off-by: Ramalingam C Cc: Joonas Lahtinen Cc: Rodrigo Vivi --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH v2 03/17] drm/i915/xehpsdv: enforce min GTT alignment

From: Matthew Auld For local-memory objects we need to align the GTT addresses to 64K, both for the ppgtt and ggtt. Signed-off-by: Matthew Auld Signed-off-by: Stuart Summers Signed-off-by: Ramalingam C Cc: Joonas Lahtinen Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_vma.c | 9 +++--

[Intel-gfx] [PATCH v2 04/17] drm/i915: enforce min page size for scratch

From: Matthew Auld If the device needs 64K minimum GTT pages for device local-memory, like on XEHPSDV, then we need to fail the allocation if we can't meet it, instead of falling back to 4K pages, otherwise we can't safely support the insertion of device local-memory pages for this vm, since the

[Intel-gfx] [PATCH v2 06/17] drm/i915/xehpsdv: support 64K GTT pages

From: Matthew Auld XEHPSDV optimises 64K GTT pages for local-memory, since everything should be allocated at 64K granularity. We say goodbye to sparse entries, and instead get a compact 256B page-table for 64K pages, which should be more cache friendly. 4K pages for local-memory are no longer sup

[Intel-gfx] [PATCH v2 05/17] drm/i915/gtt/xehpsdv: move scratch page to system memory

From: Matthew Auld On some platforms the hw has dropped support for 4K GTT pages when dealing with LMEM, and due to the design of 64K GTT pages in the hw, we can only mark the *entire* page-table as operating in 64K GTT mode, since the enable bit is still on the pde, and not the pte. And since we

[Intel-gfx] [PATCH v2 07/17] drm/i915: Add vm min alignment support

From: Bommu Krishnaiah Replace the hard coded 4K alignment value with vm->min_alignment. Cc: Wilson Chris P Signed-off-by: Bommu Krishnaiah Signed-off-by: Ramalingam C --- .../i915/gem/selftests/i915_gem_client_blt.c | 23 --- drivers/gpu/drm/i915/gt/intel_gtt.c |

[Intel-gfx] [PATCH v2 08/17] drm/i915/selftests: account for min_alignment in GTT selftests

From: Matthew Auld We need to support vm->min_alignment > 4K, depending on the vm itself and the type of object we are inserting. With this in mind update the GTT selftests to take this into account. Signed-off-by: Matthew Auld Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/selftests/i9

[Intel-gfx] [PATCH v2 09/17] drm/i915/xehpsdv: implement memory coloring

From: Matthew Auld The basic idea is that each 2M block(page-table) has a color, depending on if the page-table is occupied by LMEM objects(64K) or SMEM objects(4K), where our goal is to prevent mixing 64K and 4K GTT pages in the page-table, which is not supported by the HW. Signed-off-by: Matth

[Intel-gfx] [PATCH v2 11/17] drm/i915/lmem: Enable lmem for platforms with Flat CCS

From: Abdiel Janulgue A portion of device memory is reserved for Flat CCS so usable device memory will be reduced by size of Flat CCS. Size of Flat CCS is specified in “XEHPSDV_FLAT_CCS_BASE_ADDR”. So to get effective device memory we need to subtract total device memory by Flat CCS memory size.

[Intel-gfx] [PATCH v2 10/17] drm/i915/xehpsdv: Add has_flat_ccs to device info

From: CQ Tang Gen12+ devices support 3D surface (buffer) compression and various compression formats. This is accomplished by an additional compression control state (CCS) stored for each surface. Gen 12 devices(TGL family and DG1) stores compression states in a separate region of memory. It is

[Intel-gfx] [PATCH v2 12/17] drm/i915/gt: Clear compress metadata for Xe_HP platforms

From: Ayaz A Siddiqui Xe-hp and latest devices support Flat CCS which reserved a portion of the device memory to store compression metadata, during the clearing of device memory buffer object we also need to clear the associated CCS buffer. Flat CCS memory can not be directly accessed by S/W. Ad

[Intel-gfx] [PATCH v2 13/17] drm/i915/dg2: Tile 4 plane format support

From: Stanislav Lisovskiy TileF(Tile4 in bspec) format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Fixed wrong case condition(Jani Nikula) - Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak) v3: - s/I915_TI

[Intel-gfx] [PATCH v2 15/17] drm/i915/uapi: document behaviour for DG2 64K support

From: Matthew Auld On discrete platforms like DG2, we need to support a minimum page size of 64K when dealing with device local-memory. This is quite tricky for various reasons, so try to document the new implicit uapi for this. v2: Fixed suggestions on formatting [Daniel] Signed-off-by: Matthe

[Intel-gfx] [PATCH v2 14/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color

From: Matt Roper DG2 unifies render compression and media compression into a single format for the first time. The programming and buffer layout is supposed to match compression on older gen12 platforms, but the actual compression algorithm is different from any previous platform; as such, we ne

[Intel-gfx] [PATCH v2 16/17] drm/i915/Flat-CCS: Document on Flat-CCS memory compression

Documents the Flat-CCS feature and kernel handling required along with modifiers used. Signed-off-by: Ramalingam C cc: Simon Ser cc: Pekka Paalanen --- drivers/gpu/drm/i915/gt/intel_migrate.c | 47 + 1 file changed, 47 insertions(+) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH v2 17/17] Doc/gpu/rfc/i915: i915 DG2 uAPI

Details of the new features getting added as part of DG2 enabling and their implicit impact on the uAPI. v2: improvised the Flat-CCS documentation [Danvet & CQ] Signed-off-by: Ramalingam C cc: Daniel Vetter cc: Matthew Auld cc: Simon Ser cc: Pekka Paalanen --- Documentation/gpu/rfc/i915_dg2

Re: [Intel-gfx] [PATCH v2 13/17] drm/i915/dg2: Tile 4 plane format support

On Thu, Oct 21, 2021 at 07:56:23PM +0530, Ramalingam C wrote: > From: Stanislav Lisovskiy > > TileF(Tile4 in bspec) format is 4K tile organized into > 64B subtiles with same basic shape as for legacy TileY > which will be supported by Display13. > > v2: - Fixed wrong case condition(Jani Nikula)

Re: [Intel-gfx] [PATCH v2 14/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color

For the include/uapi/drm/drm_fourcc.h changes: Acked-by: Simon Ser

Re: [Intel-gfx] [PATCH v2 14/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color

On Thu, Oct 21, 2021 at 07:56:24PM +0530, Ramalingam C wrote: > From: Matt Roper > > DG2 unifies render compression and media compression into a single > format for the first time. The programming and buffer layout is > supposed to match compression on older gen12 platforms, but the > actual com

  1   2   >