Re: [PATCH v2 26/37] drm/i915/gem: drop nth_page() usage within SG entry
David Hildenbrand <[email protected]>
| Newsgroups | com.zx2c4.lists.wireguard,dev.linux.lists.iommu,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-riscv,org.kernel.vger.io-uring,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-mips,org.kernel.vger.linux-mmc,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 02.09.25 11:22, Tvrtko Ursulin wrote: > > On 01/09/2025 16:03, 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: Lorenzo Stoakes <[email protected]> >> Cc: Jani Nikula <[email protected]> >> Cc: Joonas Lahtinen <[email protected]> >> Cc: Rodrigo Vivi <[email protected]> >> Cc: Tvrtko Ursulin <[email protected]> >> Cc: David Airlie <[email protected]> >> Cc: Simona Vetter <[email protected]> >> Signed-off-by: David Hildenbrand <[email protected]> >> --- >> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c >> index c16a57160b262..031d7acc16142 100644 >> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c >> @@ -779,7 +779,7 @@ __i915_gem_object_get_page(struct drm_i915_gem_object *obj, pgoff_t n) >> GEM_BUG_ON(!i915_gem_object_has_struct_page(obj)); >> >> sg = i915_gem_object_get_sg(obj, n, &offset); >> - return nth_page(sg_page(sg), offset); >> + return sg_page(sg) + offset; >> } >> >> /* Like i915_gem_object_get_page(), but mark the returned page dirty */ > > LGTM. If you want an ack to merge via a tree other than i915 you have > it. I suspect it might be easier to coordinate like that. Yeah, it would be best to route all of that through the MM tree. Thanks! -- Cheers David / dhildenb