== Series Details ==
Series: drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m (rev2)
URL : https://patchwork.freedesktop.org/series/127871/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14033_full -> Patchwork_127871v2_full
== Series Details ==
Series: drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m (rev2)
URL : https://patchwork.freedesktop.org/series/127871/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127871v2
Summary
Hi Christian,
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-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc5
next-20231215]
[If your patch is applied
On Wed, Dec 13, 2023 at 02:36:40PM +0530, Nemesa Garg wrote:
> Darkscreen detection checks if all the pixels of the frame are less then
> or equal to the comparision value. The comparision value is set to 256
> i.e black. So upon getting black pixels from the pipe, the dark screen
> detect bit is
== Series Details ==
Series: drm/i915: Eaerly ggtt pinning stuff
URL : https://patchwork.freedesktop.org/series/127870/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14030_full -> Patchwork_127870v1_full
Summary
---
== Series Details ==
Series: drm/i915/display: C20 clock state verification
URL : https://patchwork.freedesktop.org/series/127858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14027_full -> Patchwork_127858v1_full
Summary
== Series Details ==
Series: drm/edid: prefer forward declarations over includes in drm_edid.h
URL : https://patchwork.freedesktop.org/series/127695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14010_full -> Patchwork_127695v1_full
== Series Details ==
Series: perf: Fix perf_event_validate_size() lockdep splat
URL : https://patchwork.freedesktop.org/series/127883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127883v1
Summary
> -Original Message-
> From: Ville Syrjala
> Sent: Friday, December 15, 2023 2:59 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Paz Zcharya ; Das, Nirmoy ;
> Sripada, Radhakrishna ; Joonas Lahtinen
>
> Subject: [PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL
> stolen memory
== Series Details ==
Series: perf: Fix perf_event_validate_size() lockdep splat
URL : https://patchwork.freedesktop.org/series/127883/
State : warning
== Summary ==
Error: dim checkpatch failed
ae4af2d14505 perf: Fix perf_event_validate_size() lockdep splat
-:23: WARNING:BAD_FIXES_TAG: Please
== Series Details ==
Series: Revert "drm/i915/gt: Temporarily disable CPU caching into DMA for MTL"
(rev2)
URL : https://patchwork.freedesktop.org/series/127763/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127763v2
== Series Details ==
Series: drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m
URL : https://patchwork.freedesktop.org/series/127871/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127871v1
Summary
---
On Thu, Dec 14, 2023 at 01:48:36PM +0200, Jouni Högander wrote:
> Pipe config check is currently ignoring vsc sdp changes completely
> if psr is enabled. We want to ignore only PSR part of it as there
> might be changes in colorimetry data. Also read back vsc_sdp when psr is
> used.
>
>
On Thu, Dec 14, 2023 at 01:48:38PM +0200, Jouni Högander wrote:
> We need to configure VSC Select field in video dip ctl if we want to have
> e.g. colorimetry date in our VSC SDP.
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +---
> 1 file changed,
== Series Details ==
Series: drm/i915: Eaerly ggtt pinning stuff
URL : https://patchwork.freedesktop.org/series/127870/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14030 -> Patchwork_127870v1
Summary
---
On Thu, Dec 14, 2023 at 01:48:37PM +0200, Jouni Högander wrote:
> VSC SDP sending is taken care by PSR HW and it's not enabled in
> VIDEO_DIP_CTL when PSR is enabled. Readback of VSC SDP is depending on
> VSC_SDP being set in intel_crtc_state->infoframes.enabled. In case of PSR
> setting this flag
On Thu, Dec 14, 2023 at 01:48:35PM +0200, Jouni Högander wrote:
> Currently colorimetry data is not added for psr1 or non-psr case.
> Fix this by adding it as needed.
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 48 ++---
> 1 file
On Thu, Dec 14, 2023 at 01:48:34PM +0200, Jouni Högander wrote:
> There is no specific reason to prepare VSC SDP for PSR case somehow
> differently. Unify PSR and non-PSR preparation.
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 43
== Series Details ==
Series: drm/i915: Eaerly ggtt pinning stuff
URL : https://patchwork.freedesktop.org/series/127870/
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: Eaerly ggtt pinning stuff
URL : https://patchwork.freedesktop.org/series/127870/
State : warning
== Summary ==
Error: dim checkpatch failed
bb26a9048f2e drm/i915/hdcp: Do intel_hdcp_component_init() much later during
init
-:14: WARNING:REPEATED_WORD:
On Fri, Dec 15, 2023 at 08:22:17AM -0800, Lucas De Marchi wrote:
> From: Mark Rutland
>
> When lockdep is enabled, the for_each_sibling_event(sibling, event)
> macro checks that event->ctx->mutex is held. When creating a new group
> leader event, we call perf_event_validate_size() on a partially
From: Mark Rutland
When lockdep is enabled, the for_each_sibling_event(sibling, event)
macro checks that event->ctx->mutex is held. When creating a new group
leader event, we call perf_event_validate_size() on a partially
initialized event where event->ctx is NULL, and so when
== Series Details ==
Series: drm/i915: (stolen) memory region related fixes (rev3)
URL : https://patchwork.freedesktop.org/series/127721/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14030 -> Patchwork_127721v3
Summary
== Series Details ==
Series: drm/i915: (stolen) memory region related fixes (rev3)
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 (rev3)
URL : https://patchwork.freedesktop.org/series/127721/
State : warning
== Summary ==
Error: dim checkpatch failed
e7cbf4e3592e drm/i915: Use struct resource for memory region IO as well
-:387:
On Fri, 15 Dec 2023, "Kahola, Mika" wrote:
>> -Original Message-
>> From: Deak, Imre
>> Sent: Friday, December 15, 2023 11:02 AM
>> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/i915/display: C20 clock state verification
>>
>> On Fri, Dec 15, 2023 at
> -Original Message-
> From: Deak, Imre
> Sent: Friday, December 15, 2023 11:02 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/display: C20 clock state verification
>
> On Fri, Dec 15, 2023 at 10:53:36AM +0200, Imre Deak wrote:
> > On Fri, Dec 15,
On 15.12.2023 11:59, Ville Syrjala wrote:
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c |
== Series Details ==
Series: drm/i915/hdcp: Fail Repeater authentication if Type1 device not present
(rev4)
URL : https://patchwork.freedesktop.org/series/127414/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14027 -> Patchwork_127414v4
== Series Details ==
Series: drm/i915/display: C20 clock state verification
URL : https://patchwork.freedesktop.org/series/127858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14027 -> Patchwork_127858v1
Summary
---
Hi Dave & Sima,
Final drm-intel-gt-next PR for v6.8.
Elimination of kmap_atomic() from the driver to allow kernel wide
cleanup. One new DG2 W/A and static checker/spelling fixes.
Best Regards,
Joonas
***
drm-intel-gt-next-2023-12-15:
Driver Changes:
- Eliminate use of kmap_atomic() in i915
Ville Syrjala writes:
Hello Ville,
> From: Ville Syrjälä
>
> The original rationale for
> commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko")
> was that depot_save_stack() (which is what we used back then)
> wasn't exported. stack_depot_save() (which is what we use now) is
On Wed, Dec 13, 2023 at 08:36:49PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Dec 11, 2023 at 10:11:34AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently async flips are busted when bigjoiner is in use.
> > As a short term fix simply reject async flips in that case.
> >
>
On Wed, Dec 13, 2023 at 05:29:12PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 13, 2023 at 05:15:06PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 13, 2023 at 01:28:15PM +0200, Lisovskiy, Stanislav wrote:
> > > On Wed, Dec 13, 2023 at 12:25:19PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
From: Ville Syrjälä
The original rationale for
commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko")
was that depot_save_stack() (which is what we used back then)
wasn't exported. stack_depot_save() (which is what we use now) is
exported however, so relax the dependency allow
From: Ville Syrjälä
If we fail to pin error_capture to the start of ggtt (which
is likely given the BIOS fb is usually there), we currently
fall back to pinning it at the next available low address.
This seems somewhat sub-optimal to me in case we later discard
the BIOS fb (fairly likely if
From: Ville Syrjälä
AFAICS there is no hardware restriction on where in ggtt
the hdcp gsc message object needs to be bound. And as it's
a regular shmem object we don't need it be in the mappabe
range either. So pin it high to make avoid needlessly
wasting the precious mappable range for it.
Cc:
From: Ville Syrjälä
intel_hdcp_component_init()->...->intel_hdcp_gsc_initialize_message()
will allocate ggtt address space for some hdcp gsc message thing.
That is currently being done way too early as we haven't even
taken over the BIOS fb yet. So this has the potential of corrupting
ggtt PTEs
From: Ville Syrjälä
Fix up an order issue with HDCP code that tries to clobber the
ggtt way too early. And try to optimize where in the ggtt we
place permanently pinned stuff.
Ville Syrjälä (3):
drm/i915/hdcp: Do intel_hdcp_component_init() much later during init
drm/i915/hdcp: Pin the hdcp
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
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
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
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_driver.c | 7 +---
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
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
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.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
1 file changed, 8 insertions(+), 7
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.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_plane_initial.c| 25 +--
1 file changed, 18
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
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
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
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.
TODO: MI_UPDATE_GTT might be interesting as an optimization
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
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.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c
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.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_memory_region.c | 18
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
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
Hi,
https://patchwork.freedesktop.org/series/127695/ - Re-reported.
Thanks,
Tejasree
-Original Message-
From: I915-ci-infra On Behalf Of
Jani Nikula
Sent: Friday, December 15, 2023 2:23 PM
To: i915-ci-in...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ✗
== Series Details ==
Series: drm/edid: prefer forward declarations over includes in drm_edid.h
URL : https://patchwork.freedesktop.org/series/127695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127695v1
On Thu, Dec 14, 2023 at 09:06:03PM +, Sripada, Radhakrishna wrote:
> HI Ville,
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, December 13, 2023 6:03 PM
> > To: Sripada, Radhakrishna
> > Cc: Joonas Lahtinen ; Das, Nirmoy
> > ; intel-gfx@lists.freedesktop.org
>
On 14/12/2023 15:04, Zhao Liu wrote:
On Thu, Dec 14, 2023 at 02:35:26PM +, Tvrtko Ursulin wrote:
Date: Thu, 14 Dec 2023 14:35:26 +
From: Tvrtko Ursulin
Subject: Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with
kmap_local_page()
On 14/12/2023 13:45, Tvrtko Ursulin wrote:
Hi Jani,
I believe that re-reporting should be an exception, not a regular activity.
Currently we do have delays in bug filing and multiple regressions active but
in general, we should work to have stable environment and reduce need of
re-report and then, information in results email about our
On Fri, Dec 15, 2023 at 11:10:52AM +0200, Ville Syrjälä wrote:
> On Fri, Dec 15, 2023 at 10:53:31AM +0200, Imre Deak wrote:
> > On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > > Add clock state verification for C20. Since we
> > > are usign either A or B contexts, which are
> > >
On Fri, Dec 15, 2023 at 10:53:31AM +0200, Imre Deak wrote:
> On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > Add clock state verification for C20. Since we
> > are usign either A or B contexts, which are
> > selected based on clock rate, we first need to
> > calculate hw clock and
On Fri, Dec 15, 2023 at 10:53:36AM +0200, Imre Deak wrote:
> On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > Add clock state verification for C20. Since we
> > are usign either A or B contexts, which are
> > selected based on clock rate, we first need to
> > calculate hw clock and
On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> Add clock state verification for C20. Since we
> are usign either A or B contexts, which are
> selected based on clock rate, we first need to
> calculate hw clock and use that clock to select
> which context we are using.
Could the
On Tue, 12 Dec 2023, Patchwork wrote:
> == Series Details ==
>
> Series: drm/edid: prefer forward declarations over includes in drm_edid.h
> URL : https://patchwork.freedesktop.org/series/127695/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14010 ->
On Fri, Dec 15, 2023 at 01:01:39AM +0200, Ville Syrjälä wrote:
> On Thu, Dec 14, 2023 at 12:06:58PM +0100, Andrzej Hajda wrote:
> >
> >
> > On 13.12.2023 17:13, Andrzej Hajda wrote:
> > > On 13.12.2023 02:37, Patchwork wrote:
> > >> *Patch Details*
> > >> *Series:* drm/i915: (stolen) memory
Add clock state verification for C20. Since we
are usign either A or B contexts, which are
selected based on clock rate, we first need to
calculate hw clock and use that clock to select
which context we are using.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8
67 matches
Mail list logo
