== Series Details ==
Series: drm/i915/fb: Deal with Mesa clear color alignment regression
URL : https://patchwork.freedesktop.org/series/141911/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15761 -> Patchwork_141911v1
Summ
== Series Details ==
Series: drm/i915/fb: Deal with Mesa clear color alignment regression
URL : https://patchwork.freedesktop.org/series/141911/
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/fb: Deal with Mesa clear color alignment regression
URL : https://patchwork.freedesktop.org/series/141911/
State : warning
== Summary ==
Error: dim checkpatch failed
a1a9f5ac1652 drm/i915/fb: Relax clear color alignment to 64 bytes
-:46: WARNING:MISSING_FI
From: Ville Syrjälä
Document the fact that the Intel clear color offset and pitch
must be 64 byte aligned.
Cc: Sagar Ghuge
Cc: Nanley Chery
Cc: Xi Ruoyao
Link:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/17f97a69c13832a6c1b0b3aad45b06f07d4b852f
Signed-off-by: Ville Syrjälä
---
includ
From: Ville Syrjälä
Mesa changed its clear color alignment without informing the kernel,
and now the kernel expects 4k alignment whereas Mesa only guaratees
64 bytes. Reduce the kernel alignment requirement to the same 64 bytes
since there's no real reason for the current 4k limit. And while at i
From: Ville Syrjälä
Make sure the user supplied offset[] for the clear color plane
fits within the actual BO. Note that we use tile units to track
the size here. All the other color/aux planes are already
being checked correctly.
Cc: Sagar Ghuge
Cc: Nanley Chery
Cc: Xi Ruoyao
Signed-off-by: V
From: Ville Syrjälä
We're currently failing to provide any debug output when the
user passes in a misaligned offset for the clear color plane.
Add some debugs prints to make debugging actually possible.
Cc: Sagar Ghuge
Cc: Nanley Chery
Cc: Xi Ruoyao
Signed-off-by: Ville Syrjälä
---
drivers/
From: Ville Syrjälä
Mesa changed its clear color alignment from 4k to 64 bytes
without informing the kernel side about the change. This
is now likely to cause framebuffer creation to fail.
The only thing we do with the clear color buffer in i915 is:
1. map a single page
2. read out bytes 16-23 f
== Series Details ==
Series: drm/modes: Fix div-by-zero in drm_mode_vrefresh()
URL : https://patchwork.freedesktop.org/series/141910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15761 -> Patchwork_141910v1
Summary
---
== Series Details ==
Series: drm/modes: Fix div-by-zero in drm_mode_vrefresh()
URL : https://patchwork.freedesktop.org/series/141910/
State : warning
== Summary ==
Error: dim checkpatch failed
b5ea1d1f9a67 drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()
-:50: WARNING:MISSING_FIXE
From: Ville Syrjälä
drm_mode_vrefresh() is trying to avoid divide by zero
by checking whether htotal or vtotal are zero. But we may
still end up with a div-by-zero of vtotal*htotal*...
Cc: sta...@vger.kernel.org
Reported-by: syzbot+622bba18029bcde67...@syzkaller.appspotmail.com
Closes: https://s
From: Ville Syrjälä
We no longer store a cache vrefresh value in the mode.
Remove the stale information from drm_vrefresh() docs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/dri
From: Ville Syrjälä
Fix a potential div-by-zero in drm_mode_vrefresh()
TODO: should probably make drm_mode_setcrtc() not even print the
(potentially partially) converted mode, and instead print
the original umode..
Test-with: 20241128190927.26033-1-ville.syrj...@linux.intel.com
Vil
On 11/28/2024 13:28, Eugene Kobyak wrote:
When the intel_context structure contains NULL,
it raises a NULL pointer dereference error in drm_info().
Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12309
Cc: Jo
Hi Arun,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on v6.12 next-20241128]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Eugene,
On Thu, Nov 28, 2024 at 09:28:43PM +, Eugene Kobyak wrote:
> When the intel_context structure contains NULL,
> it raises a NULL pointer dereference error in drm_info().
>
> Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request")
> Closes: https://gitlab.freedesktop.
== Series Details ==
Series: drm/i915: Fix NULL pointer dereference in capture_engine
URL : https://patchwork.freedesktop.org/series/141903/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15761 -> Patchwork_141903v1
Summary
When the intel_context structure contains NULL,
it raises a NULL pointer dereference error in drm_info().
Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12309
Cc: John Harrison
Cc: # v6.3+
Signed-off-by: Eug
When memory stats is generated fresh everytime by going though all the
BOs, their active information is quite easy to get. But if the stats are
tracked with BO's state this becomes harder since the job scheduling
part doesn't really deal with individual buffers.
Make drm-active- optional to enable
== Series Details ==
Series: drm/i915/display: power conversion to struct intel_display (rev2)
URL : https://patchwork.freedesktop.org/series/141846/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15759 -> Patchwork_141846v2
== Series Details ==
Series: drm/i915/display: power conversion to struct intel_display (rev2)
URL : https://patchwork.freedesktop.org/series/141846/
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/display: power conversion to struct intel_display (rev2)
URL : https://patchwork.freedesktop.org/series/141846/
State : warning
== Summary ==
Error: dim checkpatch failed
cd780c372c31 drm/i915/display: convert for_each_power_well() to struct
intel_display
== Series Details ==
Series: Introduce DRM device wedged event (rev8)
URL : https://patchwork.freedesktop.org/series/138069/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15759 -> Patchwork_138069v8
Summary
---
**FAI
== Series Details ==
Series: Introduce DRM device wedged event (rev8)
URL : https://patchwork.freedesktop.org/series/138069/
State : warning
== Summary ==
Error: dim checkpatch failed
48e6db3a81e0 drm: Introduce device wedged event
-:189: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declarati
== Series Details ==
Series: Introduce DRM device wedged event (rev8)
URL : https://patchwork.freedesktop.org/series/138069/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Wed, Nov 27, 2024 at 08:11:13AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Try to make DPT objects shrinakble once again. To overcome
> the earlier suspend/resume issues we'll just make sure all
> DPT VMAs are evicted during suspend, and thus resume won't
> care whether the DPT obje
Going forward, struct intel_display is the main device data structure
for display. Convert intel_display_power.c internally first, leaving
external interfaces for follow-up.
v2: Rebase, checkpatch fixes
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c
Going forward, struct intel_display is the main device data structure
for display. Convert the power map code to it.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../i915/display/intel_display_power_map.c| 56 +--
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git
Hi Dave, Simona
An all-Matt drm-xe-next-fixes PR this week.
Thanks,
Thomas
drm-xe-next-fixes-2024-11-28:
Driver Changes:
- Update xe2 graphics name string (Matt Roper)
- Fix a couple of guc submit races (Matt Auld)
- Fix pat index usage in migrate (Matt Auld)
- Ensure non-cached migrate pagetabl
Start converting power well code to struct intel_display. Start off with
for_each_power_well() and the reverse variant.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_power.c | 16 ++--
.../drm/i915/display/intel_display_power_well.c | 3 ++-
Going forward, struct intel_display is the main device data structure
for display. Switch the power well code over to it.
v2: Fix parenthesis alignment
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 3 +-
.../drm/i915/display/intel_display_power.
Start converting display power domain code to struct
intel_display. Start off with for_each_power_domain_well() and the
reverse variant.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_power.c | 17 ++---
1 file changed, 10 insertions(+), 7 delet
Going forward, struct intel_display is the main device data structure
for display. Convert the high level interfaces (init, cleanup, suspend,
resume, etc.) of intel_display_power.c over to it. The actual power
get/put etc. are left for follow-up.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
...
On Thu, 28 Nov 2024, Imre Deak wrote:
> On Thu, Nov 28, 2024 at 02:31:22PM +0200, Imre Deak wrote:
>> On Wed, Nov 27, 2024 at 07:06:02PM +0200, Jani Nikula wrote:
>> > Simplify conditional compilation on CONFIG_DRM_I915_DEBUG_RUNTIME_PM.
>> > Hide it all inside intel_display_power.c.
>> >
>> > Th
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Signed-off-by: Raag Jadav
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/d
This is v2 of [1] with patch 1 dropped, and some minor checkpatch issues
fixed.
[1] https://lore.kernel.org/r/cover.1732727056.git.jani.nik...@intel.com
Jani Nikula (6):
drm/i915/display: convert for_each_power_well() to struct
intel_display
drm/i915/display: convert for_each_power_domain
This series introduces device wedged event in DRM subsystem and uses
it in xe and i915 drivers. Detailed description in commit message.
This was earlier attempted as xe specific uevent in v1 and v2.
https://patchwork.freedesktop.org/series/136909/
Similar work by André Almeida.
https://lore.kerne
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
W
Add documentation for device wedged event in a new 'Device wedging'
chapter. The describes basic definitions, prerequisites and consumer
expectations along with an example.
v8: Improve documentation (Christian, Rodrigo)
v9: Add prerequisites section (Christian)
v10: Clarify mmap cleanup and cons
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected and has become unrecoverable from driver context. Purpose of
this implementation is
Hi Dave, Sima,
here's the PR of drm-misc-fixes for this week. The first two patches
are from last weeks PR drm-misc-fixes-2024-11-21, which should be merged
first.
Best regards
Thomas
drm-misc-fixes-2024-11-28:
Short summary of fixes pull:
dma-buf:
- Fix dma_fence_array_signaled() to ensure for
On 2024-11-28 at 14:34:52 +0200, Ville Syrjälä wrote:
> On Wed, Nov 27, 2024 at 03:56:27PM +, Sebastian Brzezinka wrote:
> >
> > Hi Ville
> >
> > I found your patch looking at issue VLK-65591, seems like for some reason
> > cannot apply this workaround on JasperLake and end up with an error:
== Series Details ==
Series: drm/i915: Fix memory leak by correcting cache object name in error
handler (rev4)
URL : https://patchwork.freedesktop.org/series/133610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15757 -> Patchwork_133610v4
On Wed, 27 Nov 2024, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dp: use seq buf for printing rates
> URL : https://patchwork.freedesktop.org/series/141841/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_15753 -> Patchwork_141841v1
> ===
Hi Dave, Simona,
A pull request with a single obvious patch in it. Consequently it's very likely
to break the world and everything in it. As famous last words I'll add: "the
affected source file seems to compile on 32-bits and 64-bits x86".
Cheers,
~Maarten
drm-misc-next-fixes-2024-11-28:
A si
On Mon, 25 Nov 2024, Eugene Kobyak wrote:
> When the intel_context structure contains NULL,
> it raises a NULL pointer dereference error in drm_info().
>
> Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request")
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/1230
On Wed, 20 Nov 2024, Ankit Nautiyal wrote:
> Forward Error Correction is required for DP if we are using DSC but
> is optional for eDP.
>
> Currently the helper intel_dp_supports_dsc checks if fec_enable is set for
> DP or not. The helper is called after fec_enable is set in crtc_state.
>
> Instea
On Thu, Nov 28, 2024 at 02:31:22PM +0200, Imre Deak wrote:
> On Wed, Nov 27, 2024 at 07:06:02PM +0200, Jani Nikula wrote:
> > Simplify conditional compilation on CONFIG_DRM_I915_DEBUG_RUNTIME_PM.
> > Hide it all inside intel_display_power.c.
> >
> > This will unnecessarily pass in the wakeref also
On Wed, Nov 27, 2024 at 03:56:27PM +, Sebastian Brzezinka wrote:
>
> Hi Ville
>
> I found your patch looking at issue VLK-65591, seems like for some reason
> cannot apply this workaround on JasperLake and end up with an error:
>
> ```
> <3> [463.126159] i915 :00:02.0: [drm] ERROR GT0: e
On Wed, Nov 27, 2024 at 07:06:02PM +0200, Jani Nikula wrote:
> Simplify conditional compilation on CONFIG_DRM_I915_DEBUG_RUNTIME_PM.
> Hide it all inside intel_display_power.c.
>
> This will unnecessarily pass in the wakeref also when debug is disabled,
> but it should not matter a whole lot.
Ftr
On Thu, Nov 28, 2024 at 12:16:35PM +0100, Janusz Krzysztofik wrote:
> Commit e25913a1a79d ("i915/gem_mmap_offset: Ignore ENOSPC error for making
> residency execbuf") not only resolved the issue of unnecessary failures on
> ENOSPC errors, but also introduced an alternative method of clearing
> memo
Hi Janusz,
On Thu, Nov 28, 2024 at 12:16:36PM +0100, Janusz Krzysztofik wrote:
> The 'clear' subtest exercises correctness of object memory clearing on
> passing a batch with the object to GPU for processing. The exercise is
> executed in several parallel threads, one per CPU. Each thread repeat
On 11/28/2024 12:04 PM, Suraj Kandpal wrote:
We don't need to shout out loud if there is a Link Integrity
Failure. This does not mean HDCP has failed, it is expected and
taken into account in the HDCP Spec. The real failure happens when
we are not able to reauthenticate and get HDCP running aga
Hi Jiasheng,
> CI Bug Log - changes from CI_DRM_15756 -> Patchwork_133610v3
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_133610v3 absolutely need to be
> verified manually.
>
> If you th
Hi Jiasheng,
On Wed, Nov 27, 2024 at 08:10:42PM +, Jiasheng Jiang wrote:
> From: Jiasheng Jiang
>
> Replace "slab_priorities" with "slab_dependencies" in the error handler
> to avoid memory leak.
>
> Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
> Cc: # v5.2+
> Re
== Series Details ==
Series: drm/i915: Fix memory leak by correcting cache object name in error
handler (rev3)
URL : https://patchwork.freedesktop.org/series/133610/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15756 -> Patchwork_133610v3
The 'clear' subtest used to exercise correctness of object memory clearing
on passing a batch with the object to GPU for processing. However, commit
e25913a1a79d ("i915/gem_mmap_offset: Ignore ENOSPC error for making
residency execbuf"), while resolving an issue of unnecessary failures on
ENOSPC e
The 'clear' subtest exercises correctness of object memory clearing on
passing a batch with the object to GPU for processing. The exercise is
executed in several parallel threads, one per CPU. Each thread repeats
the exercise in a time only limited loop, with no delay between
consecutive iteratio
Commit e25913a1a79d ("i915/gem_mmap_offset: Ignore ENOSPC error for making
residency execbuf") not only resolved the issue of unnecessary failures on
ENOSPC errors, but also introduced an alternative method of clearing
memory of an object, with random selection of one of those methods on each
itera
Hi,
On Mon, Nov 25, 2024 at 03:27:11PM +, Eugene Kobyak wrote:
> When the intel_context structure contains NULL,
> it raises a NULL pointer dereference error in drm_info().
>
> Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request")
> Closes: https://gitlab.freedesktop.org/drm
On 11/27/2024 11:15 AM, Kandpal, Suraj wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Wednesday, November 20, 2024 4:08 PM
To: intel-gfx@lists.freedesktop.org
Cc: intel...@lists.freedesktop.org; Kandpal, Suraj ;
jani.nik...@linux.intel.com; Deak, Imre
Subject: [PATCH 04/12]
From: Jiasheng Jiang
Replace "slab_priorities" with "slab_dependencies" in the error handler
to avoid memory leak.
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Cc: # v5.2+
Reviewed-by: Nirmoy Das
Signed-off-by: Jiasheng Jiang
---
Changelog:
v1 -> v2:
1. Alter the
On Wed, 2024-11-27 at 07:57 +0200, Ville Syrjälä wrote:
> On Mon, Nov 25, 2024 at 02:55:34PM +0800, Xi Ruoyao wrote:
> > On Tue, 2024-10-08 at 12:01 +0300, Juha-Pekka Heikkila wrote:
> > > On 4.10.2024 21.03, Ville Syrjälä wrote:
> > > > On Fri, Oct 04, 2024 at 04:35:17PM +0300, Juha-Pekka Heikkila
> -Original Message-
> From: Intel-gfx On Behalf Of Mitul
> Golani
> Sent: Tuesday, November 12, 2024 2:21 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Subject: [RFC v1 1/4] drm/i915/scaler: Calculate scaler prefill latency
>
> Calculate scaler prefill lat
64 matches
Mail list logo
