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 drm-intel/for-linux-next-fixes drm-xe/drm-xe-next
drm-tip/drm-tip linus/master v6.8-rc2 next-20240202]
[If your patch is applied to the wrong git
== Series Details ==
Series: drm/i915: (stolen) memory region related fixes (rev11)
URL : https://patchwork.freedesktop.org/series/127721/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14213 -> Patchwork_127721v11
Summary
-
Hi Ville,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc2 next-20240202]
[If your patch is applied to the wrong git tree, kindly drop us a
== Series Details ==
Series: drm/i915: (stolen) memory region related fixes (rev11)
URL : https://patchwork.freedesktop.org/series/127721/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: (stolen) memory region related fixes (rev11)
URL : https://patchwork.freedesktop.org/series/127721/
State : warning
== Summary ==
Error: dim checkpatch failed
25a51b5a5590 drm/i915: Use struct resource for memory region IO as well
-:388: WARNING:LONG_LINE
== Series Details ==
Series: Enable ccs compressed framebuffers on Xe2 (rev2)
URL : https://patchwork.freedesktop.org/series/129471/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14213 -> Patchwork_129471v2
Summary
---
From: Ville Syrjälä
Annotate a few more of the failure paths on the initial
BIOS fb takeover to avoid having to guess why things
aren't working the way we expect.
Reviewed-by: Uma Shankar
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_plane_initial
From: Ville Syrjälä
On MTL the GOP (for whatever reason) likes to bind its framebuffer
high up in the ggtt address space. This can conflict with whatever
ggtt_reserve_guc_top() is trying to do, and the result is that
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear
From: Ville Syrjälä
Currently we assume that we bind the BIOS fb exactly into the same
ggtt address where the BIOS left it. That is about to change, and
in order to keep intel_reuse_initial_plane_obj() working as intended
we need to compare the original ggtt offset (called 'base' here)
as opposed
From: Ville Syrjälä
The "io" address of an object is its dma address minus the
region.start. Subtract the latter to make smem_start correct.
The current code happens to work for genuine LMEM objects
as LMEM region.start==0, but for LMEMBAR stolen objects
region.start!=0.
TODO: perhaps just set s
From: Ville Syrjälä
There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.
v2: "fix" xe
Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../drm/i
From: Ville Syrjälä
Declutter initial_plane_vma() a bit by pulling the lmem and smem
readout paths into their own functions.
TODO: the smem path should still be fixed to get and validate
the dma address from the pte as well
Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
Signed-off-by
From: Ville Syrjälä
The address we read from the PTE is a dma address, not a physical
address. Rename the variable to say so.
Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
1 file chan
From: Ville Syrjälä
MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.
Reviewed-by: Uma Shankar
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_plane_initial.c| 25 +--
From: Ville Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do the
From: Ville Syrjälä
When multiple pipes are enabled by the BIOS we try to read out each
in turn. But we do the readout for the second only after the inherited
vma for the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high cachi
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
v2: Rebase
Reviewed-by: Andrzej Hajda
Acked-by: Nirmoy Das
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
drivers/gpu/drm/i
From: Ville Syrjälä
Now that the GGTT PTE updates go straight to GSMBASE (bypassing
GTTMMADR) there should be no more risk of system hangs? So the
"binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
necessary, disable it.
My main worry with the MI_UPDATE_GTT are:
- only used on this on
From: Ville Syrjälä
On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.
Note that on every other platform this itself would hang the
machine, but on MTL the system firmw
From: Ville Syrjälä
Now that intel_memory_regions_hw_probe() prints out each and every
memory region there's no reason to have ad-hoc debugs to do similar
things elsewhere.
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu
From: Ville Syrjälä
Dump the details about every memory region into dmesg at probe time.
Avoids having to dig those out from random places when debugging stuff.
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/in
From: Ville Syrjälä
mem->region is a struct resource, but mem->io_start and
mem->io_size are not for whatever reason. Let's unify this
and convert the io stuff into a struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all t
From: Ville Syrjälä
Attempt to fix the mess around stolen memory, especially on MTL
with it's special (and apparenly broken) not-actually-lmem stolen.
The series is made up of roughtly three parts:
1. General refactoring/debug improvement for mem regions
2. Deal with the broken BAR stuff on MTL
== Series Details ==
Series: drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address
URL : https://patchwork.freedesktop.org/series/129486/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14212 -> Patchwork_129486v1
===
== Series Details ==
Series: drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address
URL : https://patchwork.freedesktop.org/series/129486/
State : warning
== Summary ==
Error: dim checkpatch failed
d490bac8db7c drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg
a
On Fri, Feb 02, 2024 at 02:14:40PM -0600, Lucas De Marchi wrote:
On Fri, Feb 02, 2024 at 02:38:57PM -0500, Sasha Levin wrote:
On Fri, Feb 02, 2024 at 11:35:33AM -0600, Lucas De Marchi wrote:
On Fri, Feb 02, 2024 at 06:53:03PM +0200, Ville Syrjälä wrote:
On Thu, Feb 01, 2024 at 11:17:28AM -0800
On Fri, Feb 02, 2024 at 11:35:33AM -0600, Lucas De Marchi wrote:
> On Fri, Feb 02, 2024 at 06:53:03PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 01, 2024 at 11:17:28AM -0800, Greg KH wrote:
> > > On Thu, Feb 01, 2024 at 08:35:24PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Feb 01, 2024 at 10:16:4
On Thu, 2024-01-25 at 08:07 -0800, José Roberto de Souza wrote:
> On Thu, 2024-01-25 at 17:56 +0200, Juha-Pekka Heikkila wrote:
> > On 25.1.2024 17.28, Souza, Jose wrote:
> > > On Thu, 2024-01-25 at 17:25 +0200, Juha-Pekka Heikkila wrote:
> > > > AuxCCS framebuffers don't work on Xe driver hence di
Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS register")
defines
a new macro to calculate the DSC PPS register addresses with PPS number as an
input. This macro correctly calculates the addresses till PPS 11 since the
addresses increment by 4. So in that case the following macr
Thanks Jani, that makes sense and thanks for adding them in your suggestion.
I have made the necessary changes addressing all your review comments
and will send out a V2 for the patch.
Regards
Manasi
On Thu, Feb 1, 2024 at 3:34 PM Jani Nikula wrote:
>
> On Thu, 01 Feb 2024, Manasi Navare wrote
On Fri, Feb 02, 2024 at 02:38:57PM -0500, Sasha Levin wrote:
On Fri, Feb 02, 2024 at 11:35:33AM -0600, Lucas De Marchi wrote:
On Fri, Feb 02, 2024 at 06:53:03PM +0200, Ville Syrjälä wrote:
On Thu, Feb 01, 2024 at 11:17:28AM -0800, Greg KH wrote:
On Thu, Feb 01, 2024 at 08:35:24PM +0200, Ville
On Fri, Feb 02, 2024 at 09:58:37PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 02, 2024 at 10:12:08AM -0300, Gustavo Sousa wrote:
> > Looks like the name and description of intel_cdclk_needs_modeset()
> > became inacurate as of commit 59f9e9cab3a1 ("drm/i915: Skip modeset for
> > cdclk changes if pos
On Fri, Feb 02, 2024 at 10:12:08AM -0300, Gustavo Sousa wrote:
> Looks like the name and description of intel_cdclk_needs_modeset()
> became inacurate as of commit 59f9e9cab3a1 ("drm/i915: Skip modeset for
> cdclk changes if possible"), when it became possible to update the cdclk
> without requirin
== Series Details ==
Series: series starting with [CI,1/3] drm: Add drm_vblank_work_flush_all().
URL : https://patchwork.freedesktop.org/series/129478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14212 -> Patchwork_129478v1
===
On Fri, Feb 02, 2024 at 11:35:33AM -0600, Lucas De Marchi wrote:
On Fri, Feb 02, 2024 at 06:53:03PM +0200, Ville Syrjälä wrote:
On Thu, Feb 01, 2024 at 11:17:28AM -0800, Greg KH wrote:
On Thu, Feb 01, 2024 at 08:35:24PM +0200, Ville Syrjälä wrote:
On Thu, Feb 01, 2024 at 10:16:48AM -0800, Greg
== Series Details ==
Series: series starting with [CI,1/3] drm: Add drm_vblank_work_flush_all().
URL : https://patchwork.freedesktop.org/series/129478/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch
== Series Details ==
Series: series starting with [CI,1/3] drm: Add drm_vblank_work_flush_all().
URL : https://patchwork.freedesktop.org/series/129478/
State : warning
== Summary ==
Error: dim checkpatch failed
28807ec6d593 drm: Add drm_vblank_work_flush_all().
-:33: WARNING:WAITQUEUE_ACTIVE:
== Series Details ==
Series: Enable ccs compressed framebuffers on Xe2
URL : https://patchwork.freedesktop.org/series/129471/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14212 -> Patchwork_129471v1
Summary
---
**FA
== Series Details ==
Series: drm/i915/cdclk: Rename intel_cdclk_needs_modeset to
intel_cdclk_params_changed
URL : https://patchwork.freedesktop.org/series/129467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14212 -> Patchwork_129467v1
===
== Series Details ==
Series: Bigjoiner refactoring (rev5)
URL : https://patchwork.freedesktop.org/series/128311/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14212 -> Patchwork_128311v5
Summary
---
**FAILURE**
Se
== Series Details ==
Series: XE HDCP Enablement
URL : https://patchwork.freedesktop.org/series/129456/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14212 -> Patchwork_129456v1
Summary
---
**FAILURE**
Serious unkn
== Series Details ==
Series: Bigjoiner refactoring (rev5)
URL : https://patchwork.freedesktop.org/series/128311/
State : warning
== Summary ==
Error: dim checkpatch failed
d6545c8124d8 drm/i915: Add bigjoiner force enable option to debugfs
-:38: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 7
On Tue, Nov 07, 2023 at 02:15:03AM +0200, Imre Deak wrote:
> Enable DSC decompression for all streams. In particular atm if a sink is
> connected to a last branch device that is downstream of the first branch
> device connected to the source, decompression is not enabled for it.
> Similarly it's no
On Fri, Feb 02, 2024 at 06:53:03PM +0200, Ville Syrjälä wrote:
On Thu, Feb 01, 2024 at 11:17:28AM -0800, Greg KH wrote:
On Thu, Feb 01, 2024 at 08:35:24PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 01, 2024 at 10:16:48AM -0800, Greg KH wrote:
> > On Thu, Feb 01, 2024 at 08:05:19PM +0200, Ville Sy
== Series Details ==
Series: XE HDCP Enablement
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: warning: unrep
On Thu, Feb 01, 2024 at 11:17:28AM -0800, Greg KH wrote:
> On Thu, Feb 01, 2024 at 08:35:24PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 01, 2024 at 10:16:48AM -0800, Greg KH wrote:
> > > On Thu, Feb 01, 2024 at 08:05:19PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Feb 01, 2024 at 12:03:20PM -050
On Fri, 02 Feb 2024, Ville Syrjälä wrote:
> On Fri, Feb 02, 2024 at 05:14:37PM +0200, Jani Nikula wrote:
>> On Tue, 16 Jan 2024, Ville Syrjala wrote:
>> So this fails to build on CONFIG_DRM_XE=m, because it has its own
>> version of intel_plane_initial.c which has
>> intel_crtc_initial_plane_conf
On Fri, Feb 02, 2024 at 05:14:37PM +0200, Jani Nikula wrote:
> On Tue, 16 Jan 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > There's no reason the caller of intel_initial_plane_config() should
> > have to loop over the CRTCs. Pull the loop into the function to
> > make life simpler fo
On Fri, Feb 02, 2024 at 04:05:34PM +0200, Jani Nikula wrote:
> If the sink supports 128b/132b and single-stream sideband messaging,
> enable MST mode.
>
> With this, the topology manager will still write DP_MSTM_CTRL, which
> should be ignored by the sink. In the future,
> drm_dp_mst_topology_mgr_
On Fri, Feb 02, 2024 at 04:05:31PM +0200, Jani Nikula wrote:
> Amend drm_dp_read_mst_cap() to return an enum, indicating "none",
> "sideband messaging", or "mst". Modify all call sites to take the new
> return value into account.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Ni
On Fri, Feb 02, 2024 at 04:05:32PM +0200, Jani Nikula wrote:
> Currently we've split MST capability detection in two places,
> intel_dp_can_mst() and intel_dp_configure_mst(). They check essentially
> the same things.
>
> Move bulk of the work, including logging, to intel_dp_can_mst() and
> rename
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 cleaned
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 accessing
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 +
On Wed, 31 Jan 2024, Arun R Murthy wrote:
> With a value of '0' read from MSTM_CAP register MST to be enabled.
> DP2.1 SCR updates the spec for 128/132b DP capable supporting only one
> stream and not supporting single stream sideband MSG.
> The underlying protocol will be MST to enable use of MTP
On Tue, 16 Jan 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There's no reason the caller of intel_initial_plane_config() should
> have to loop over the CRTCs. Pull the loop into the function to
> make life simpler for the caller.
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed
With Xe2 always treat tile4 as if it was using flat ccs.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Mika Kahola
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/
This patch set touches Xe and i915 drivers. On i915 is checked if
running on Xe2 hardware and enable framebuffer ccs decompression
unconditionally for tile4 framebuffers. On Xe driver with Xe2
hardware check if ccs compression is in use and behave accordingly;
attempt to use ccs with linear and x-t
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 15/21] drm/i915/psr: Modify intel_dp_get_su_granularity
> to support panel replay
>
> Currently inte
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 14/21] drm/i915/psr: Detect panel replay selective update
> support
>
> Add new boolean to store pan
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 13/21] drm/panelreplay: dpcd register definition for
> panelreplay SU
>
> Add definitions for panel
If the sink supports 128b/132b and single-stream sideband messaging,
enable MST mode.
With this, the topology manager will still write DP_MSTM_CTRL, which
should be ignored by the sink. In the future,
drm_dp_mst_topology_mgr_set_mst() bool mst_state parameter should
probably be turned into an enum
Debug log the sink's MST capability, including single-stream sideband
messaging support, and the decision whether to enable MST mode or not.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 19 ++-
1 file changed, 14 i
Currently we've split MST capability detection in two places,
intel_dp_can_mst() and intel_dp_configure_mst(). They check essentially
the same things.
Move bulk of the work, including logging, to intel_dp_can_mst() and
rename it intel_dp_mst_detect(). Set intel_dp->is_mst there to avoid
duplicate
Amend drm_dp_read_mst_cap() to return an enum, indicating "none",
"sideband messaging", or "mst". Modify all call sites to take the new
return value into account.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++---
Draft for comments.
BR,
Jani.
Cc: Arun R Murthy
Cc: Ville Syrjälä
Jani Nikula (4):
drm/mst: read sideband messaging cap
drm/i915/dp: refactor DP MST detection and configuration
drm/i915/mst: improve debug logging of DP MST mode detect
drm/i915/mst: enable MST mode for 128b/132b single
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 11/21] drm/i915/psr: Modify VSC SDP calculation to
> support panel replay + su
>
> Current VSC SDP c
Looks like the name and description of intel_cdclk_needs_modeset()
became inacurate as of commit 59f9e9cab3a1 ("drm/i915: Skip modeset for
cdclk changes if possible"), when it became possible to update the cdclk
without requiring disabling the pipes when only changing the cd2x
divider was enough.
== Series Details ==
Series: HDCP Type1 MST fixes
URL : https://patchwork.freedesktop.org/series/129381/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14193 -> Patchwork_129381v1
Summary
---
**FAILURE**
Serious un
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 10/21] drm/i915/psr: Rename has_psr2 as
> has_sel_update
>
> We are going to reuse has_psr2 for pane
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 09/21] drm/i915/psr: Panel replay has to be enabled
> before link training
>
> Panel replay has to b
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 08/21] drm/i915/psr: Unify panel replay enable/disable
> sink
>
> Unify enabling and disabling of ps
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 07/21] drm/i915/psr: Do not write registers/bits not
> applicable for panel replay
>
> From bspec:
>
On 2/2/2024 12:08 PM, Suraj Kandpal wrote:
Create a remote HDCP capability shim function which can read the
remote monitor HDCP capability when in MST configuration.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_display_types.h| 4
drivers/gpu/drm/i915/display/intel
Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
slave crtcs should be handled by master hooks. Same for encoders.
That way we can also remove a bunch of checks like
intel_crtc_is_bigjoiner_slave.
v2: Get rid of master vs slave checks and separation in crtc enable/disable
ho
== Series Details ==
Series: drm: Check polling initialized before
URL : https://patchwork.freedesktop.org/series/129454/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14211 -> Patchwork_129454v1
Summary
---
**SUCCES
On 2/2/2024 12:08 PM, Suraj Kandpal wrote:
Currently we are only checking capability of remote device and not
immediate downstream device but during capability check we need are
concerned with only the HDCP capability of downstream device.
During i915_display_info reporting we need HDCP Capabil
== Series Details ==
Series: series starting with [PATCHv2,1/2] drm/display/dp: Check for MSTM_CAP
before MSTM_CTRL write (rev2)
URL : https://patchwork.freedesktop.org/series/129361/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14211 -> Patchwork_129361v2
==
On Thu, 01 Feb 2024, Jani Nikula wrote:
> On Thu, 01 Feb 2024, Paz Zcharya wrote:
>> Thank you so much for the super prompt reply!
>
> FYI, looks like we've got some hiccup in CI, will merge after we get
> results.
Pushed to drm-intel-next, thanks for the patch.
BR,
Jani.
--
Jani Nikula, Inte
== Series Details ==
Series: series starting with [PATCHv2,1/2] drm/display/dp: Check for MSTM_CAP
before MSTM_CTRL write (rev2)
URL : https://patchwork.freedesktop.org/series/129361/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won
== Series Details ==
Series: series starting with [1/3] drm/i915/bios: bump expected child device
size (rev2)
URL : https://patchwork.freedesktop.org/series/129378/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14211 -> Patchwork_129378v2
=
== Series Details ==
Series: series starting with [1/3] drm/i915/bios: bump expected child device
size (rev2)
URL : https://patchwork.freedesktop.org/series/129378/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separ
Add intel_hdcp_gsc_message to Makefile and add corresponding
changes to xe_hdcp_gsc.c to make it build.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 19 +++
2 files changed, 20 insertions(+)
diff --g
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 188 ++-
1 file changed, 184 insertions(+), 4 deletions(-)
diff --git a/drivers/
Move intel_hdcp_gsc_message definition into intel_hdcp_gsc_message.c
so that intel_hdcp_gsc_message can be redefined for xe as needed.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 6 ++
drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 7 +--
2 files cha
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 (3):
drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file
drm/xe/hdcp: Enable HDCP for XE
drm/xe/
In function drm_helper_probe_single_connector_modes() when we enable
polling again, if it is already uninitialized, a warning is reported.
This patch fixes the warning message by checking if poll is initialized
before enabling it.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe
In drm_kms_helper_poll_disable() check if output polling
support is initialized before disabling polling. If not flag
this as a warning.
Additionally in drm_mode_config_helper_suspend() and
drm_mode_config_helper_resume() calls, that re the callers of these
functions, avoid invoking them if polling
This patchset consists of sanity checks before enabling/disabling
output polling to make sure we do not call polling enable and disable
functions when polling for the device is not initialized or is now
uninitialized(by drm_kms_helper_poll_fini() function)
The first patch consists of these checks
On Fri, 2024-02-02 at 08:10 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, January 19, 2024 3:40 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Manna, Animesh ; Hogander, Jouni
> >
> > Subject: [PATCH v3 06/21] drm/i915/psr: Check
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 06/21] drm/i915/psr: Check possible errors for panel
> replay as well
>
> On HPD interrupt we want t
91 matches
Mail list logo
