== Series Details ==
Series: ALPM LFPS and silence period calculation (rev2)
URL : https://patchwork.freedesktop.org/series/152862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17086 -> Patchwork_152862v2
Summary
---
Currently we are using maximum lfps cycle and silence period times when
calculating AUXLess wake time. Use actual values instead.
Signed-off-by: Jouni Högander
Reviewed-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_alpm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletion
Currently LFPS is hadcoded for different port clocks. Replace this with
proper calculation.
v2: replace hardcoded 20 with 2 * LFPS_CYCLE_COUNT
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_alpm.c | 90 ++-
1 file changed, 38 insertions(+), 52 deletions
Calculate silence period instead of hardcoding it in switch case.
Signed-off-by: Jouni Högander
Reviewed-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_alpm.c | 37 +++
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/int
Add own define for LFPS count and use it for the configuration. This new
define will be used for calculating ALPM parameters as well.
Signed-off-by: Jouni Högander
Reviewed-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_alpm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Currently ALPM LFPS and silence period are hardcoded for different
link rates. This patch set implements calculation for these
parameters.
Also AUXLess wake time is optimized by using actual LFPS cycles and
silence period instead of maximum values.
v2: replace hardcoded 20 with 2 * LFPS_CYCLE_COU
> Subject: RE: [PATCH] drm/i915/backlight: Honor VESA eDP backlight luminance
> control capability
>
> > Subject: [PATCH] drm/i915/backlight: Honor VESA eDP backlight
> > luminance control capability
> >
> > The VESA AUX backlight failed to be enabled becaused luminance_set is
> > false always.
F
bytes [-Werror=frame-larger-than=]
171 | }
| ^
cc1: all warnings being treated as errors
Possibly caused by commit
e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva")
I have used the drm-misc tree from next-20250828 for today.
--
Cheers,
Stephen Rothwell
pgp7
* David Hildenbrand [250827 18:05]:
> 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.
Thanks for the comment here.
>
> Furth
* David Hildenbrand [250827 18:04]:
> Let's check that no hstate that corresponds to an unreasonable folio size
> is registered by an architecture. If we were to succeed registering, we
> could later try allocating an unsupported gigantic folio size.
>
> Further, let's add a BUILD_BUG_ON() for ch
* David Hildenbrand [250827 18:04]:
> Let's reject unreasonable folio sizes early, where we can still fail.
> We'll add sanity checks to prepare_compound_head/prepare_compound_page
> next.
>
> Is there a way to configure a system such that unreasonable folio sizes
> would be possible? It would al
* David Hildenbrand [250827 18:04]:
> Let's reject them early, which in turn makes folio_alloc_gigantic() reject
> them properly.
>
> To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER
> and calculate MAX_FOLIO_NR_PAGES based on that.
>
> Reviewed-by: Zi Yan
> Acked-by:
* David Hildenbrand [250827 18:04]:
> It's no longer user-selectable (and the default was already "y"), so
> let's just drop it.
>
> It was never really relevant to the wireguard selftests either way.
>
> Acked-by: Mike Rapoport (Microsoft)
> Cc: "Jason A. Donenfeld"
> Cc: Shuah Khan
> Signed
* David Hildenbrand [250827 18:03]:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Reviewed-by: Mike Rapoport (Microsoft)
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Signed-off-by: David Hildenbrand
Reviewed-by
* David Hildenbrand [250827 18:03]:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Reviewed-by: Mike Rapoport (Microsoft)
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Alexander Gordeev
> Cc: Christian Borntraeger
> Cc: Sven Schnelle
> Signed-off-b
* David Hildenbrand [250827 18:03]:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Reviewed-by: Mike Rapoport (Microsoft)
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: David Hildenbrand
Reviewed-by: Liam R. Howlett
> ---
> arch/arm64/Kc
* David Hildenbrand [250827 18:03]:
> 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 support SPARSEMEM with
> SPAR
On 8/29/25 2:53 AM, Lorenzo Stoakes wrote:
> On Thu, Aug 28, 2025 at 12:01:28AM +0200, 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.
>>
>> Cc: Damien Le Moal
>> Cc: Niklas Cassel
>> Signe
== Series Details ==
Series: drm/i915/guc: Test GuC v70.49.4 for ADL-P, DG1, DG2, MTL, TGL (rev4)
URL : https://patchwork.freedesktop.org/series/153534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153534v4
==
On 28.08.25 23:28, David Hildenbrand wrote:
On 28.08.25 23:18, David Hildenbrand wrote:
On 26.08.25 18:09, Christian König wrote:
On 26.08.25 14:07, David Hildenbrand wrote:
2) We add another interface that consumes PFNs, but explicitly states
that it is only for ordinary system RAM,
On 28.08.25 23:18, David Hildenbrand wrote:
On 26.08.25 18:09, Christian König wrote:
On 26.08.25 14:07, David Hildenbrand wrote:
2) We add another interface that consumes PFNs, but explicitly states
that it is only for ordinary system RAM, and that the user is
required for updati
On 26.08.25 18:09, Christian König wrote:
On 26.08.25 14:07, David Hildenbrand wrote:
2) We add another interface that consumes PFNs, but explicitly states
that it is only for ordinary system RAM, and that the user is
required for updating the direct map.
We could sanity-check
On 26.08.25 16:27, Thomas Hellström wrote:
Hi, Christian,
On Tue, 2025-08-26 at 11:56 +0200, Christian König wrote:
On 26.08.25 11:17, David Hildenbrand wrote:
On 26.08.25 11:00, Christian König wrote:
On 26.08.25 10:46, David Hildenbrand wrote:
So my assumption would be that that is missing
On 28.08.25 18:57, Lorenzo Stoakes wrote:
On Thu, Aug 28, 2025 at 12:01:24AM +0200, David Hildenbrand wrote:
Let's make it clearer that we are operating within a single folio by
providing both the folio and the page.
This implies that for flush_dcache_folio() we'll now avoid one more
page->foli
UAPI compatibility version 1.24.4
This patch is for testing only. If testing is successful the binary
blobs will replace the major versioned '*_guc_70.bin' files for given
platforms.
Signed-off-by: Julia Filipchuk
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 +-
1 file changed, 5 i
On Thu, Aug 28, 2025 at 12:01:38AM +0200, David Hildenbrand wrote:
> We want to get rid of nth_page(), and kfence init code is the last user.
>
> Unfortunately, we might actually walk a PFN range where the pages are
> not contiguous, because we might be allocating an area from memblock
> that could
On Thu, Aug 28, 2025 at 12:01:10AM +0200, David Hildenbrand wrote:
>Let's reject them early, which in turn makes folio_alloc_gigantic() reject
>them properly.
>
>To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER
>and calculate MAX_FOLIO_NR_PAGES based on that.
>
>Reviewed-b
在 2025/8/27 17:17, Sudeep Holla 写道:
On Wed, Aug 27, 2025 at 09:30:13AM +0100, Ben Horgan wrote:
Hi Zihuan,
On 8/27/25 03:31, Zihuan Zhang wrote:
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting
On Thu, Aug 28, 2025 at 12:01:14AM +0200, David Hildenbrand wrote:
>Let's sanity-check in folio_set_order() whether we would be trying to
>create a folio with an order that would make it exceed MAX_FOLIO_ORDER.
>
>This will enable the check whenever a folio/compound page is initialized
>through pre
On Thu, Aug 28, 2025 at 12:01:05AM +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 supp
On Thu, 28 Aug 2025 at 00:11, 'David Hildenbrand' via kasan-dev
wrote:
>
> We want to get rid of nth_page(), and kfence init code is the last user.
>
> Unfortunately, we might actually walk a PFN range where the pages are
> not contiguous, because we might be allocating an area from memblock
> tha
On Thu, Aug 28, 2025 at 12:01:06AM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Reviewed-by: Mike Rapoport (Microsoft)
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: David Hildenbrand
Acked-by: Catalin Marin
This is based on mm-unstable.
I will only CC non-MM folks on the cover letter and the respective patch
to not flood too many inboxes (the lists receive all patches).
--
As discussed recently with Linus, nth_page() is just nasty and we would
like to remove it.
To recap, the reason we currently n
On Thu, Aug 28, 2025 at 09:46:25AM +0200, David Hildenbrand wrote:
>>
>> Curious about why it is in page-flags.h. It seems not related to page-flags.
>
>Likely because we have the page_folio() in there as well.
>
Hmm... sorry for this silly question.
>--
>Cheers
>
>David / dhildenb
--
Wei Yan
On Thu, Aug 28, 2025 at 12:01:16AM +0200, David Hildenbrand wrote:
>Now that a single folio/compound page can no longer span memory sections
>in problematic kernel configurations, we can stop using nth_page().
>
>While at it, turn both macros into static inline functions and add
>kernel doc for fol
Hi,
在 2025/8/27 22:13, Sean Christopherson 写道:
On Wed, Aug 27, 2025, Zihuan Zhang wrote:
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting mistakes and aligns the code with the latest kernel style.
On Thu, Aug 28, 2025 at 12:01:13AM +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.
>
>Further, let'
On Thu, Aug 28, 2025 at 12:01:15AM +0200, David Hildenbrand wrote:
>Let's limit the maximum folio size in problematic kernel config where
>the memmap is allocated per memory section (SPARSEMEM without
>SPARSEMEM_VMEMMAP) to a single memory section.
>
>Currently, only a single architectures supports
== Series Details ==
Series: drm/i915/guc: Test GuC v70.49.4 for ADL-P, DG1, DG2, MTL, TGL (rev3)
URL : https://patchwork.freedesktop.org/series/153534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153534v3
==
On Thu, 28 Aug 2025 00:01:35 +0200
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.
>
> Cc: Brett Creeley
> Cc: Jason Gunthorpe
> Cc: Yishai Hadas
> Cc: Shameer Kolothum
> Cc: Kevin Tian
On Thu, Aug 28, 2025 at 12:01:40AM +0200, David Hildenbrand wrote:
> Now that all users are gone, let's remove it.
>
> Signed-off-by: David Hildenbrand
HAPPY DAYYS
Happy to have reached this bit, great work! :)
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/mm.h
On Thu, Aug 28, 2025 at 12:01:39AM +0200, David Hildenbrand wrote:
> Ever since commit 858c708d9efb ("block: move the bi_size update out of
> __bio_try_merge_page"), page_is_mergeable() no longer exists, and the
> logic in bvec_try_merge_page() is now a simple page pointer
> comparison.
>
> Signed-
On Thu, Aug 28, 2025 at 12:01:36AM +0200, 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.
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-b
On Thu, Aug 28, 2025 at 12:01:37AM +0200, David Hildenbrand wrote:
> There is the concern that unpin_user_page_range_dirty_lock() might do
> some weird merging of PFN ranges -- either now or in the future -- such
> that PFN range is contiguous but the page range might not be.
>
> Let's sanity-check
== Series Details ==
Series: Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to
LANE0_1_STATUS" (rev7)
URL : https://patchwork.freedesktop.org/series/153652/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/153652/revisions/7/mbox/ not
On Thu, Aug 28, 2025 at 12:01:35AM +0200, 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.
>
> Cc: Brett Creeley
> Cc: Jason Gunthorpe
> Cc: Yishai Hadas
> Cc: Shameer Kolothum
> Cc: Kevin T
On Thu, Aug 28, 2025 at 12:01:34AM +0200, 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.
>
> Reviewed-by: Bart Van Assche
> Cc: Doug Gilbert
> Cc: "James E.J. Bottomley"
> Cc: "Martin K. Pe
On Thu, Aug 28, 2025 at 12:01:33AM +0200, 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.
>
> Reviewed-by: Bart Van Assche
> Cc: "James E.J. Bottomley"
> Cc: "Martin K. Petersen"
> Signed-of
UAPI compatibility version 1.24.4
This patch is for testing only. If testing is successful the binary
blobs will replace the major versioned '*_guc_70.bin' files for given
platforms.
Signed-off-by: Julia Filipchuk
---
Resend to trigger CI with corrected firmware tree.
drivers/gpu/drm/i915/gt/u
On Thu, Aug 28, 2025 at 12:01:32AM +0200, 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.
>
> Acked-by: Ulf Hansson
> Cc: Alex Dubov
> Cc: Ulf Hansson
> Cc: Jesper Nilsson
> Cc: Lars Persso
On Thu, Aug 28, 2025 at 12:01:31AM +0200, 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.
>
> Acked-by: Ulf Hansson
> Cc: Maxim Levitsky
> Cc: Alex Dubov
> Cc: Ulf Hansson
> Signed-off-by:
On Thu, Aug 28, 2025 at 12:01:30AM +0200, 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.
>
> Acked-by: Ulf Hansson
> Cc: Maxim Levitsky
> Cc: Alex Dubov
> Cc: Ulf Hansson
> Signed-off-by:
On Thu, Aug 28, 2025 at 12:01:29AM +0200, 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.
>
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: David Airli
On Thu, Aug 28, 2025 at 12:01:28AM +0200, 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.
>
> Cc: Damien Le Moal
> Cc: Niklas Cassel
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-b
On Thu, Aug 28, 2025 at 12:01:27AM +0200, 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
> obtain
This reverts commit 944e732be9c3a33e64e9fb0f5451a37fc252ddfc.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
This reverts commit a19b31f854a8992dfa35255f43efd19be292b15c.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
This reverts commit 4f546a77671076a0a49c08b4c6a7d0888d72f7d2.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
This reverts commit 65e46aeaf84aa88539bcff6b8077e05fbd0700da.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
This reverts commit 3c778a98bee16b4c7ba364a0101ee3c399a95b85.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
This reverts commit 89d17a2d89a83c5b7643ca934651a3f9229e4734.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
This reverts commit 2402adce8da4e7396b63b5ffa71e1fa16e5fe5c4.
The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the
reverted commit backported causes a regression, on one eDP panel at
least resulting in display fl
== Series Details ==
Series: drm/i915/display: convert to generic poll_timeout_us()
URL : https://patchwork.freedesktop.org/series/153629/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153629v1
Summary
--
On Thu, Aug 28, 2025 at 12:01:26AM +0200, 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 pag
On Thu, Aug 28, 2025 at 12:01:25AM +0200, David Hildenbrand wrote:
> Let's disallow handing out PFN ranges with non-contiguous pages, so we
> can remove the nth-page usage in __cma_alloc(), and so any callers don't
> have to worry about that either when wanting to blindly iterate pages.
>
> This is
Add the necessary code needed to compile panthor tests. The tests
themselves will be added in a subsequent patch.
Signed-off-by: Daniel Almeida
---
meson.build | 8
tests/meson.build | 2 ++
tests/panthor/meson.build | 11 +++
3 files changed, 21 insertio
On Thu, Aug 28, 2025, Zihuan Zhang wrote:
> > Hmm, this is technically buggy. __free() won't invoke put_cpufreq_policy()
> > until
> > policy goes out of scope, and so using __free() means the code is
> > effectively:
> >
> > if (IS_ENABLED(CONFIG_CPU_FREQ)) {
> >
== Series Details ==
Series: series starting with [v4,1/2] drm/buddy: Optimize free block management
with RB tree
URL : https://patchwork.freedesktop.org/series/153625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153625v1
=
== Series Details ==
Series: drm/i915/guc: Test GuC v70.49.4 for ADL-P, DG1, DG2, MTL, TGL (rev2)
URL : https://patchwork.freedesktop.org/series/153534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153534v2
==
On Thu, Aug 28, 2025 at 12:01:24AM +0200, David Hildenbrand wrote:
> Let's make it clearer that we are operating within a single folio by
> providing both the folio and the page.
>
> This implies that for flush_dcache_folio() we'll now avoid one more
> page->folio lookup, and that we can safely dro
== Series Details ==
Series: drm/i915/display: Add no_psr_reason to PSR debugfs
URL : https://patchwork.freedesktop.org/series/153622/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153622v1
Summary
--
On Thu, Aug 28, 2025 at 12:01:08AM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
>
> Reviewed-by: Mike Rapoport (Microsoft)
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Signed-off-by: Da
On Thu, Aug 28, 2025 at 12:01:23AM +0200, David Hildenbrand wrote:
> Within a folio/compound page, nth_page() is no longer required.
> Given that we call folio_test_partial_kmap()+kmap_local_page(), the code
> would already be problematic if the pages would span multiple folios.
>
> So let's just a
On Thu, Aug 28, 2025 at 12:01:22AM +0200, David Hildenbrand wrote:
> nth_page() is no longer required when iterating over pages within a
> single folio, so let's just drop it when recording subpages.
>
> Signed-off-by: David Hildenbrand
This looks correct to me, so notwithtsanding suggestion belo
On Thu, Aug 28, 2025 at 12:01:21AM +0200, David Hildenbrand wrote:
> It's no longer required to use nth_page() within a folio, so let's just
> drop the nth_page() in folio_walk_start().
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/pagewalk.c | 2 +-
>
On Thu, Aug 28, 2025 at 12:01:20AM +0200, David Hildenbrand wrote:
> Let's cleanup and simplify the function a bit.
Ah I guess you separated this out from the previous patch? :)
I feel like it might be worth talking about the implementation here in the
commit message as it took me a while to figu
== Series Details ==
Series: series starting with [1/2] drm/i915: Disable tracepoints for PREEMPT_RT
URL : https://patchwork.freedesktop.org/series/153608/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17082 -> Patchwork_153608v1
===
We will be adding tests for Panthor in a subsequent patch, so first add
the ability to open the device.
Signed-off-by: Daniel Almeida
---
lib/drmtest.c | 1 +
lib/drmtest.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 436b6de78..f4b429048 100644
--- a
This series adds basic Panthor tests. In particular, these are being
used to test both Panthor and Tyr, i.e.: the new Rust GPU driver that
implements Panthor's uAPI. Most of the initial tests were chosen in
order to have something to test Tyr with, but this series lays the
groundwork so that more
== Series Details ==
Series: series starting with [v1,01/36] mm: stop making SPARSEMEM_VMEMMAP
user-selectable
URL : https://patchwork.freedesktop.org/series/153593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17081 -> Patchwork_153593v1
On Thu, Aug 28, 2025 at 12:01:17AM +0200, David Hildenbrand wrote:
> We can now safely iterate over all pages in a folio, so no need for the
> pfn_to_page().
>
> Also, as we already force the refcount in __init_single_page() to 1,
Mega huge nit (ignore if you want), but maybe worth saying 'via
ini
On Thu, Aug 28, 2025 at 12:01:19AM +0200, David Hildenbrand wrote:
> The nth_page() is not really required anymore, so let's remove it.
> While at it, cleanup and simplify the code a bit.
Hm Not sure which bit is the cleanup? Was there meant to be more here or?
>
> Signed-off-by: David Hildenbran
On Thu, Aug 28, 2025 at 12:01:18AM +0200, David Hildenbrand wrote:
> We're allocating a higher-order page from the buddy. For these pages
> (that are guaranteed to not exceed a single memory section) there is no
> need to use nth_page().
>
> Signed-off-by: David Hildenbrand
Oh hello! Now it all c
Hi Daniel,
A couple of errors that I hit when I tested this are below.
On 28/08/2025 14:04, Daniel Almeida wrote:
> Add an initial test suit covering query device properties, allocating
> memory, binding and unbinding VA ranges through VM_BIND and submitting a
> simple piece of work through GROUP
On 28/08/2025 14:03, Daniel Almeida wrote:
> We will be adding tests for Panthor in a subsequent patch, so first add
> the ability to open the device.
>
> Signed-off-by: Daniel Almeida
There's also chipset_to_str() which should be updated to return the
correct name. Although I think that only ma
On Thu, Aug 28, 2025 at 12:01:16AM +0200, David Hildenbrand wrote:
> Now that a single folio/compound page can no longer span memory sections
> in problematic kernel configurations, we can stop using nth_page().
>
> While at it, turn both macros into static inline functions and add
> kernel doc for
On Thu, 28 Aug 2025 10:03:56 -0300
Daniel Almeida wrote:
> This series adds basic Panthor tests. In particular, these are being
> used to test both Panthor and Tyr, i.e.: the new Rust GPU driver that
> implements Panthor's uAPI. Most of the initial tests were chosen in
> order to have something t
On Thu, Aug 28, 2025 at 12:01:10AM +0200, David Hildenbrand wrote:
> Let's reject them early, which in turn makes folio_alloc_gigantic() reject
> them properly.
>
> To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER
> and calculate MAX_FOLIO_NR_PAGES based on that.
>
> Revie
On Thu, Aug 28, 2025 at 12:01:15AM +0200, David Hildenbrand wrote:
> Let's limit the maximum folio size in problematic kernel config where
> the memmap is allocated per memory section (SPARSEMEM without
> SPARSEMEM_VMEMMAP) to a single memory section.
>
> Currently, only a single architectures supp
On Thu, Aug 28, 2025 at 12:01:14AM +0200, David Hildenbrand wrote:
> Let's sanity-check in folio_set_order() whether we would be trying to
> create a folio with an order that would make it exceed MAX_FOLIO_ORDER.
>
> This will enable the check whenever a folio/compound page is initialized
> through
On Thu, Aug 28, 2025 at 12:01:13AM +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.
>
> Further,
On Thu, Aug 28, 2025 at 12:01:12AM +0200, David Hildenbrand wrote:
> Let's check that no hstate that corresponds to an unreasonable folio size
> is registered by an architecture. If we were to succeed registering, we
> could later try allocating an unsupported gigantic folio size.
>
> Further, let'
On Thu, Aug 28, 2025 at 12:01:11AM +0200, David Hildenbrand wrote:
> Let's reject unreasonable folio sizes early, where we can still fail.
> We'll add sanity checks to prepare_compound_head/prepare_compound_page
> next.
>
> Is there a way to configure a system such that unreasonable folio sizes
> w
On Thu, Aug 28, 2025 at 12:01:09AM +0200, David Hildenbrand wrote:
> It's no longer user-selectable (and the default was already "y"), so
> let's just drop it.
>
> It was never really relevant to the wireguard selftests either way.
>
> Acked-by: Mike Rapoport (Microsoft)
> Cc: "Jason A. Donenfeld"
Hi Michał
On Thu Aug 28, 2025 at 10:49 AM UTC, Michał Grzelak wrote:
> There is no reason in debugfs why PSR has been disabled. Add
It might be useful to explain the motivation behind this feature.
> no_psr_reason field into struct intel_psr. Write the reason,
> e.g. PSR setup timing not met, into
Add an initial test suit covering query device properties, allocating
memory, binding and unbinding VA ranges through VM_BIND and submitting a
simple piece of work through GROUP_SUBMIT.
---
lib/igt_panthor.c | 136 ++
lib/igt_panthor.h | 20 +++
tests/panth
On Thu, Aug 28, 2025 at 12:01:07AM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
Ah yes there are other cases :)
>
> Reviewed-by: Mike Rapoport (Microsoft)
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Alexander Gordeev
>
On Thu, Aug 28, 2025 at 12:01:06AM +0200, David Hildenbrand wrote:
> Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
> is selected.
Do you plan to do this for other cases then I guess? Or was this an
outlier? I guess I will see :)
>
> Reviewed-by: Mike Rapoport (Microsoft)
>
On Thu, Aug 28, 2025 at 12:01:05AM +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 Thu, Aug 28, 2025 at 08:06:49AM +, Lee Shawn C wrote:
> Since intel_fdi_compute_pipe_bpp() is no longer FDI-specific and
> now applies to all connectors. Move it to intel_link_bw.c,
> and rename to intel_link_bw_compute_pipe_bpp().
>
> Cc: Shankar Uma
> Cc: Jani Nikula
> Cc: Imre Deak
>
1 - 100 of 151 matches
Mail list logo
