On 07/04/25 at 11:29am, Jani Nikula wrote:
> On Thu, 03 Jul 2025, Askar Safin wrote:
> > TL;DR: I found a bug in strange interaction in kexec_file_load (but not
> > kexec_load) and i915
> > TL;DR#2: Second (sometimes third or forth) kexec (using kexec_file_load)
> > fails on my particular hardwa
== Series Details ==
Series: drm/xe/display: Avoid dig_port work during suspend
URL : https://patchwork.freedesktop.org/series/151603/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16864 -> Patchwork_151603v1
Summary
--
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, July 15, 2025 2:21 AM
> To: Sousa, Gustavo
> Cc: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
> ; Dibin Moolakadan Subrahmanian
>
> Subje
this issue:
https://lore.kernel.org/dri-devel/20250715054754.800765-1-andys...@163.com/T/#u
>
>I have used the drm-misc tree from next-20250714 for today.
>
>--
>Cheers,
>Stephen Rothwell
It has been observed that during `xe_display_pm_suspend()` execution,
an HPD interrupt can still be triggered, resulting in `dig_port_work`
being scheduled. The issue arises when this work executes after
`xe_display_pm_suspend_late()`, by which time the display is fully
suspended.
This can l
Now we have everything in place for triggering PSR "frame change" event
using TRANS_PUSH: use TRANS_PUSH for LunarLake and onwards.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i9
On LunarLake we are using TRANS_PUSH mechanism to trigger "Frame Change"
event. This way we have more control on when PSR HW is woken up. I.e. not
every display register write is triggering sending update. This allows us
setting DSB_SKIP_WAITS_EN chicken bit as well.
Signed-off-by: Jouni Högander
On Lunarlake and onwards it is possible to generate PSR "frame change"
event using TRANS_PUSH mechanism. Implement function to enable this and
take PSR into account in intel_vrr_send_push.
v4:
- use rmw when enabling/disabling transcoder
- set TRANS_PUSH_EN conditionally in intel_vrr_send_push
In case PSR uses trans push as a "frame change" event and we need to wait
vblank after triggering PSR "frame change" event. Othervise we may miss
selective updates.
DSB skips all waits while PSR is active. Check push send is skipped as well
because trans push send bit is not clearn by the HW if VR
We want to get rid of triggering "Frame Change" events from
frontbuffer flush calls. We are about to move using TRANS_PUSH
register for this on LunarLake and onwards. Touching TRANS_PUSH
register from fronbuffer flush would be problematic as it's written by
DSB as well.
Fix this by using intel_psr
Currently we are using "automatic" frame change event generation. The
event is generated by any access to plane or pipe registers.
We have option to use "PSR PR Frame Change Enable" bit in TRANS_PUSH
register to enable frame change event generation only when doing trans
push. When this bit is set
This is a preparation patch to start using TRANS_PUSH for PSR "Frame
Change". It adds intel_psr_use_trans_push which return false for now until
we have everything in place.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 5 +
drivers/gpu/drm/i915/display/intel_ps
Add TRANS_PUSH register bit LNL_TRANS_PUSH_PSR_PR_EN definition for PSR
usage.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_vrr_regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr_regs.h
b/drivers/gpu/drm/i915/display/intel_v
mit
5d156a9c3d5e ("drm/bridge: Pass down connector to drm bridge detect hook")
I have used the drm-misc tree from next-20250714 for today.
--
Cheers,
Stephen Rothwell
pgp81lk6N3aEq.pgp
Description: OpenPGP digital signature
On 7/11/2025 5:07 PM, Gustavo Sousa wrote:
Quoting Ankit Nautiyal (2025-07-11 01:19:00-03:00)
As per Wa_16025573575 for PTL/WCL, set the GPIO masks bit before starting
bit-bashing and maintain value through the bit-bashing sequence. After the
bit-bashing sequence is done, clear the GPIO masks
On Mon, Jul 14, 2025 at 04:51:18PM -0300, Gustavo Sousa wrote:
> Quoting Gustavo Sousa (2025-07-14 12:07:50-03:00)
> >Quoting Chaitanya Kumar Borah (2025-07-14 02:53:44-03:00)
> >>WCL has 3 pipes, create power well mapping to reflect
> >
> >I believe display fuses should reflect that, right? I don'
== Series Details ==
Series: drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to
TRAINING_PATTERN_SET (rev2)
URL : https://patchwork.freedesktop.org/series/151356/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/151356/revisions/2/mbox/ no
== Series Details ==
Series: drm/i915/display: Add no_psr_reason to PSR debugfs (rev9)
URL : https://patchwork.freedesktop.org/series/148958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16863 -> Patchwork_148958v9
Summary
On Mon, Jul 14, 2025 at 11:00:08AM +0200, Thomas Zimmermann wrote:
>
> Am 14.07.25 um 10:57 schrieb Imre Deak:
> > Hi,
> >
> > On Thu, Jul 10, 2025 at 02:28:28PM +0300, Imre Deak wrote:
> > > Hi Thomas, Maxime, Maarten,
> > >
> > > the patch this change fixes (commit a40c5d727b81) was merged via
== Series Details ==
Series: fs: refactor write_begin/write_end and add ext4 IOCB_DONTCACHE support
URL : https://patchwork.freedesktop.org/series/151578/
State : failure
== Summary ==
Address 'chentao...@didiglobal.com' is not on the allowlist, which prevents CI
from being triggered for this
Quoting Gustavo Sousa (2025-07-14 12:07:50-03:00)
>Quoting Chaitanya Kumar Borah (2025-07-14 02:53:44-03:00)
>>WCL has 3 pipes, create power well mapping to reflect
>
>I believe display fuses should reflect that, right? I don't have a WCL
>handy to check that, but I believe so.
>
>In that case, I b
On Fri, Jul 11, 2025 at 10:33:58AM +, Hogander, Jouni wrote:
> On Fri, 2025-07-11 at 02:11 +0300, Ville Syrjälä wrote:
> > On Thu, Jul 10, 2025 at 05:27:13PM -0400, Rodrigo Vivi wrote:
> > > On Thu, Jul 10, 2025 at 11:09:42PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Jul 10, 2025 at 11:42:52A
== Series Details ==
Series: drm/i915: PREEMPT_RT related fixups. (rev13)
URL : https://patchwork.freedesktop.org/series/95463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16862 -> Patchwork_95463v13
Summary
---
**
On Fri, Jul 04, 2025 at 03:00:55PM +0300, Jani Nikula wrote:
> On Fri, 04 Jul 2025, Aakash Deep Sarkar wrote:
> > dma_fence_wait_timeout returns a long type but the driver is
> > only using the lower 32 bits of the retval and discarding the
> > upper 32 bits.
> >
> > This is particularly problemat
From: Taotao Chen
Refactors shmem_pwrite() to replace the ->write_begin/end logic
with a write_iter-based implementation using kiocb and iov_iter.
While kernel_write() was considered, it caused about 50% performance
regression. vfs_write() is not exported for kernel use. Therefore,
file->f_op->w
On Fri, 2025-07-11 at 04:36 +0200, Mike Galbraith wrote:
> ..forwarding any performance goop emitted, but lockdep runs out of lock
> counting fingers and turns itself off in short order with RT builds.
Hohum, seems block-land called dibs on lockdep anyway.
[6.761473] =
From: Taotao Chen
Change the address_space_operations callbacks write_begin() and
write_end() to take struct kiocb * as the first argument instead of
struct file *.
Update all affected function prototypes, implementations, call sites,
and related documentation across VFS, filesystems, and block
On Wed, 2025-07-09 at 23:09 +0300, Ville Syrjälä wrote:
> On Wed, Jul 09, 2025 at 09:44:43PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2025-07-09 20:30:26 [+0300], Ville Syrjälä wrote:
> > > >
> > > > It seems like the critical uncore lock is currently held in a lot of
> > > > places and pote
On Thu, 2025-07-10 at 18:50 +0300, Ville Syrjälä wrote:
> On Thu, Jul 10, 2025 at 06:52:58AM +0200, Mike Galbraith wrote:
> > >
> > > Until someone actually does the work to confirm the thing is working
> > > reliably there's no point in posting anything.
> >
> > What does that entail?
>
> Basic
From: Taotao Chen
Replace the write_begin/write_end loop in
i915_gem_object_create_shmem_from_data() with call to kernel_write().
This function initializes shmem-backed GEM objects. kernel_write()
simplifies the code by removing manual folio handling.
Part of a series refactoring address_space_
From: Taotao Chen
Set FOP_DONTCACHE in ext4_file_operations to declare support for
uncached buffered I/O.
To handle this flag, update ext4_write_begin() and ext4_da_write_begin()
to use write_begin_get_folio(), which encapsulates FGP_DONTCACHE logic
based on iocb->ki_flags.
Part of a series ref
Hi all,
Am 08.07.25 um 23:05 schrieb Rodrigo Vivi:
On Fri, Jul 04, 2025 at 09:03:45PM +0200, Werner Sembach wrote:
RFC because I'm not sure if this is the right approach.
Could you please file a gitlab issue for us so we can get someone from our
display team to take a look and see if there's a
Hi all,
> Tim can you follow up with this? Reducing the communication chain to
avoid dropping information.
Yes, here is the Ticket:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14616
Best regards,
Tim Guttzeit
Am 09.07.25 um 13:49 schrieb Werner Sembach:
Hi all,
Am 08.07.25 um
From: Taotao Chen
This patch series refactors the address_space_operations write_begin()
and write_end() callbacks to take const struct kiocb * as their first
argument, allowing IOCB flags such as IOCB_DONTCACHE to propagate to the
filesystem's buffered I/O path.
Ext4 is updated to implement han
From: Taotao Chen
Add write_begin_get_folio() to simplify the common folio lookup logic
used by filesystem ->write_begin() implementations.
This helper wraps __filemap_get_folio() with common flags such as
FGP_WRITEBEGIN, conditional FGP_DONTCACHE, and set folio order based
on the write length.
There is no reason in debugfs why PSR has been disabled. Add
no_psr_reason field into struct intel_psr. Write the reason,
e.g. PSR setup timing not met, into proper PSR debugfs file.
Clean it when PSR is activated.
Signed-off-by: Michał Grzelak
---
.../drm/i915/display/intel_display_types.h|
Next version of v4 [1]. Removed the tag to test if Patchwork will pick
the IGT changes.
[1]
https://lore.kernel.org/intel-gfx/20250711164959.608303-1-michal.grze...@intel.com
Best regards,
Michał
---
Changelog:
v4->v5
- fix indentation errors from checkpatch
v3->v4
- change format of logging
The !in_atomic() check in _wait_for_atomic() triggers on PREEMPT_RT
because the uncore::lock is a spinlock_t and does not disable
preemption or interrupts.
Changing the uncore:lock to a raw_spinlock_t doubles the worst case
latency on an otherwise idle testbox during testing.
Ignore _WAIT_FOR_ATO
From: Mike Galbraith
Mario Kleiner suggest in commit
ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms
driver.")
a spots where preemption should be disabled on PREEMPT_RT. The
difference is that on PREEMPT_RT the intel_uncore::lock disables neither
preemption nor in
intel_guc_send_busy_loop() looks at in_atomic() and irqs_disabled() to
decide if it should busy-spin while waiting or if it may sleep.
Both checks will report false on PREEMPT_RT if sleeping spinlocks are
acquired leading to RCU splats while the function sleeps.
Check also if RCU has been disabled
Locking and/ or running inside interrupt handler will not lead to an
atomic section on PREEMPT_RT. The RCU read section needs to be
considered because all locks, which become sleeping locks on
PREEMPT_RT, start a RCU read section. Scheduling/ sleeping while within
a RCU read section is invalid.
Ch
Once the known issues are addressed, it should be safe to enable the
driver.
Acked-by: Tvrtko Ursulin
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 5e
From: Mike Galbraith
Commit
8d7849db3eab7 ("drm/i915: Make sprite updates atomic")
started disabling interrupts across atomic updates. This breaks on PREEMPT_RT
because within this section the code attempt to acquire spinlock_t locks which
are sleeping locks on PREEMPT_RT.
According to the c
The !irqs_disabled() check triggers on PREEMPT_RT even with
i915_sched_engine::lock acquired. The reason is the lock is transformed
into a sleeping lock on PREEMPT_RT and does not disable interrupts.
There is no need to check for disabled interrupts. The lockdep
annotation below already check if t
execlists_dequeue() is invoked from a function which uses
local_irq_disable() to disable interrupts so the spin_lock() behaves
like spin_lock_irq().
This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not
the same as spin_lock_irq().
execlists_dequeue_irq() and execlists_dequeue()
Luca Abeni reported this:
| BUG: scheduling while atomic: kworker/u8:2/15203/0x0003
| CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
| Call Trace:
| rt_spin_lock+0x3f/0x50
| gen6_read32+0x45/0x1d0 [i915]
| g4x_get_vblank_counter+0x36/0x40 [i915]
| trace_event_raw_event_i915
The following patches are from the PREEMPT_RT queue. They are used by
people using the real-time preemption model and a i915 compatible GPU
card.
Patches 1+2 keep preemption and interrupts enabled within vblank
handling. I don't see another way of handling it given the constrains.
Patch #4 disables
Quoting Chaitanya Kumar Borah (2025-07-14 02:53:44-03:00)
>WCL has 3 pipes, create power well mapping to reflect
I believe display fuses should reflect that, right? I don't have a WCL
handy to check that, but I believe so.
In that case, I believe a better solution would be to filter out the
power
On Fri, Jul 11, 2025 at 11:35:15AM +0200, Thomas Zimmermann wrote:
> Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
> in the affected places. Also revert any fixes on top. Separates references
> to imported and exported DMA bufs within a GEM object; as before.
>
> Using th
On Thu, 10 Jul 2025 10:14:06 +, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen
>
> This patch series refactors the address_space_operations write_begin()
> and write_end() callbacks to take const struct kiocb * as their first
> argument, allowing IOCB flags such as IOCB_DONTCACHE to propagate to
Am 14.07.25 um 10:57 schrieb Imre Deak:
Hi,
On Thu, Jul 10, 2025 at 02:28:28PM +0300, Imre Deak wrote:
Hi Thomas, Maxime, Maarten,
the patch this change fixes (commit a40c5d727b81) was merged via
drm-intel and is also part of v6.16-rc4 (there cherry-picked in commit
a3ef3c2da675).
Are you
Hi,
On Thu, Jul 10, 2025 at 02:28:28PM +0300, Imre Deak wrote:
> Hi Thomas, Maxime, Maarten,
>
> the patch this change fixes (commit a40c5d727b81) was merged via
> drm-intel and is also part of v6.16-rc4 (there cherry-picked in commit
> a3ef3c2da675).
>
> Are you ok with merging this fix via drm
On 7/11/2025 8:19 PM, Ville Syrjälä wrote:
On Thu, Jul 10, 2025 at 10:50:39AM +0530, Ankit Nautiyal wrote:
Revert the existing patch that rejects HBR3 for all eDP panels that
do not support TPS4. With the patch reverted, the gitlab issue#5969 [1]
will get opened again. Add a quirk to limit the
== Series Details ==
Series: drm/i915/display: Add power well mapping for WCL
URL : https://patchwork.freedesktop.org/series/151550/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16858 -> Patchwork_151550v1
Summary
---
54 matches
Mail list logo