All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
	Francois Dugast <francois.dugast@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v1 1/5] drm/pagemap: Use struct drm_pagemap_device_addr in mapping and copy functions
Date: Wed, 23 Jul 2025 14:10:21 +0200	[thread overview]
Message-ID: <2d8a89feb294cb98107bcf55ac23dd329dacbebc.camel@linux.intel.com> (raw)
In-Reply-To: <aHnHhjpD06Wqz4W+@lstrano-desk.jf.intel.com>

On Thu, 2025-07-17 at 21:03 -0700, Matthew Brost wrote:
> On Thu, Jul 17, 2025 at 03:38:23PM +0200, Francois Dugast wrote:
> > This struct embeds more information than just the DMA address. This
> > will help
> > later to support folio orders greater than zero. At this point,
> > there is no
> > functional change as the only struct member used is addr.
> > 
> 
> This patch alone will break the build. You'll need to combine it with
> the next patch to avoid build breakage.
> 
> > Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> > Cc: Matthew Brost <matthew.brost@intel.com>
> > ---
> >  drivers/gpu/drm/drm_pagemap.c | 58 +++++++++++++++++--------------
> > ----
> >  include/drm/drm_pagemap.h     |  8 ++---
> >  2 files changed, 33 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_pagemap.c
> > b/drivers/gpu/drm/drm_pagemap.c
> > index 1da55322af12..0ed66aaade14 100644
> > --- a/drivers/gpu/drm/drm_pagemap.c
> > +++ b/drivers/gpu/drm/drm_pagemap.c
> > @@ -202,7 +202,7 @@ static void drm_pagemap_get_devmem_page(struct
> > page *page,
> >  /**
> >   * drm_pagemap_migrate_map_pages() - Map migration pages for GPU
> > SVM migration
> >   * @dev: The device for which the pages are being mapped
> > - * @dma_addr: Array to store DMA addresses corresponding to mapped
> > pages
> > + * @device_addr: Array to store DMA information corresponding to
> > mapped pages
> >   * @migrate_pfn: Array of migrate page frame numbers to map
> >   * @npages: Number of pages to map
> >   * @dir: Direction of data transfer (e.g., DMA_BIDIRECTIONAL)
> > @@ -215,7 +215,7 @@ static void drm_pagemap_get_devmem_page(struct
> > page *page,
> >   * Returns: 0 on success, -EFAULT if an error occurs during
> > mapping.
> >   */
> >  static int drm_pagemap_migrate_map_pages(struct device *dev,
> > -					 dma_addr_t *dma_addr,
> > +					 struct
> > drm_pagemap_device_addr *device_addr,
> 
> I like the change to drm_pagemap_device_addr—I think it fits with the
> patch—but it's not actually a device address. It's a DMA mapping of
> CPU
> memory. Originally, drm_pagemap_device_addr was intended to represent
> a
> device memory address shared between devices. That said, I think it
> still works for our purpose here.
> 
> So, I suggest we rename it:
> s/drm_pagemap_device_addr/drm_pagemap_addr
> And for the variable:
> s/device_addr/pagemap_addr

IIRC regardless of referencing system pages or device pages, both are
actually dma mappings.

So would drm_pagemap_dma_addr be a better fit? FWIW I'm OK with both.

Thanks,
Thomas


  reply	other threads:[~2025-07-23 12:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 13:38 [PATCH v1 0/5] Prepare GPU SVM for migration of THP Francois Dugast
2025-07-17 13:38 ` [PATCH v1 1/5] drm/pagemap: Use struct drm_pagemap_device_addr in mapping and copy functions Francois Dugast
2025-07-18  4:03   ` Matthew Brost
2025-07-23 12:10     ` Thomas Hellström [this message]
2025-07-17 13:38 ` [PATCH v1 2/5] drm/xe/svm: Use struct drm_pagemap_device_addr Francois Dugast
2025-07-18  4:12   ` Matthew Brost
2025-07-17 13:38 ` [PATCH v1 3/5] drm/pagemap: DMA map folios when possible Francois Dugast
2025-07-18  4:21   ` Matthew Brost
2025-07-20 19:53   ` Matthew Brost
2025-07-17 13:38 ` [PATCH v1 4/5] drm/xe/migrate: Use order to calculate migration length Francois Dugast
2025-07-18  4:27   ` Matthew Brost
2025-07-17 13:38 ` [PATCH v1 5/5] drm/pagemap: Allocate folios when possible Francois Dugast
2025-07-18  4:41   ` Matthew Brost
2025-07-18  5:49     ` Matthew Brost
2025-07-20 20:53       ` Matthew Brost
2025-07-17 14:25 ` ✗ CI.checkpatch: warning for Prepare GPU SVM for migration of THP Patchwork
2025-07-17 14:26 ` ✓ CI.KUnit: success " Patchwork
2025-07-17 15:34 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-18 22:46 ` ✗ Xe.CI.Full: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d8a89feb294cb98107bcf55ac23dd329dacbebc.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.