✗ Fi.CI.SPARSE: warning for XE HDCP Enablement (rev10)

== Series Details == Series: XE HDCP Enablement (rev10) URL : https://patchwork.freedesktop.org/series/129456/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:116:1:

[PATCH v4 4/4] drm/ttm: Allow continued swapout after -ENOSPC falure

The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock was dropped and simply restarting the iteration meant we'd likely hit the same error again on the same resource. Now that we can restart the iteration even if the lock was dropped, do that. Cc: Christian König Cc: Somalapuram

[PATCH v4 1/4] drm/ttm: Allow TTM LRU list nodes of different types

To be able to handle list unlocking while traversing the LRU list, we want the iterators not only to point to the next position of the list traversal, but to insert themselves as list nodes at that point to work around the fact that the next node might otherwise disappear from the list while the

[PATCH v4 3/4] drm/ttm, drm/amdgpu, drm/xe: Consider hitch moves within bulk sublist moves

To address the problem with hitches moving when bulk move sublists are lru-bumped, register the list cursors with the ttm_lru_bulk_move structure when traversing its list, and when lru-bumping the list, move the cursor hitch to the tail. This also means it's mandatory for drivers to call

[PATCH v4 2/4] drm/ttm: Use LRU hitches

Have iterators insert themselves into the list they are iterating over using hitch list nodes. Since only the iterator owner can remove these list nodes from the list, it's safe to unlock the list and when continuing, use them as a starting point. Due to the way LRU bumping works in TTM, newly

[PATCH v4 0/4] TTM unlockable restartable LRU list iteration

This patch-set is a prerequisite for a standalone TTM shrinker and for exhaustive TTM eviction using sleeping dma_resv locks, which is the motivation for it. Currently when unlocking the TTM lru list lock, iteration needs to be restarted from the beginning, rather from the next LRU list node.

✓ Fi.CI.BAT: success for drm/i915/guc: Use context hints for GT frequency (rev2)

== Series Details == Series: drm/i915/guc: Use context hints for GT frequency (rev2) URL : https://patchwork.freedesktop.org/series/130698/ State : success == Summary == CI Bug Log - changes from CI_DRM_14395 -> Patchwork_130698v2 Summary

✗ Fi.CI.SPARSE: warning for drm/i915/guc: Use context hints for GT frequency (rev2)

== Series Details == Series: drm/i915/guc: Use context hints for GT frequency (rev2) URL : https://patchwork.freedesktop.org/series/130698/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[bug report] drm/i915/dp: Add support for DP tunnel BW allocation

Hello Imre Deak, The patch 91888b5b1ad2: "drm/i915/dp: Add support for DP tunnel BW allocation" from Feb 26, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/gpu/drm/i915/display/intel_dp_tunnel.c:793 intel_dp_tunnel_mgr_init() warn: 'tunnel_mgr'

✗ Fi.CI.BAT: failure for Disable automatic load CCS load balancing (rev5)

== Series Details == Series: Disable automatic load CCS load balancing (rev5) URL : https://patchwork.freedesktop.org/series/129951/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14395 -> Patchwork_129951v5 Summary ---

✗ Fi.CI.CHECKPATCH: warning for Disable automatic load CCS load balancing (rev5)

== Series Details == Series: Disable automatic load CCS load balancing (rev5) URL : https://patchwork.freedesktop.org/series/129951/ State : warning == Summary == Error: dim checkpatch failed 5b93f1cd8989 drm/i915/gt: Disable HW load balancing for CCS 380b317702a8 drm/i915/gt: Refactor uabi

[PATCH 2/3] drm/i915/dsb: Fix DSB vblank waits when using VRR

From: Ville Syrjälä Looks like the undelayed vblank gets signalled exactly when the active period ends. That is a problem for DSB+VRR when we are already in vblank and expect DSB to start executing as soon as we send the push. Instead of starting the DSB just keeps on waiting for the undelayed

[PATCH 3/3] drm/i915/dsb: Always set DSB_SKIP_WAITS_EN

From: Ville Syrjälä Bspec asks us to always set the DSB_SKIP_WAITS_EN bit in DSB_CHICKEN. This seems to instruct DSB to skip vblank and scanline waits when PSR is entered. I don't think we have any cases currently where we would want to enter PSR while DSB is waiting for something, but let's

[PATCH 1/3] drm/i915/vrr: Generate VRR "safe window" for DSB

From: Ville Syrjälä Looks like TRANS_CHICKEN bit 31 means something totally different depending on the platform: TGL: generate VRR "safe window" for DSB ADL/DG2: make TRANS_SET_CONTEXT_LATENCY effective with VRR So far we've only set this on ADL/DG2, but when using DSB+VRR we also need to set

[PATCH 0/3] drm/i915: Fix DSB vblank waits with VRR

From: Ville Syrjälä Make DSB vblank waits work correctly when VRR is enabled. Ville Syrjälä (3): drm/i915/vrr: Generate VRR "safe window" for DSB drm/i915/dsb: Fix DSB vblank waits when using VRR drm/i915/dsb: Always set DSB_SKIP_WAITS_EN drivers/gpu/drm/i915/display/intel_dsb.c | 15

✗ Fi.CI.BAT: failure for Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4)

== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4) URL : https://patchwork.freedesktop.org/series/130335/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14395 -> Patchwork_130335v4 Summary

Re: [PATCH v3 3/5] drm/i915/psr: Calculate IO wake and fast wake lines for DISPLAY_VER < 12

Hi Jouni, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip next-20240305] [cannot apply to drm-intel/for-linux-next-fixes linus/master v6.8-rc7] [If your patch is applied to the wrong git

✗ Fi.CI.SPARSE: warning for Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4)

== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4) URL : https://patchwork.freedesktop.org/series/130335/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✗ Fi.CI.CHECKPATCH: warning for Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4)

== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4) URL : https://patchwork.freedesktop.org/series/130335/ State : warning == Summary == Error: dim checkpatch failed cae3f3729701 drm/i915: Enable Wa_16019325821 2048664461bf drm/i915/guc: Add support for w/a

✗ Fi.CI.BUILD: failure for Regression on linux-next (next-20240228)

== Series Details == Series: Regression on linux-next (next-20240228) URL : https://patchwork.freedesktop.org/series/130763/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/130763/revisions/1/mbox/ not applied Applying: Regression on linux-next

✗ Fi.CI.BUILD: failure for TTM unlockable restartable LRU list iteration (rev3)

== Series Details == Series: TTM unlockable restartable LRU list iteration (rev3) URL : https://patchwork.freedesktop.org/series/130001/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M]

[PATCH] drm/i915/display: Fixed a screen flickering when turning on display from off

From: Gareth Yu Turn on the panel from zero brightness of the last state, the panel was set a maximum PWM in the flow. Once the panel initialization is completed, the backlight is restored to zero brightness. There is a flckering generated. Set the brightness to the minimum value when the

[PATCH 1/4] drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file

Move intel_hdcp_gsc_message definition into intel_hdcp_gsc.c so that intel_hdcp_gsc_message can be redefined for xe as needed. --v2 -Correct commit message to reflect what patch is actually doing [Arun] Signed-off-by: Suraj Kandpal Reviewed-by: Arun R Murthy Acked-by: Jani Nikula ---

[PATCH 2/4] drm/xe/hdcp: Use xe_device struct

Use xe_device struct instead of drm_i915_private so as to not cause confusion and comply with Xe standards as drm_i915_private is xe_device under the hood. --v2 -Fix commit message [Daniele] Signed-off-by: Suraj Kandpal Reviewed-by: Arun R Murthy --- drivers/gpu/drm/xe/display/xe_hdcp_gsc.c |

[PATCH 4/4] drm/xe/hdcp: Enable HDCP for XE

Enable HDCP for Xe by defining functions which take care of interaction of HDCP as a client with the GSC CS interface. Add intel_hdcp_gsc_message to Makefile and add corresponding changes to xe_hdcp_gsc.c to make it build. --v2 -add kfree at appropriate place [Daniele] -remove useless define

[PATCH 3/4] drm/xe: Use gsc_proxy_init_done to check proxy status

Expose gsc_proxy_init_done so that we can check if gsc proxy has been initialized or not. --v2 -Check if GSC FW is enabled before taking forcewake ref [Daniele] --v3 -Directly call proxy check function inside if condition Signed-off-by: Suraj Kandpal Reviewed-by: Arun R Murthy Reviewed-by:

[PATCH 1/4] drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file

Move intel_hdcp_gsc_message definition into intel_hdcp_gsc.c so that intel_hdcp_gsc_message can be redefined for xe as needed. --v2 -Correct commit message to reflect what patch is actually doing [Arun] Signed-off-by: Suraj Kandpal Acked-by: Jani Nikula ---

[PATCH 0/4] XE HDCP Enablement

This patch series enables HDCP on XE. Mainly includes rewriting functions that were responsible for sending hdcp messages via gsc cs. Signed-off-by: Suraj Kandpal Acked-by: Lucas De Marchi Suraj Kandpal (4): drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file drm/xe/hdcp:

Re: [PATCH v2 3/3] drm/i915/bios: abstract child device expected size

On 3/5/2024 16:43, Jani Nikula wrote: On Tue, 05 Mar 2024, "Chauhan, Shekhar" wrote: On 2/26/2024 23:28, Jani Nikula wrote: Add a function to return the expected child device size. Flip the if ladder around and use the same versions as in documentation to make it easier to verify. Return an

[PATCH v4] drm/i915/guc: Use context hints for GT frequency

Allow user to provide a low latency context hint. When set, KMD sends a hint to GuC which results in special handling for this context. SLPC will ramp the GT frequency aggressively every time it switches to this context. The down freq threshold will also be lower so GuC will ramp down the GT freq

[PATCH v4 3/3] drm/i915/gt: Enable only one CCS for compute workload

Enable only one CCS engine by default with all the compute sices allocated to it. While generating the list of UABI engines to be exposed to the user, exclude any additional CCS engines beyond the first instance. This change can be tested with igt i915_query. Fixes: d2eae8e98d59 ("drm/i915/dg2:

[PATCH v4 2/3] drm/i915/gt: Refactor uabi engine class/instance list creation

For the upcoming changes we need a cleaner way to build the list of uabi engines. Suggested-by: Tvrtko Ursulin Signed-off-by: Andi Shyti Cc: # v6.2+ --- drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 - 1 file changed, 17 insertions(+), 12 deletions(-) diff --git

[PATCH v4 1/3] drm/i915/gt: Disable HW load balancing for CCS

The hardware should not dynamically balance the load between CCS engines. Wa_14019159160 recommends disabling it across all platforms. Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement") Signed-off-by: Andi Shyti Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Matt Roper Cc: # v6.2+

[PATCH v4 0/3] Disable automatic load CCS load balancing

Hi, I have to admit that v3 was a lazy attempt. This one should be on the right path. this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Assigns all the CCS slices to one single user engine. The user will then be able to

✗ Fi.CI.BAT: failure for drm/i915: Fix VMA UAF on destroy against deactivate race (rev5)

== Series Details == Series: drm/i915: Fix VMA UAF on destroy against deactivate race (rev5) URL : https://patchwork.freedesktop.org/series/129026/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14393 -> Patchwork_129026v5

✗ Fi.CI.SPARSE: warning for drm/i915: Fix VMA UAF on destroy against deactivate race (rev5)

== Series Details == Series: drm/i915: Fix VMA UAF on destroy against deactivate race (rev5) URL : https://patchwork.freedesktop.org/series/129026/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✓ Fi.CI.BAT: success for drm/i915: Unpin cursor fb only after vblank.

== Series Details == Series: drm/i915: Unpin cursor fb only after vblank. URL : https://patchwork.freedesktop.org/series/130746/ State : success == Summary == CI Bug Log - changes from CI_DRM_14393 -> Patchwork_130746v1 Summary ---

✗ Fi.CI.SPARSE: warning for drm/i915: Unpin cursor fb only after vblank.

== Series Details == Series: drm/i915: Unpin cursor fb only after vblank. URL : https://patchwork.freedesktop.org/series/130746/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✗ Fi.CI.CHECKPATCH: warning for drm/i915: Unpin cursor fb only after vblank.

== Series Details == Series: drm/i915: Unpin cursor fb only after vblank. URL : https://patchwork.freedesktop.org/series/130746/ State : warning == Summary == Error: dim checkpatch failed eb5c989a767b drm: Add drm_vblank_work_flush_all(). -:33: WARNING:WAITQUEUE_ACTIVE: waitqueue_active

✓ Fi.CI.BAT: success for IO and fast wake lines calculation and increase fw sync length (rev3)

== Series Details == Series: IO and fast wake lines calculation and increase fw sync length (rev3) URL : https://patchwork.freedesktop.org/series/130173/ State : success == Summary == CI Bug Log - changes from CI_DRM_14393 -> Patchwork_130173v3

✗ Fi.CI.SPARSE: warning for IO and fast wake lines calculation and increase fw sync length (rev3)

== Series Details == Series: IO and fast wake lines calculation and increase fw sync length (rev3) URL : https://patchwork.freedesktop.org/series/130173/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✗ Fi.CI.BAT: failure for drm/i915/dp: Enable AUX based backlight for HDR

== Series Details == Series: drm/i915/dp: Enable AUX based backlight for HDR URL : https://patchwork.freedesktop.org/series/130729/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14393 -> Patchwork_130729v1 Summary ---

Re: [PATCH v3] drm/i915/guc: Use context hints for GT frequency

On Mon, Mar 04, 2024 at 03:34:50PM -0800, Vinay Belgaumkar wrote: > Allow user to provide a low latency context hint. When set, KMD > sends a hint to GuC which results in special handling for this > context. SLPC will ramp the GT frequency aggressively every time > it switches to this context. The

Re: [PATCH v3] drm/i915/guc: Use context hints for GT frequency

On Mon, Mar 4, 2024, at 3:34 PM, Vinay Belgaumkar wrote: > Allow user to provide a low latency context hint. When set, KMD > sends a hint to GuC which results in special handling for this > context. SLPC will ramp the GT frequency aggressively every time > it switches to this context. The down

Re: [PATCH v3 3/4] drm/ttm, drm/amdgpu, drm/xe: Consider hitch moves within bulk sublist moves

Hi Thomas, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next-fixes linus/master v6.8-rc7 next-20240305] [If your patch

✗ Fi.CI.BAT: failure for drm/ci: update device type for volteer devices (rev2)

== Series Details == Series: drm/ci: update device type for volteer devices (rev2) URL : https://patchwork.freedesktop.org/series/130723/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14393 -> Patchwork_130723v2 Summary

✗ Fi.CI.CHECKPATCH: warning for drm/ci: update device type for volteer devices (rev2)

== Series Details == Series: drm/ci: update device type for volteer devices (rev2) URL : https://patchwork.freedesktop.org/series/130723/ State : warning == Summary == Error: dim checkpatch failed 1f2ef535a742 drm/ci: update device type for volteer devices -:16: WARNING:BAD_FIXES_TAG: Please

Re: [PATCH v3 2/4] drm/i915/gt: Do not exposed fused off engines.

On Fri, Mar 01, 2024 at 12:28:57AM +0100, Andi Shyti wrote: > Some of the CCS engines are disabled. They should not be listed > in the uabi_engine list, that is the list of engines that the > user can see. Fused off engines already aren't visible to userspace (or to the kernel for that matter).

✗ Fi.CI.BAT: failure for drm/i915: Use drm_printer more (rev5)

== Series Details == Series: drm/i915: Use drm_printer more (rev5) URL : https://patchwork.freedesktop.org/series/129956/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14393 -> Patchwork_129956v5 Summary ---

✗ Fi.CI.BUILD: failure for drm: enable W=1 warnings by default across the subsystem (rev4)

== Series Details == Series: drm: enable W=1 warnings by default across the subsystem (rev4) URL : https://patchwork.freedesktop.org/series/127072/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/127072/revisions/4/mbox/ not applied Applying: drm:

✗ Fi.CI.SPARSE: warning for drm/i915: Use drm_printer more (rev5)

== Series Details == Series: drm/i915: Use drm_printer more (rev5) URL : https://patchwork.freedesktop.org/series/129956/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use drm_printer more (rev5)

== Series Details == Series: drm/i915: Use drm_printer more (rev5) URL : https://patchwork.freedesktop.org/series/129956/ State : warning == Summary == Error: dim checkpatch failed 3de64739aac8 drm/i915: Indicate which pipe failed the fastset check overall 84cc770bca09 drm/i915: Include CRTC

✗ Fi.CI.BAT: failure for drm/i915: Make crtc disable more atomic

== Series Details == Series: drm/i915: Make crtc disable more atomic URL : https://patchwork.freedesktop.org/series/130715/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14392 -> Patchwork_130715v1 Summary ---

Re: [PATCH 2/2] drm/i915: Implement vblank synchronized MBUS join changes

On Wed, Feb 28, 2024 at 10:02:13AM +0200, Stanislav Lisovskiy wrote: > Currently we can't change MBUS join status without doing a modeset, > because we are lacking mechanism to synchronize those with vblank. > However then this means that we can't do a fastset, if there is a need > to change MBUS

Re: [PATCH 1/2] drm/i915: Update mbus in intel_dbuf_mbus_update and do it properly

On Wed, Feb 28, 2024 at 10:02:12AM +0200, Stanislav Lisovskiy wrote: > According to BSpec we need to do correspondent MBUS updates before > or after DBUF reallocation, depending on whether we are reducing > or increasing amount of pipes(typical scenario is swithing between > multiple and single

Re: ✗ Fi.CI.IGT: failure for drm/i915/dp: Fix connector DSC HW state readout (rev2)

On Fri, Mar 01, 2024 at 08:00:41PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/dp: Fix connector DSC HW state readout (rev2) > URL : https://patchwork.freedesktop.org/series/129540/ > State : failure Thanks for the report/testing and review, patch is pushed to

✓ Fi.CI.BAT: success for drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly

== Series Details == Series: drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly URL : https://patchwork.freedesktop.org/series/130714/ State : success == Summary == CI Bug Log - changes from CI_DRM_14392 -> Patchwork_130714v1

✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly

== Series Details == Series: drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly URL : https://patchwork.freedesktop.org/series/130714/ State : warning == Summary == Error: dim checkpatch failed 916e57569f78 drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order,

Re: [RESEND v3 0/2] drm: enable W=1 warnings by default across the subsystem

On Tue, 05 Mar 2024, Lucas De Marchi wrote: > On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote: >>Thanks everyone for acks and reviews, pushed to drm-misc-next. > > should we start removing the now duplicate ones in i915 and xe? After the drm-misc-next to drm-next merge and subsequent

Re: Regression on linux-next (next-20240228)

On Tue, Mar 05, 2024 at 06:49:16AM +, Borah, Chaitanya Kumar wrote: > Issue is still seen with the following changes > > void put_pages_list(struct list_head *pages) > > folio_batch_init(); > list_for_each_entry(folio, pages, lru) { > - if

Re: [RESEND v3 0/2] drm: enable W=1 warnings by default across the subsystem

On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote: On Tue, 05 Mar 2024, "Maxime Ripard" wrote: On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote: Resend of [1] with an intent to merge after the CI results come in. This is aiming for v6.10, so we'll have maximal time to find all

Re: [RESEND v3 0/2] drm: enable W=1 warnings by default across the subsystem

On Tue, 05 Mar 2024, "Maxime Ripard" wrote: > On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote: >> Resend of [1] with an intent to merge after the CI results come in. This >> is aiming for v6.10, so we'll have maximal time to find all the issues >> my configs didn't catch. >> >> I built this

Re: [PATCH] drm/i915/selftests: Fix dependency of some timeouts on HZ

Hi Janusz, On Thu, Feb 22, 2024 at 12:32:40PM +0100, Janusz Krzysztofik wrote: > Third argument of i915_request_wait() accepts a timeout value in jiffies. > Most users pass either a simple HZ based expression, or a result of > msecs_to_jiffies(), or MAX_SCHEDULE_TIMEOUT, or a very small number

Re: [PATCH] drm/i915/selftest_hangcheck: Check sanity with more patience

Hi Janusz, On Wed, Feb 28, 2024 at 04:24:41PM +0100, Janusz Krzysztofik wrote: > While trying to reproduce some other issues reported by CI for i915 > hangcheck live selftest, I found them hidden behind timeout failures > reported by igt_hang_sanitycheck -- the very first hangcheck test case >

Re: [PATCH] drm/i915/display: Disable AuxCCS framebuffers if built for Xe

On Wed, 28 Feb 2024, Juha-Pekka Heikkila wrote: > AuxCCS framebuffers don't work on Xe driver hence disable them > from plane capabilities until they are fixed. FlatCCS framebuffers > work and they are left enabled. CCS is left untouched for i915 > driver. > > Closes:

Re: [PATCH v7 2/6] drm/i915: Unregister in-kernel clients

On Tue, 05 Mar 2024, Rodrigo Vivi wrote: > On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote: >> Unregister all in-kernel clients before unloading the i915 driver. For >> other drivers, drm_dev_unregister() does this automatically. As i915 >> does not use this helper, it has to

Re: [PATCH v7 2/6] drm/i915: Unregister in-kernel clients

On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote: > Unregister all in-kernel clients before unloading the i915 driver. For > other drivers, drm_dev_unregister() does this automatically. As i915 > does not use this helper, it has to perform the call by itself. For xe, > do the same

[PATCH v3 4/4] drm/ttm: Allow continued swapout after -ENOSPC falure

The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock was dropped and simply restarting the iteration meant we'd likely hit the same error again on the same resource. Now that we can restart the iteration even if the lock was dropped, do that. Cc: Christian König Cc: Somalapuram

[PATCH v3 1/4] drm/ttm: Allow TTM LRU list nodes of different types

To be able to handle list unlocking while traversing the LRU list, we want the iterators not only to point to the next position of the list traversal, but to insert themselves as list nodes at that point to work around the fact that the next node might otherwise disappear from the list while the

[PATCH v3 3/4] drm/ttm, drm/amdgpu, drm/xe: Consider hitch moves within bulk sublist moves

To address the problem with hitches moving when bulk move sublists are lru-bumped, register the list cursors with the ttm_lru_bulk_move structure when traversing its list, and when lru-bumping the list, move the cursor hitch to the tail. This also means it's mandatory for drivers to call

[PATCH v3 2/4] drm/ttm: Use LRU hitches

Have iterators insert themselves into the list they are iterating over using hitch list nodes. Since only the iterator owner can remove these list nodes from the list, it's safe to unlock the list and when continuing, use them as a starting point. Due to the way LRU bumping works in TTM, newly

[PATCH v3 0/4] TTM unlockable restartable LRU list iteration

This patch-set is a prerequisite for a standalone TTM shrinker and for exhaustive TTM eviction using sleeping dma_resv locks, which is the motivation for it. Currently when unlocking the TTM lru list lock, iteration needs to be restarted from the beginning, rather from the next LRU list node.

Re: [PATCH] drm/i915/scaler: Update Pipe src size check for DISPLAY_VER >= 12

On Mon, Feb 19, 2024 at 11:22:55AM +0530, Ankit Nautiyal wrote: > For Earlier platforms, the Pipe source size is 12-bits so > max pipe source width and height is 4096. For newer platforms it is > 13-bits so theoretically max height is 8192, but maximum width > supported on a single pipe is 5120,

Re: [PATCH 3/4] drm/i915: Use pw_idx to derive PHY for ICL_LANE_ENABLE_AUX override

On Thu, Feb 29, 2024 at 10:03:56PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > We don't actually know whether we should be picking the PHY > simply based on the AUX_CH/power well, or based on the VBT > defined AUX_CH->DDI->PHY relationship. At the moment we are > doing the former for

Re: [PATCH v7 2/3] drm/i915: Remove extra multi-gt pm-references

On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote: There was an attempt to fix an issue of illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle, reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT was acquired from

Re: [PATCH v7 1/3] drm/i915/vma: Fix UAF on destroy against retire race

On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote: Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: 88811643b958 object type: i915_active

Re: [PATCH v7 3/3] Revert "drm/i915: Wait for active retire before i915_active_fini()"

On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote: This reverts commit 7a2280e8dcd2f1f436db9631287c0b21cf6a92b0, obsoleted by "drm/i915/vma: Fix UAF on destroy against retire race". Signed-off-by: Janusz Krzysztofik Cc: Nirmoy Das Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_vma.c

Re: [PATCH 1/8] drm/i915: Rename the crtc/crtc_states in the top level DDI hooks/etc

On Tue, 05 Mar 2024, Ville Syrjälä wrote: > If the spec got updated then we should probably just do a full rename > pass over the whole codebase instead of confusing things more by > mixing up the terminology. For example: Bspec 54142 for display version 12+ has some mixed old/new terminology.

Re: [PATCH 5/8] drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_state

Quoting Matt Roper (2024-03-04 20:25:31-03:00) >On Mon, Mar 04, 2024 at 03:30:24PM -0300, Gustavo Sousa wrote: >> CDCLK programming Xe2LPD always selects the CDCLK PLL as source for the > >I think something got a bit muddled while rewriting this sentence. >Maybe the first two words were supposed

Re: [PATCH 1/4] drm/i915: Rename ICL_AUX_ANAOVRD1 to ICL_PORT_TX_DW6_AUX

On Thu, Feb 29, 2024 at 10:03:54PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > ICL_AUX_ANAOVRD1 is actually ICL_PORT_TX_DW6_AUX. Give it its proper > name, and relocate to the correct file (intel_combo_phy_regs.h). > > Signed-off-by: Ville Syrjälä > --- >

Re: [PATCH 3/8] drm/i915/cdclk: Only compute squash waveform when necessary

Quoting Matt Roper (2024-03-04 19:04:19-03:00) >On Mon, Mar 04, 2024 at 03:30:22PM -0300, Gustavo Sousa wrote: >> It is no use computing the squash waveform if we are not going to use >> it. Move the call to cdclk_squash_waveform() inside the block guarded by >> HAS_CDCLK_SQUASH(dev_priv). >> >>

Re: [PATCH 2/8] drm/i915/cdclk: Add and use xe2lpd_mdclk_source_sel()

Quoting Matt Roper (2024-03-04 18:58:34-03:00) >On Mon, Mar 04, 2024 at 03:30:21PM -0300, Gustavo Sousa wrote: >> There will be future changes that rely on the source of the MDCLK. Let's >> have xe2lpd_mdclk_source_sel() as the function responsible for reporting >> that information. >> >> Bspec:

✗ Fi.CI.BAT: failure for drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13

== Series Details == Series: drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13 URL : https://patchwork.freedesktop.org/series/130710/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14388 -> Patchwork_130710v1

[PATCH v7 3/3] Revert "drm/i915: Wait for active retire before i915_active_fini()"

This reverts commit 7a2280e8dcd2f1f436db9631287c0b21cf6a92b0, obsoleted by "drm/i915/vma: Fix UAF on destroy against retire race". Signed-off-by: Janusz Krzysztofik Cc: Nirmoy Das --- drivers/gpu/drm/i915/i915_vma.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH v7 2/3] drm/i915: Remove extra multi-gt pm-references

There was an attempt to fix an issue of illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle, reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e91787

[PATCH v7 1/3] drm/i915/vma: Fix UAF on destroy against retire race

Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: 88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]

[PATCH v7 0/3] drm/i915: Fix VMA UAF on destroy against deactivate race

Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: 88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]

Re: [PATCH 1/8] drm/i915: Rename the crtc/crtc_states in the top level DDI hooks/etc

On Tue, Mar 05, 2024 at 04:07:45PM +0200, Jani Nikula wrote: > On Tue, 05 Mar 2024, Ville Syrjälä wrote: > > On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote: > >> I also wonder whether should we really emphasize things like > >> "master"/"slave" > >> in function names. I

[PATCH v2 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb safely

From: Ville Syrjälä The cursor hardware only does sync updates, and thus the hardware will be scanning out from the old fb until the next start of vblank. So in order to make the legacy cursor fastpath actually safe we should not unpin the old fb until we're sure the hardware has ceased

[PATCH v2 3/3] drm/i915: Use the same vblank worker for atomic unpin

In case of legacy cursor update, the cursor VMA needs to be unpinned only after vblank. This exceeds the lifetime of the whole atomic commit. Any trick I attempted to keep the atomic commit alive didn't work, as drm_atomic_helper_setup_commit() force throttles on any old commit that wasn't

[PATCH v2 0/3] drm/i915: Unpin cursor fb only after vblank.

Fix legacy cursor updates on xe by enforcing wait between updating registers and unpin. In comparison with previous version, there was a small bug in the atomic unpin path. In intel_plane_cleanup_fb we tried to deference plane_state after calling vblank schedule. Remove plane from atomic state

[PATCH v2 1/3] drm: Add drm_vblank_work_flush_all().

From: Maarten Lankhorst In some cases we want to flush all vblank work, right before vblank_off for example. Add a simple function to make this possible. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_vblank_work.c | 22 ++ include/drm/drm_vblank_work.h | 2

Re: [PATCH] drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly

On Tue, 05 Mar 2024, Ville Syrjala wrote: > From: Ville Syrjälä > > Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on > sequence later on icl+"), for the most part. Turns out some > machines (eg. Chuwi Minibook X) really do need that updated order. > It is also the order the Windows

Re: [PATCH 1/8] drm/i915: Rename the crtc/crtc_states in the top level DDI hooks/etc

On Tue, 05 Mar 2024, Ville Syrjälä wrote: > On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote: >> I also wonder whether should we really emphasize things like "master"/"slave" >> in function names. I thought that one idea in our refactoring was to unify >> joined pipes handling

Re: [PATCH] drm/i915/dp: Enable AUX based backlight for HDR

On Tue, 05 Mar 2024, Suraj Kandpal wrote: > As of now whenerver HDR is switched on we use the PWM to change the > backlight as opposed to AUX based backlight changes in terms of nits. > This patch writes to the appropriate DPCD registers to enable aux > based backlight using values in nits. > >

Re: [PATCH 0/4] XE HDCP Enablement

On Tue, Feb 27, 2024 at 11:02:00AM +0530, Suraj Kandpal wrote: This patch series enables HDCP on XE. Mainly includes rewriting functions that were responsible for sending hdcp messages via gsc cs. Signed-off-by: Suraj Kandpal Suraj Kandpal (4): drm/i915/hdcp: Move intel_hdcp_gsc_message def

Re: [PATCH 4/4] drm/xe/hdcp: Enable HDCP for XE

On Tue, Feb 27, 2024 at 11:02:04AM +0530, Suraj Kandpal wrote: Enable HDCP for Xe by defining functions which take care of interaction of HDCP as a client with the GSC CS interface. Add intel_hdcp_gsc_message to Makefile and add corresponding changes to xe_hdcp_gsc.c to make it build. --v2 -add

drm-tip Migration to Gitlab

Hi, In order to prepare for the drm-misc migration that should happen next week, Benjamin and I just migrated drm-tip to Gitlab. It should be effective as of 5 minutes ago, the old cgit repo being currently marked read-only, and will be setup as a mirror. Thanks to the work done last week, we

Re: [PATCH v2] drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector()

On Thu, Feb 29, 2024 at 10:07:16AM +0530, Animesh Manna wrote: > Move psr_init_dpcd() from init-connector to connector-detect > function. The dpcd probe for checking panel replay capability > for external dp connector is causing delay during boot which can > be optimized by moving dpcd probe to

Re: [PATCH v8 3/3] drm/buddy: Add user for defragmentation

Am 05.03.24 um 12:14 schrieb Paneer Selvam, Arunpravin: On 3/5/2024 4:33 PM, Paneer Selvam, Arunpravin wrote: Hi Christian, On 3/4/2024 10:09 PM, Christian König wrote: Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam: Add amdgpu driver as user for the drm buddy defragmentation.

  1   2   >