Re: Second kexec_file_load (but not kexec_load) fails on i915 if CONFIG_INTEL_IOMMU_DEFAULT_ON=n

2025-07-14 Thread Baoquan He
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

✗ i915.CI.BAT: failure for drm/xe/display: Avoid dig_port work during suspend

2025-07-14 Thread Patchwork
== 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 --

RE: [PATCH] drm/i915/display: Add power well mapping for WCL

2025-07-14 Thread Borah, Chaitanya Kumar
> -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

Re:linux-next: build failure after merge of the drm-misc tree

2025-07-14 Thread Andy Yan
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

[PATCH] drm/xe/display: Avoid dig_port work during suspend

2025-07-14 Thread Dibin Moolakadan Subrahmanian
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

[PATCH v5 7/7] drm/i915/psr: Use TRANS_PUSH to trigger frame change event

2025-07-14 Thread Jouni Högander
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

[PATCH v5 5/7] drm/i915/dsb: Set DSB_SKIP_WAITS_EN chicken bit for LunarLake and onwards

2025-07-14 Thread Jouni Högander
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

[PATCH v5 4/7] drm/i915/vrr: Prepare to Use TRANS_PUSH mechanism for PSR frame change

2025-07-14 Thread 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

[PATCH v5 6/7] drm/i915/display: Wait for vblank in case of PSR is using trans push

2025-07-14 Thread Jouni Högander
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

[PATCH v5 1/7] drm/i915/psr: Do not trigger Frame Change events from frontbuffer flush

2025-07-14 Thread Jouni Högander
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

[PATCH v5 0/7] Use trans push mechanism to generate frame change event

2025-07-14 Thread Jouni Högander
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

[PATCH v5 3/7] drm/i915/psr: Add intel_psr_use_trans_push to query if TRANS_PUSH is used

2025-07-14 Thread Jouni Högander
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

[PATCH v5 2/7] drm/i915/psr: Add TRANS_PUSH register bit definition for PSR

2025-07-14 Thread Jouni Högander
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

linux-next: build failure after merge of the drm-misc tree

2025-07-14 Thread Stephen Rothwell
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

Re: [PATCH 2/2] drm/i915/gmbus: Add Wa_16025573575 for PTL/WCL for bit-bashing

2025-07-14 Thread Nautiyal, Ankit K
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

Re: [PATCH] drm/i915/display: Add power well mapping for WCL

2025-07-14 Thread Imre Deak
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'

✗ Fi.CI.BUILD: failure for drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET (rev2)

2025-07-14 Thread Patchwork
== 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

✓ i915.CI.BAT: success for drm/i915/display: Add no_psr_reason to PSR debugfs (rev9)

2025-07-14 Thread Patchwork
== 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

Re: [PATCH] drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET

2025-07-14 Thread Imre Deak
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

✗ LGCI.VerificationFailed: failure for fs: refactor write_begin/write_end and add ext4 IOCB_DONTCACHE support

2025-07-14 Thread Patchwork
== 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

Re: [PATCH] drm/i915/display: Add power well mapping for WCL

2025-07-14 Thread Gustavo Sousa
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

Re: [PATCH v2 2/2] drm/i915/psr: Do not disable Panel Replay if PSR2 is disabled

2025-07-14 Thread Rodrigo Vivi
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

✓ i915.CI.BAT: success for drm/i915: PREEMPT_RT related fixups. (rev13)

2025-07-14 Thread Patchwork
== 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 --- **

Re: [PATCH] drm/i915/display: Change ret value type from int to long

2025-07-14 Thread Dan Carpenter
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

[PATCH v5 2/5] drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter

2025-07-14 Thread 陈涛涛 Taotao Chen
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

Re: PREEMPT_RT vs i915

2025-07-14 Thread Mike Galbraith
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] =

[PATCH v5 3/5] fs: change write_begin/write_end interface to take struct kiocb *

2025-07-14 Thread 陈涛涛 Taotao Chen
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

Re: PREEMPT_RT vs i915

2025-07-14 Thread Mike Galbraith
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

Re: PREEMPT_RT vs i915

2025-07-14 Thread Mike Galbraith
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

[PATCH v5 1/5] drm/i915: Use kernel_write() in shmem object create

2025-07-14 Thread 陈涛涛 Taotao Chen
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_

[PATCH v5 5/5] ext4: support uncached buffered I/O

2025-07-14 Thread 陈涛涛 Taotao Chen
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

Re: [RFC PATCH 0/1] drm/i915/display: Avoid unsupported 300Hz output mode on a TUXEDO device

2025-07-14 Thread Werner Sembach
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

Re: [RFC PATCH 0/1] drm/i915/display: Avoid unsupported 300Hz output mode on a TUXEDO device

2025-07-14 Thread Tim Guttzeit
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

[PATCH v5 0/5] fs: refactor write_begin/write_end and add ext4 IOCB_DONTCACHE support

2025-07-14 Thread 陈涛涛 Taotao Chen
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

[PATCH v5 4/5] mm/pagemap: add write_begin_get_folio() helper function

2025-07-14 Thread 陈涛涛 Taotao Chen
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.

[PATCH v5 1/1] drm/i915/display: Add no_psr_reason to PSR debugfs

2025-07-14 Thread Michał Grzelak
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|

[PATCH v5 0/1] drm/i915/display: Add no_psr_reason to PSR debugfs

2025-07-14 Thread Michał Grzelak
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

[PATCH v4 3/9] drm/i915: Don't check for atomic context on PREEMPT_RT

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 1/9] drm/i915: Use preempt_disable/enable_rt() where recommended

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 7/9] drm/i915/guc: Consider also RCU depth in busy loop.

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 8/9] drm/i915: Consider RCU read section as atomic.

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 9/9] Revert "drm/i915: Depend on !PREEMPT_RT."

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 2/9] drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 6/9] drm/i915: Drop the irqs_disabled() check

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 5/9] drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock()

2025-07-14 Thread Sebastian Andrzej Siewior
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()

[PATCH v4 4/9] drm/i915: Disable tracing points on PREEMPT_RT

2025-07-14 Thread Sebastian Andrzej Siewior
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

[PATCH v4 0/9] drm/i915: PREEMPT_RT related fixups.

2025-07-14 Thread Sebastian Andrzej Siewior
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

Re: [PATCH] drm/i915/display: Add power well mapping for WCL

2025-07-14 Thread Gustavo Sousa
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

Re: [PATCH 0/9] drm: Revert general use of struct drm_gem_object.dma_buf

2025-07-14 Thread Simona Vetter
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

Re: [PATCH v5 0/5] fs: refactor write_begin/write_end and add ext4 IOCB_DONTCACHE support

2025-07-14 Thread Christian Brauner
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

Re: [PATCH] drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET

2025-07-14 Thread Thomas Zimmermann
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

Re: [PATCH] drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET

2025-07-14 Thread 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 ok with merging this fix via drm

Re: [PATCH 0/1] Revert patch to reject HBR3 for all eDP panels

2025-07-14 Thread Nautiyal, Ankit K
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

✓ i915.CI.BAT: success for drm/i915/display: Add power well mapping for WCL

2025-07-14 Thread Patchwork
== 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 ---