On 22-08-2025 21:44, Xaver Hugl wrote:
+#define DRM_MODE_ATOMIC_FAILURE_REASON \
+ FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not
enabled") \
+ FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
+ FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLI
On 22-08-2025 16:07, Jani Nikula wrote:
On Fri, 22 Aug 2025, Arun R Murthy wrote:
There can be multiple reasons for a failure in atomic_ioctl. Most often
in these error conditions -EINVAL is returned. User/Compositor would
have to blindly take a call on failure of this ioctl so as to use
ALLOW_
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.
Refactor intel_psr_post_plane_update by using no_psr_reason
instead of boolean keep
Next version of v5 [1]. Took into consideration review from Jouni [2].
[1]
https://lore.kernel.org/intel-gfx/20250714160931.821383-1-michal.grze...@intel.com
[2]
https://lore.kernel.org/intel-gfx/3e4f40d5310b2fd4169f6befde7f7a7e611a4e09.ca...@intel.com
Test-with: 20250703140451.491593-2-michal.
On 22.08.25 20:01, Bart Van Assche wrote:
On 8/21/25 1:06 PM, David Hildenbrand wrote:
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.
Usually the SCSI core and the SG I/O driver are updated separately.
Anyway:
Thank
On 22.08.25 17:27, Mike Rapoport wrote:
On Thu, Aug 21, 2025 at 10:06:35PM +0200, David Hildenbrand wrote:
Grepping for "prep_compound_page" leaves on clueless how devdax gets its
compound pages initialized.
Let's add a comment that might help finding this open-coded
prep_compound_page() initia
>Subject: [PATCH] drm/i915/display: handle >return value in
>intel_sdvo_enable_hotplug
The subject does not match what you are doing in the patch maybe fix that .
Sorry for the noise my email client seems to be acting weird.(may still not be
working right so sorry again will probably be fixed by
Em 22/08/2025 12:28, Xaver Hugl escreveu:
Commit fd40a63c63a1 unintentionally disallowed no-op changes on non-primary
planes that the driver doesn't allow async flips on. This broke async flips
for compositors that disable the cursor plane in every async atomic commit.
To fix that, change drm_ato
From: Intel-gfx on behalf of
Juha-Pekka Heikkila
Sent: Friday, August 22, 2025 9:14:20 pm
To: intel-gfx@lists.freedesktop.org ;
intel...@lists.freedesktop.org
Cc: Juha-Pekka Heikkila
Subject: [PATCH] drm/i915/display: handle return value in
intel_sdvo_enabl
== Series Details ==
Series: drm/i915/display: handle return value in intel_sdvo_enable_hotplug
URL : https://patchwork.freedesktop.org/series/153361/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17050 -> Patchwork_153361v1
> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
> + FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC
> capability not enabled") \
> + FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
> + FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy
> DRM_MODE_PAGE
== Series Details ==
Series: drm/i915/guc: Add synchronization on interrupt enable flag (rev2)
URL : https://patchwork.freedesktop.org/series/153158/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17050 -> Patchwork_153158v2
Report in log if intel_sdvo_enable_hotplug failed
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
b/drivers/gpu/drm/i915/display/intel_sdvo.c
inde
== Series Details ==
Series: drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA
URL : https://patchwork.freedesktop.org/series/153345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17049 -> Patchwork_153345v1
== Series Details ==
Series: drm: re-allow no-op changes on non-primary planes in async flips (rev2)
URL : https://patchwork.freedesktop.org/series/152712/
State : failure
== Summary ==
Address 'xaver.h...@kde.org' is not on the allowlist, which prevents CI from
being triggered for this patch
Commit fd40a63c63a1 unintentionally disallowed no-op changes on non-primary
planes that the driver doesn't allow async flips on. This broke async flips
for compositors that disable the cursor plane in every async atomic commit.
To fix that, change drm_atomic_set_property to again only run atomic_as
On Thu, Aug 21, 2025 at 10:06:35PM +0200, David Hildenbrand wrote:
> Grepping for "prep_compound_page" leaves on clueless how devdax gets its
> compound pages initialized.
>
> Let's add a comment that might help finding this open-coded
> prep_compound_page() initialization more easily.
>
> Furthe
On Thu, Aug 21, 2025 at 10:06:28PM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (Microsoft)
> ---
> arch/arm64/Kcon
On Thu, Aug 21, 2025 at 10:06:31PM +0200, David Hildenbrand wrote:
> It's no longer user-selectable (and the default was already "y"), so
> let's just drop it.
and it should not matter for wireguard selftest anyway
>
> Cc: "Jason A. Donenfeld"
> Cc: Shuah Khan
> Signed-off-by: David Hildenbrand
On Thu, Aug 21, 2025 at 10:06:30PM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapop
On Thu, Aug 21, 2025 at 10:06:29PM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Alexander Gordeev
> Cc: Christian Borntraeger
> Cc: Sven Schnelle
> Signed-off-by: David Hil
On Thu, Aug 21, 2025 at 10:06:27PM +0200, David Hildenbrand wrote:
> In an ideal world, we wouldn't have to deal with SPARSEMEM without
> SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is
> considered too costly and consequently not supported.
>
> However, if an architecture does
On Fri, 2025-08-22 at 17:12 +0300, Ville Syrjälä wrote:
> On Fri, Aug 22, 2025 at 05:07:18AM +, Hogander, Jouni wrote:
> > On Thu, 2025-08-21 at 16:10 +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 21, 2025 at 07:59:18AM +0300, Jouni Högander wrote:
> > > > Check drm_mode_vrefresh return value s
Hi Xaver,
Thanks for the patch and sorry for the delay.
Em 08/08/2025 20:22, Xaver Hugl escreveu:
Commit fd40a63c63a1 unintentionally disallowed no-op changes on non-primary
planes that the driver doesn't allow async flips on. This broke async flips
for compositors that disable the cursor plane
On Thu, Aug 21, 2025 at 10:06:26PM +0200, David Hildenbrand wrote:
> As discussed recently with Linus, nth_page() is just nasty and we would
> like to remove it.
>
> To recap, the reason we currently need nth_page() within a folio is because
> on some kernel configs (SPARSEMEM without SPARSEMEM_VM
Boolean flag access from interrupt context might have synchronous issueis
on multiple processor platform, flags modified by one core might be read
as an old value by another core. This issue on interrupt enable flag might
causes interrupt misses or leakage.
Change the interrupts.enable type to atom
On Fri, Aug 22, 2025 at 05:07:18AM +, Hogander, Jouni wrote:
> On Thu, 2025-08-21 at 16:10 +0300, Ville Syrjälä wrote:
> > On Thu, Aug 21, 2025 at 07:59:18AM +0300, Jouni Högander wrote:
> > > Check drm_mode_vrefresh return value sanity before using it in
> > > intel_get_frame_time_us.
> > >
>
On 22.08.25 13:32, Pavel Begunkov wrote:
On 8/21/25 21:06, David Hildenbrand wrote:
We always provide a single dst page, it's unclear why the io_copy_cache
complexity is required.
Because it'll need to be pulled outside the loop to reuse the page for
multiple copies, i.e. packing multiple frag
On 21.08.2025 22:06, David Hildenbrand wrote:
> dma_common_contiguous_remap() is used to remap an "allocated contiguous
> region". Within a single allocation, there is no need to use nth_page()
> anymore.
>
> Neither the buddy, nor hugetlb, nor CMA will hand out problematic page
> ranges.
>
> Cc: M
On 22/08/2025 09:37, Matthew Auld wrote:
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Replace the freelist (O(n)) used for free block management with a
red-black tree, providing more efficient O(log n) search, insert,
and delete operations. This improves scalability and performance
when
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Maintain two separate RB trees per order - one for clear (zeroed) blocks
and another for dirty (uncleared) blocks. This separation improves
code clarity and makes it more obvious which tree is being searched
during allocation. It also improves
On Fri, 22 Aug 2025, Maarten Lankhorst
wrote:
> Hey,
>
> I'm not entirely sold on the design, it's way more complicated than it
> should be, it should be trivial to add any amount of error messages.
If we add error messages, how do we ensure the error messages themselves
never become part of UAP
On Wed, 20 Aug 2025, Ankit Nautiyal wrote:
> + if (HAS_VRR(display) && intel_vrr_possible(crtc_state)) {
Nitpick, and a tangential to designing stuff:
intel_vrr_possible() never returns true for !HAS_VRR(). The HAS_VRR()
check is redundant. Adding redundant checks adds uncertainty about what
Hey,
I'm not entirely sold on the design, it's way more complicated than it should
be, it should be trivial to add any amount of error messages.
Replace return -EINVAL; with return drm_atomic_error_einval(state, class,
"string");
Where class may be an enum, but in a way more generic way than cu
On Wed, 20 Aug 2025, Ankit Nautiyal wrote:
> Currently dsc/scaler prefill latencies are handled during watermark
> calculations. With the optimized guardband, we need to compute the
> latencies to find the minimum guardband that works for most cases.
> Extract the helpers to compute these latencie
On Fri, 22 Aug 2025, Arun R Murthy wrote:
> Add user readable error codes for failure cases in drm_atomic_ioctl() so
> that user can decode the error code and take corrective measurements.
>
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/drm_atomic.c | 6
> drivers/gpu/drm/drm
We are currently removing underrun on idle PSR WA even if it's not
applied. Fix this by checking pkg_c_latency_used on PSR exit as well.
Fixes: 9b1795e9b0ae ("drm/i915/psr: Underrun on idle PSR wa only when pkgc
latency > delayed vblank")
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/d
On Fri, 22 Aug 2025, Arun R Murthy wrote:
> There can be multiple reasons for a failure in atomic_ioctl. Most often
> in these error conditions -EINVAL is returned. User/Compositor would
> have to blindly take a call on failure of this ioctl so as to use
> ALLOW_MODESET or any. It would be good if
Hi Taotao,
On Fri, Aug 22, 2025 at 03:06:59AM +, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen
>
> Without O_LARGEFILE, file->f_op->write_iter calls
> generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
> causing -EFBIG on large writes.
>
> In shmem_pwrite(), this error is
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Replace the freelist (O(n)) used for free block management with a
red-black tree, providing more efficient O(log n) search, insert,
and delete operations. This improves scalability and performance
when managing large numbers of free blocks per
On 21.08.2025 22:06, David Hildenbrand wrote:
> The expectation is that there is currently no user that would pass in
> non-contigous page ranges: no allocator, not even VMA, will hand these
> out.
>
> The only problematic part would be if someone would provide a range
> obtained directly from memb
== Series Details ==
Series: User readable error codes on atomic_ioctl failure (rev2)
URL : https://patchwork.freedesktop.org/series/152275/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_17049 -> Patchwork_152275v2
Summary
There can be multiple reasons for a failure in atomic_ioctl. Most often
in these error conditions -EINVAL is returned. User/Compositor would
have to blindly take a call on failure of this ioctl so as to use
ALLOW_MODESET or any. It would be good if user/compositor gets a
readable error code on fail
For failures in async flip atomic check/commit path return user readable
error codes in struct drm_atomic_state.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/d
Add user readable error codes for failure cases in drm_atomic_ioctl() so
that user can decode the error code and take corrective measurements.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/drm_atomic.c | 6
drivers/gpu/drm/drm_atomic_uapi.c | 60
Now that a proper error code will be returned to the user on any failure
in atomic_ioctl() via struct drm_mode_atomic, add a new element
error_code in the struct drm_atomic_state so as to hold the error code
during the atomic_check() and atomic_commit() phases.
Signed-off-by: Arun R Murthy
---
i
The series focuses on providing a user readable error value on a failure
in drm_atomic_ioctl(). Usually -EINVAL is returned in most of the error
cases and it is difficult for the user to decode the error and get to
know the real cause for the error. If user gets to know the reason for
the error the
47 matches
Mail list logo
