✓ Fi.CI.BAT: success for drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL URL : https://patchwork.freedesktop.org/series/141037/ State : success == Summary == CI Bug Log - changes from CI_DRM_15648 -> Patchwork_141037v1

✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL URL : https://patchwork.freedesktop.org/series/141037/ State : warning == Summary == Error: dim checkpatch failed d44a9d257bd3 drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL -:7: W

✓ Fi.CI.BAT: success for drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev4)

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev4) URL : https://patchwork.freedesktop.org/series/140993/ State : success == Summary == CI Bug Log - changes from CI_DRM_15648 -> Patchwork_140993v4 Summ

[CI] drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL

2024-11-06 Thread Julia Filipchuk
UAPI compatiblity version 1.16.1 This patch is for testing only. If testing is successful the binary blobs will replace the major versioned '*_guc_70.bin' files for given platforms. Signed-off-by: Julia Filipchuk --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 ++-- 1 file changed, 6

✗ Fi.CI.IGT: failure for drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT URL : https://patchwork.freedesktop.org/series/141030/ State : failure == Summary == CI Bug Log - changes from CI_DRM_15648_full -> Patchwork_141030v1_full =

[PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4

2024-11-06 Thread Suraj Kandpal
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in hdcp 2.2 and we are not using an hdmi transcoder and it need to be enabled when we are using an HDMI transcoder to enable HDCP 1.4. We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so we cannot depend on the value

Re: [PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4

2024-11-06 Thread kernel test robot
Hi Suraj, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20241106] [cannot apply to linus/master drm-intel/for-linux-next-fixes drm-tip/drm-tip v6.12-rc6] [If your patch is applied to the wrong git

✓ Fi.CI.BAT: success for drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT URL : https://patchwork.freedesktop.org/series/141030/ State : success == Summary == CI Bug Log - changes from CI_DRM_15648 -> Patchwork_141030v1 ===

✗ Fi.CI.BAT: failure for drm/i915/pps: Some PPS cleanups

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/pps: Some PPS cleanups URL : https://patchwork.freedesktop.org/series/141029/ State : failure == Summary == CI Bug Log - changes from CI_DRM_15648 -> Patchwork_141029v1 Summary --- **FAILURE**

Re: [PATCH 8/8] drm/i915/debugfs: add dbuf alloc status as part of i915_ddb_info

2024-11-06 Thread Ville Syrjälä
On Tue, Nov 05, 2024 at 09:16:00AM +0200, Vinod Govindapillai wrote: > >From xe3 onwards, there is a provision to define and > use min ddb and interim ddb allocations for async flip > use case. Add the dbuf allocation status as part of > i915_ddb_info as well to show if min or interim ddb > is bein

✗ Fi.CI.BAT: failure for drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2) URL : https://patchwork.freedesktop.org/series/140282/ State : failure == Summary == CI Bug Log - changes from CI_DRM_15648 -> Patchwork_140282v2 Summary

Re: [PATCH 7/8] drm/i915/xe3: Use hw support for min/interim ddb allocations for async flip

2024-11-06 Thread Ville Syrjälä
On Tue, Nov 05, 2024 at 09:15:59AM +0200, Vinod Govindapillai wrote: > From: Stanislav Lisovskiy > > Starting from xe3, hw now is capable of switching automatically to min > ddb allocation(not using any extra blocks) or interim SAGV-adjusted > allocation in case if async flip is used. > For that

✗ Fi.CI.SPARSE: warning for drm/i915/pps: Some PPS cleanups

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/pps: Some PPS cleanups URL : https://patchwork.freedesktop.org/series/141029/ 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: war

✗ Fi.CI.CHECKPATCH: warning for drm/i915/pps: Some PPS cleanups

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/pps: Some PPS cleanups URL : https://patchwork.freedesktop.org/series/141029/ State : warning == Summary == Error: dim checkpatch failed 7be5d99fa0f8 drm/i915/pps: Store the power cycle delay without the +1 6688c47ffde8 drm/i915/pps: Decouple pps delays fr

✗ Fi.CI.SPARSE: warning for drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2) URL : https://patchwork.freedesktop.org/series/140282/ 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/dmc_wl: Fixes and enablement for Xe3_LPD (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2) URL : https://patchwork.freedesktop.org/series/140282/ State : warning == Summary == Error: dim checkpatch failed d03be180852b drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of reg.reg 8781d6c39354 drm/x

[PATCH] drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä Introduce a proper VBT->enum mipi_dsi_pixel_format converter instead of abusing pixel_format_from_register_bits() (whose job is to parse the pixel format from some pre-ICL DSI hardware register). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c

[PATCH 6/8] drm/i915/pps: Extract msecs_to_pps_units()

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä Replace all the hand rolled *10 stuff with something a bit more descriptive (msecs_to_pps_units()). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_pps.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers

[PATCH 2/8] drm/i915/pps: Decouple pps delays from VBT struct definition

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä We currently lack a proper struct definition for the VBT power squecing delays, and instead we use the same struct definition (in intel_bios.h) for both the VBT layout and our driver side state. Decouple those two things by moving the current struct into intel_vbt_defs.h and a

[PATCH 3/8] drm/i915/pps: Rename intel_pps_delay members

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä Stop using the semi-random eDP spec T1,T3,... names for the power sequencing delays, and instead call them by their human readable names. Much easier to keep track what delay goes where when you don't have to constantly cross reference against the eDP spec. Signed-off-by: Vil

[PATCH 5/8] drm/i915/pps: Spell out the eDP spec power sequencing delays a bit more clearly

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä We determine the "spec" eDP power sequencing delays by refercing some max values from the eDP spec. Write out each number from the spec explicitly instead of precomputing the final number (that's the job of the computer). Makes it a bit easier to see what the supposed spec def

[PATCH 1/8] drm/i915/pps: Store the power cycle delay without the +1

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä The code initializing the power sequencing delays is a bit hard to follow. One confusing thing is that we keep doing the +/-1 adjustment for the hardware register value in several places. Simplify this a bit by doing the adjustment only when reading or writing the actual regis

[PATCH 0/8] drm/i915/pps: Some PPS cleanups

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä I just wanted to defuse the mess around struct edp_power_seq, but ended up super confused by the PPS delay initialization code and so ended up untangling some of that mess as well. Ville Syrjälä (8): drm/i915/pps: Store the power cycle delay without the +1 drm/i915/pps: D

[PATCH 7/8] drm/i915/pps: Extract pps_units_to_msecs()

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä Add pps_units_to_msecs() as the counterpart to msecs_pps_units_to(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_pps.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/

[PATCH 4/8] drm/i915/lvds: Use struct intel_pps_delays for LVDS power sequencing

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä Reuse struct intel_pps_delays for the LVDS power sequencing delays insteda of hand rolling it all. Perhaps in the future we could reuse some of the same PPS code for both LVDS and eDP (assuming we can decouple the PPS code from intel_dp...). Signed-off-by: Ville Syrjälä ---

[PATCH 8/8] drm/i915/pps: Eliminate pointless get_delay() macro

2024-11-06 Thread Ville Syrjala
From: Ville Syrjälä Now that we have pps_units_to_msecs(), get_delay() looks rather pointless. Nuke it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_pps.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_

[PATCH v2 17/17] drm/i915/xe3lpd: Use DMC wakelock by default

2024-11-06 Thread Gustavo Sousa
Although Bspec doesn't explicitly mentions that, as of Xe3_LPD, using DMC wakelock is the officially recommended way of accessing registers that would be off during DC5/DC6 and the legacy method (where the DMC intercepts MMIO to wake up the hardware) is to be avoided. As such, update the driver to

[PATCH v2 11/17] drm/i915/dmc_wl: Deal with existing references when disabling

2024-11-06 Thread Gustavo Sousa
It is possible that there are active wakelock references at the time we are disabling the DMC wakelock mechanism. We need to deal with that in two ways: (A) Implement the missing step from Bspec: The Bspec instructs us to clear any existing wakelock request bit after disabling the mechani

[PATCH v2 14/17] drm/i915/dmc_wl: Init only after we have runtime device info

2024-11-06 Thread Gustavo Sousa
We should be able to use the DMC wakelock only if the display hardware has support for DMC. We will add a check for that in an upcoming change. Since info for DMC availability (HAS_DMC()) needs runtime device info, move the call to intel_dmc_wl_init() to a place where we know we have the hardware

[PATCH v2 09/17] drm/i915/dmc_wl: Track registers touched by the DMC

2024-11-06 Thread Gustavo Sousa
There are extra registers that require the DMC wakelock when specific dynamic DC states are in place. Those are registers that are touched by the DMC and require DC exit for proper access. Add the range tables for them and use the correct one depending on the enabled DC state. v2: - Do not look

[PATCH v2 12/17] drm/i915/dmc_wl: Couple enable/disable with dynamic DC states

2024-11-06 Thread Gustavo Sousa
Enabling and disabling the DMC wakelock should be done as part of enabling and disabling of dynamic DC states, respectively. We should not enable or disable DMC wakelock independently of DC states, otherwise we would risk ending up with an inconsistent state where dynamic DC states are enabled and

[PATCH v2 13/17] drm/i915/dmc_wl: Add and use HAS_DMC_WAKELOCK()

2024-11-06 Thread Gustavo Sousa
A HAS_DMC_WAKELOCK() macro gives more semantic than openly checking the display version. Define it and use it where appropriate. v2: - Make this patch contain only the non-functional refactor. Functional changes related to including HAS_DMC() in the macro are done in upcoming changes. (J

[PATCH v2 10/17] drm/i915/dmc_wl: Allow simpler syntax for single reg in range tables

2024-11-06 Thread Gustavo Sousa
Allow simpler syntax for defining entries for single registers in range tables. That makes them easier to type as well as to read, allowing one to quickly tell whether a range actually refers to a single register or a "true range". Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/in

[PATCH v2 15/17] drm/i915/dmc_wl: Use HAS_DMC() in HAS_DMC_WAKELOCK()

2024-11-06 Thread Gustavo Sousa
In order to be able to use the DMC wakelock, we also need to know that the display hardware has support for DMC. For that, include HAS_DMC() in the definition of HAS_DMC_WAKELOCK(). Cc: Jani Nikula Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_display_device.h | 2 +- 1 fi

[PATCH v2 16/17] drm/i915/dmc_wl: Sanitize enable_dmc_wl according to hardware support

2024-11-06 Thread Gustavo Sousa
Instead of checking for HAS_DMC_WAKELOCK() multiple times, let's use it to sanitize the enable_dmc_wl parameter and use that variable when necessary. Reviewed-by: Luca Coelho Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_dmc_wl.c | 21 ++--- 1 file changed,

[PATCH v2 08/17] drm/i915/dmc_wl: Rename lnl_wl_range to powered_off_ranges

2024-11-06 Thread Gustavo Sousa
In an upcoming change, we will add extra range tables for registers that are touched by the DMC during DC states. The range table that we are currently using is meant for registers that are powered off during DC states. As such, let's rename the table to powered_off_ranges and also add a comment re

[PATCH v2 07/17] drm/i915/dmc_wl: Extract intel_dmc_wl_reg_in_range()

2024-11-06 Thread Gustavo Sousa
We will be using more than one range table in intel_dmc_wl_check_range(). As such, move the logic to a new function and name it intel_dmc_wl_reg_in_range(). Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_dmc_wl.c | 21 +++-- 1 file changed, 11 insertions(+),

[PATCH v2 00/17] drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD

2024-11-06 Thread Gustavo Sousa
Using the DMC wakelock is the official recommendation for Xe3_LPD. This series apply fixes to the current DMC wakelock implementation and enables it by default for Xe3_LPD. The series has been tested with a PTL machine. Gustavo Sousa (17): drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of r

[PATCH v2 01/17] drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of reg.reg

2024-11-06 Thread Gustavo Sousa
The macro i915_mmio_reg_offset() is the proper interface to get a register's offset. Use that instead of looking directly at reg.reg. Cc: Jani Nikula Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_dmc_wl.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) d

[PATCH v2 05/17] drm/i915/dmc_wl: Get wakelock when disabling dynamic DC states

2024-11-06 Thread Gustavo Sousa
Bspec says that disabling dynamic DC states require taking the DMC wakelock to cause an DC exit before writing to DC_STATE_EN. Implement that. In fact, testing on PTL revealed we end up failing to exit DC5/6 without this step. Bspec: 71583 Signed-off-by: Gustavo Sousa --- .../drm/i915/display/i

[PATCH v2 06/17] drm/i915/dmc_wl: Use sentinel item for range tables

2024-11-06 Thread Gustavo Sousa
We are currently using ARRAY_SIZE() to iterate address ranges in intel_dmc_wl_check_range(). In upcoming changes, we will be using more than a single table and will extract the range checking logic into a dedicated function that takes a range table as argument. As we will not able to use ARRAY_SIZE

[PATCH v2 04/17] drm/i915/dmc_wl: Check for non-zero refcount in release work

2024-11-06 Thread Gustavo Sousa
When the DMC wakelock refcount reaches zero, we know that there are no users and that we can do the actual release operation on the hardware, which is queued with a delayed work. The idea of the delayed work is to avoid performing the release if a new lock user appears (i.e. refcount gets increment

[PATCH v2 02/17] drm/xe: Mimic i915 behavior for non-sleeping MMIO wait

2024-11-06 Thread Gustavo Sousa
In upcoming display changes, we will modify the DMC wakelock MMIO waiting code to choose a non-sleeping variant implementation, because the wakelock is also taking in atomic context. While xe provides an explicit parameter (namely "atomic") to prevent xe_mmio_wait32() from sleeping, i915 does not

[PATCH v2 03/17] drm/i915/dmc_wl: Use non-sleeping variant of MMIO wait

2024-11-06 Thread Gustavo Sousa
Some display MMIO transactions for offsets in the range that requires the DMC wakelock happen in atomic context (this has been confirmed during tests on PTL). That means that we need to use a non-sleeping variant of MMIO waiting function. Implement __intel_de_wait_for_register_atomic_nowl() and us

Re: [PATCH 08/13] drm/i915/dmc_wl: Allow simpler syntax for single reg in range tables

2024-11-06 Thread Luca Coelho
On Wed, 2024-11-06 at 09:29 -0300, Gustavo Sousa wrote: > Quoting Luca Coelho (2024-11-06 09:23:32-03:00) > > On Tue, 2024-11-05 at 10:42 -0300, Gustavo Sousa wrote: > > > Quoting Luca Coelho (2024-11-01 09:58:33-03:00) > > > > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote: > > > > > Allow

[PATCH 6.11 228/245] drm/i915/display/dp: Compute AS SDP when vrr is also enabled

2024-11-06 Thread Greg Kroah-Hartman
6.11-stable review patch. If anyone has any objections, please let me know. -- From: Mitul Golani commit eb53e5b933b9ff315087305b3dc931af3067d19c upstream. AS SDP should be computed when VRR timing generator is also enabled. Correct the compute condition to compute params of A

✗ Fi.CI.BAT: failure for drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev3)

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev3) URL : https://patchwork.freedesktop.org/series/140993/ State : failure == Summary == CI Bug Log - changes from CI_DRM_15647 -> Patchwork_140993v3 Summ

✗ Fi.CI.BAT: failure for drm/i915/dp: demote source OUI read/write failure logging to debug

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/dp: demote source OUI read/write failure logging to debug URL : https://patchwork.freedesktop.org/series/141016/ State : failure == Summary == CI Bug Log - changes from CI_DRM_15647 -> Patchwork_141016v1

Re: [PATCH 11/15] drm/i915/display: convert HAS_ULTRAJOINER() to struct intel_display

2024-11-06 Thread Govindapillai, Vinod
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote: > Convert HAS_ULTRAJOINER() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. > > Signed-off-by: Jani Nikula > --- >  drivers/gpu/drm/i915/display/intel_display.c | 10 ++

Re: [PATCH 04/13] drm/i915/dmc_wl: Get wakelock when disabling dynamic DC states

2024-11-06 Thread Luca Coelho
On Tue, 2024-11-05 at 09:44 -0300, Gustavo Sousa wrote: > Quoting Luca Coelho (2024-11-01 09:24:08-03:00) > > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote: > > > Bspec says that disabling dynamic DC states require taking the DMC > > > wakelock to cause an DC exit before writing to DC_STAT

[PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4

2024-11-06 Thread Suraj Kandpal
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in hdcp 2.2 and we are not using an hdmi transcoder and it need to be enabled when we are using an HDMI transcoder to enable HDCP 1.4. We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so we cannot depend on the value

✗ Fi.CI.SPARSE: warning for Refactor MST DSC Determination Policy (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: Refactor MST DSC Determination Policy (rev2) URL : https://patchwork.freedesktop.org/series/140832/ 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 Refactor MST DSC Determination Policy (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: Refactor MST DSC Determination Policy (rev2) URL : https://patchwork.freedesktop.org/series/140832/ State : warning == Summary == Error: dim checkpatch failed acf8c5365f33 drm/display/dsc: Refactor DRM MST DSC Determination Policy -:11: WARNING:COMMIT_LOG_LONG_LINE

✓ Fi.CI.BAT: success for Refactor MST DSC Determination Policy (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: Refactor MST DSC Determination Policy (rev2) URL : https://patchwork.freedesktop.org/series/140832/ State : success == Summary == CI Bug Log - changes from CI_DRM_15647 -> Patchwork_140832v2 Summary --- *

Re: [PATCH] drm/i915/dp: demote source OUI read/write failure logging to debug

2024-11-06 Thread Matt Roper
On Wed, Nov 06, 2024 at 06:23:25PM +0200, Jani Nikula wrote: > Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP > sinks as well") started writing source OUI for non-eDP sinks as well, > increasing the possibilities of hitting read/write failures either due > to the sink behaviour

RE: i915 potential deadlock

2024-11-06 Thread Saarinen, Jani
Hi, > -Original Message- > From: Intel-gfx On Behalf Of > Rodrigo Vivi > Sent: Tuesday, 5 November 2024 4.34 > To: Coffin, Alexander ; Auld, Matthew > ; Deak, Imre ; Syrjala, Ville > ; Vishwanathapura, Niranjana > ; andi.sh...@linux.intel.com > Cc: intel-gfx@lists.freedesktop.org; Jani Ni

✗ Fi.CI.BUILD: failure for series starting with [01/10] drm/xe: Remove double pageflip

2024-11-06 Thread Patchwork
== Series Details == Series: series starting with [01/10] drm/xe: Remove double pageflip URL : https://patchwork.freedesktop.org/series/141008/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/141008/revisions/1/mbox/ not applied Applying: drm/xe: R

Re: [PATCH 06/15] drm/i915/display: convert HAS_GMBUS_BURST_READ() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:20PM +0200, Jani Nikula wrote: > Convert HAS_GMBUS_BURST_READ() to struct intel_display. Do minimal > drive-by conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/di

Re: [PATCH 11/15] drm/i915/display: convert HAS_ULTRAJOINER() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:25PM +0200, Jani Nikula wrote: > Convert HAS_ULTRAJOINER() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display

Re: [PATCH 10/15] drm/i915/display: convert HAS_HW_SAGV_WM() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:24PM +0200, Jani Nikula wrote: > Convert HAS_HW_SAGV_WM() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/

Re: [PATCH 09/15] drm/i915/display: convert HAS_SAGV() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:23PM +0200, Jani Nikula wrote: > Convert HAS_SAGV() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > .../drm/i915/display/intel_display_

Re: [PATCH 08/15] drm/i915/display: convert HAS_MBUS_JOINING() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:22PM +0200, Jani Nikula wrote: > Convert HAS_MBUS_JOINING() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > .../drm/i915/display/intel_

Re: [PATCH 07/15] drm/i915/display: convert HAS_IPS() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:21PM +0200, Jani Nikula wrote: > Convert HAS_IPS() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/hsw_ips

RE: [PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4

2024-11-06 Thread Kandpal, Suraj
> -Original Message- > From: Nikula, Jani > Sent: Wednesday, November 6, 2024 9:59 PM > To: Kandpal, Suraj ; intel...@lists.freedesktop.org; > intel-gfx@lists.freedesktop.org > Cc: Roper, Matthew D ; Kandpal, Suraj > > Subject: Re: [PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for H

Re: [PATCH 02/15] drm/i915/display: convert HAS_D12_PLANE_MINIMIZATION() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:16PM +0200, Jani Nikula wrote: > Convert HAS_D12_PLANE_MINIMIZATION() to struct intel_display. Do minimal > drive-by conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i

Re: [PATCH 01/15] drm/i915/display: identify discrete graphics

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:15PM +0200, Jani Nikula wrote: > Identify discrete graphics separately in display, using the platform > group mechanism. This enables dropping the dependency on i915_drv.h > IS_DGFX() from display code. > > Start grouping platform groups separately in INTEL_DISPLAY_PL

Re: [PATCH 03/15] drm/i915/display: convert HAS_4TILE() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:17PM +0200, Jani Nikula wrote: > Convert HAS_4TILE() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > .../gpu/drm/i915/display/intel_dis

Re: [PATCH 05/15] drm/i915/display: convert HAS_DP20() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:19PM +0200, Jani Nikula wrote: > Convert HAS_DP20() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_

Re: [PATCH 04/15] drm/i915/display: convert HAS_DOUBLE_BUFFERED_M_N() to struct intel_display

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:18PM +0200, Jani Nikula wrote: > Convert HAS_DOUBLE_BUFFERED_M_N() to struct intel_display. Do minimal > drive-by conversions to struct intel_display in the callers while at it. Reviewed-by: Rodrigo Vivi > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915

Re: [PATCH 15/15] drm/i915/display: add mobile platform group

2024-11-06 Thread Rodrigo Vivi
On Mon, Nov 04, 2024 at 07:19:29PM +0200, Jani Nikula wrote: > Identify mobile platforms separately in display, using the platform > group mechanism. This enables dropping the dependency on i915_drv.h > IS_MOBILE() from display code. > > Signed-off-by: Jani Nikula > --- > .../drm/i915/display/in

Re: [PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4

2024-11-06 Thread Jani Nikula
On Wed, 06 Nov 2024, Suraj Kandpal wrote: > TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in > hdcp 2.2 and we are not using an hdmi transcoder and it need to be > enabled when we are using an HDMI transcoder to enable HDCP 1.4. > We use intel_de_rmw cycles to update TRANS_DDI_

Re: ✗ Fi.CI.IGT: failure for drm/dp_mst: Fix DDI function/DP2 config programming

2024-11-06 Thread Imre Deak
On Mon, Nov 04, 2024 at 04:24:24PM +, Patchwork wrote: > == Series Details == > > Series: drm/dp_mst: Fix DDI function/DP2 config programming > URL : https://patchwork.freedesktop.org/series/140732/ > State : failure Thanks for the review, patchset is pushed to drm-intel-next. The failures

[PATCH] drm/i915/dp: demote source OUI read/write failure logging to debug

2024-11-06 Thread Jani Nikula
Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP sinks as well") started writing source OUI for non-eDP sinks as well, increasing the possibilities of hitting read/write failures either due to the sink behaviour or hotplug or whatever. Even before that, commit 3fb0501f0c07 ("drm

Re: [PATCH 06/15] drm/i915/display: convert HAS_GMBUS_BURST_READ() to struct intel_display

2024-11-06 Thread Govindapillai, Vinod
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote: > Convert HAS_GMBUS_BURST_READ() to struct intel_display. Do minimal > drive-by conversions to struct intel_display in the callers while at it. > > Signed-off-by: Jani Nikula > --- >  drivers/gpu/drm/i915/display/intel_display_device.h | 2 +-

Re: [PATCH v2 2/5] drm/i915/adlp+/dp_mst: Align slave transcoder enabling with spec wrt. DDI function

2024-11-06 Thread Luca Coelho
On Thu, 2024-10-31 at 13:40 +0200, Imre Deak wrote: > On Thu, Oct 31, 2024 at 12:49:22PM +0200, Luca Coelho wrote: > > On Wed, 2024-10-30 at 21:23 +0200, Imre Deak wrote: > > > On ADLP+ during modeset enabling configure the DDI function without > > > enabling it for MST slave transcoders before pro

Re: [PATCH v2] drm/i915/display: convert display device identification to struct intel_display

2024-11-06 Thread Govindapillai, Vinod
On Tue, 2024-11-05 at 12:17 +0200, Jani Nikula wrote: > Convert intel_display_device.[ch] to struct intel_display, including > callers, but excluding intel_display_device_probe() which will be > handled in follow-up. > > v2: fix display->drm = display->drm goof-up > > Signed-off-by: Jani Nikula

✗ Fi.CI.BAT: failure for drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev2)

2024-11-06 Thread Patchwork
== Series Details == Series: drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev2) URL : https://patchwork.freedesktop.org/series/140993/ State : failure == Summary == CI Bug Log - changes from CI_DRM_15642 -> Patchwork_140993v2 Summ

Re: [PATCH 11/13] drm/i915/dmc_wl: Add and use HAS_DMC_WAKELOCK()

2024-11-06 Thread Gustavo Sousa
Quoting Jani Nikula (2024-11-06 06:25:52-03:00) >On Tue, 05 Nov 2024, Gustavo Sousa wrote: >> Quoting Gustavo Sousa (2024-10-22 08:03:39-03:00) >>>Quoting Jani Nikula (2024-10-22 06:37:51-03:00) On Mon, 21 Oct 2024, Gustavo Sousa wrote: > In order to be able to use the DMC wakelock, we al

Re: [PATCH 3/8] drm/i915/display: update use_minimal_wm0_only to use intel_display

2024-11-06 Thread Govindapillai, Vinod
On Wed, 2024-11-06 at 16:06 +0200, Ville Syrjälä wrote: > On Tue, Nov 05, 2024 at 11:08:40AM +0200, Jani Nikula wrote: > > On Tue, 05 Nov 2024, Vinod Govindapillai > > wrote: > > > Avoid using struct drm_i915_private reference and use intel_display > > > instead. This is in preparation for the re

Re: [PATCH v2] drm/i915/display: add mobile platform group

2024-11-06 Thread Govindapillai, Vinod
On Wed, 2024-11-06 at 11:27 +0200, Jani Nikula wrote: > Identify mobile platforms separately in display, using the platform > group mechanism. This enables dropping the dependency on i915_drv.h > IS_MOBILE() from display code. > > v2: Make snb_display static (kernel test robot) > > Signed-off-by:

Re: [PATCH 10/15] drm/i915/display: convert HAS_HW_SAGV_WM() to struct intel_display

2024-11-06 Thread Govindapillai, Vinod
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote: > Convert HAS_HW_SAGV_WM() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. > > Signed-off-by: Jani Nikula > --- >  drivers/gpu/drm/i915/display/intel_cursor.c   |  5 ++- >  .../drm

[PATCH 6.11 222/245] drm/i915: disable fbc due to Wa_16023588340

2024-11-06 Thread Greg Kroah-Hartman
6.11-stable review patch. If anyone has any objections, please let me know. -- From: Matthew Auld commit c55f79f317ab428ae6d005965bc07e37496f209f upstream. On BMG-G21 we need to disable fbc due to complications around the WA. v2: - Try to handle with i915_drv.h and compat la

[PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4

2024-11-06 Thread Suraj Kandpal
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in hdcp 2.2 and we are not using an hdmi transcoder and it need to be enabled when we are using an HDMI transcoder to enable HDCP 1.4. We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so we cannot depend on the value

Re: [PATCH 08/15] drm/i915/display: convert HAS_MBUS_JOINING() to struct intel_display

2024-11-06 Thread Govindapillai, Vinod
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote: > Convert HAS_MBUS_JOINING() to struct intel_display. Do minimal drive-by > conversions to struct intel_display in the callers while at it. > > Signed-off-by: Jani Nikula > --- >  .../drm/i915/display/intel_display_device.h    |  2 +- >  drive

Re: [PATCH 08/13] drm/i915/dmc_wl: Allow simpler syntax for single reg in range tables

2024-11-06 Thread Luca Coelho
On Tue, 2024-11-05 at 10:42 -0300, Gustavo Sousa wrote: > Quoting Luca Coelho (2024-11-01 09:58:33-03:00) > > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote: > > > Allow simpler syntax for defining entries for single registers in range > > > tables. That makes them easier to type as well as

[PATCH v3 1/2] drm/display/dsc: Refactor DRM MST DSC Determination Policy

2024-11-06 Thread Fangzhi Zuo
[why] How we determine the dsc_aux used for dsc decompression in drm_dp_mst_dsc_aux_for_port() today has defects: 1. The method how we determine a connected peer device is virtual or not in drm_dp_mst_is_virtual_dpcd() is not always correct. There are DP1.4 products in the market which don'

[PATCH v3 2/2] drm/display/dsc: MST DSC Interface Change

2024-11-06 Thread Fangzhi Zuo
[why] Starting from dp2 where dsc passthrough is introduced, it is required to identify the dsc passthrough aux, apart from dsc decompression aux. Existing drm_dp_mst_port function that returns dsc_aux alone is not sufficient. [how] 1. Interface change in drm_dp_mst_dsc_aux_for_port, and depende

[PATCH v3 0/2] Refactor MST DSC Determination Policy

2024-11-06 Thread Fangzhi Zuo
The patch series is to refactor existing dsc determination policy for dsc decompression and dsc passthrough given a mst output port. Original routine was written based on different peer device types which is not accurate and shows difficulty when expanding support of products that do not fully com

Re: [PATCH 08/13] drm/i915/dmc_wl: Allow simpler syntax for single reg in range tables

2024-11-06 Thread Gustavo Sousa
Quoting Luca Coelho (2024-11-06 09:23:32-03:00) >On Tue, 2024-11-05 at 10:42 -0300, Gustavo Sousa wrote: >> Quoting Luca Coelho (2024-11-01 09:58:33-03:00) >> > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote: >> > > Allow simpler syntax for defining entries for single registers in range >>

Re: [PATCH 1/4] drm/plane: Add new plane property IN_FORMATS_ASYNC

2024-11-06 Thread Ville Syrjälä
On Wed, Nov 06, 2024 at 02:32:28PM +, Murthy, Arun R wrote: > > -Original Message- > > From: Ville Syrjälä > > Sent: Wednesday, November 6, 2024 7:31 PM > > To: Murthy, Arun R > > Cc: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri- > > de...@lists.freedesktop.org

[PATCH 08/10] drm/xe: Make it possible to read instance0 MCR registers after xe_gt_mcr_init_early

2024-11-06 Thread Maarten Lankhorst
After mcr_init_early, we need to be able to do VRAM and CCS probing without hwconfig probe. Fortunately the relevant registers are all instance 0, which fortunately means no dependencies on further initialisation is required. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.o

[PATCH 09/10] drm/xe: Split init of xe_gt_init_hwconfig to xe_gt_init and *_early

2024-11-06 Thread Maarten Lankhorst
Now that we added the separate step of initialising GUC in xe_gt_init_early, it should be ok to initialise the minimum during early init, and the rest after allocations are allowed. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-9-maarte

[PATCH 07/10] drm/xe: Simplify GuC early initialisation

2024-11-06 Thread Maarten Lankhorst
Add a 2-stage GuC init. An early one for everything that is needed for VF, and a full one that loads GuC and is allowed to do allocations. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-7-maarten.lankho...@linux.intel.com Signed-off-by:

[PATCH 10/10] fixup! drm/xe/display: Add intel_plane_initial_vblank_wait

2024-11-06 Thread Maarten Lankhorst
From: Maarten Lankhorst --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c index f0f4ec2b6cc98..77eb2b763be5e 100

[PATCH 01/10] drm/xe: Remove double pageflip

2024-11-06 Thread Maarten Lankhorst
This is already handled below by fixup_initial_plane_config. Fixes: a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of ggtt") Cc: Ville Syrjälä Reviewed-by: Vinod Govindapillai Reviewed-by: Lucas De Marchi Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop

[PATCH 05/10] drm/xe/display: Use a single early init call for display

2024-11-06 Thread Maarten Lankhorst
Instead of 3 different calls, it should be safe to unify to a single call now. This makes the init sequence cleaner, and display less tangled. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-5-maarten.lankho...@linux.intel.com Signed-off-

[PATCH 06/10] drm/xe/sriov: Move VF bootstrap and query_config to vf_guc_init

2024-11-06 Thread Maarten Lankhorst
We want to split up GUC init to an alloc and noalloc part to keep the init path the same for VF and !VF as much as possible. Everything in vf_guc_init should be done as early as possible, otherwise VRAM probing becomes impossible. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedes

[PATCH 03/10] drm/xe: Move suballocator init to after display init

2024-11-06 Thread Maarten Lankhorst
No allocations should be done before we have had a chance to preserve the display fb. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-3-maarten.lankho...@linux.intel.com Signed-off-by: Maarten Lankhorst,,, --- drivers/gpu/drm/xe/xe_devi

[PATCH 04/10] drm/xe: Defer irq init until after xe_display_init_noaccel

2024-11-06 Thread Maarten Lankhorst
Technically, I believe this means that xe_display_init_noirq and xe_display_init_noaccel can be merged together now. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-4-maarten.lankho...@linux.intel.com Signed-off-by: Maarten Lankhorst,,,

[PATCH 02/10] drm/xe/display: Add intel_plane_initial_vblank_wait

2024-11-06 Thread Maarten Lankhorst
We're changing the driver to have no interrupts during early init for Xe, so we poll the PIPE_FRMSTMSMP counter instead. Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-2-maarten.lankho...@linux.intel.com Signed-off-by: Maarten Lankhorst,

  1   2   >