From: Oak Zeng <oak.zeng@intel.com>
To: intel-xe@lists.freedesktop.org
Subject: [CI v3 02/26] dma-mapping: provide an interface to allocate IOVA
Date: Tue, 28 May 2024 21:19:00 -0400 [thread overview]
Message-ID: <20240529011924.4125173-2-oak.zeng@intel.com> (raw)
In-Reply-To: <20240529011924.4125173-1-oak.zeng@intel.com>
From: Leon Romanovsky <leonro@nvidia.com>
Existing .map_page() callback provides two things at the same time:
allocates IOVA and links DMA pages. That combination works great for
most of the callers who use it in control paths, but less effective
in fast paths.
These advanced callers already manage their data in some sort of
database and can perform IOVA allocation in advance, leaving range
linkage operation to be in fast path.
Provide an interface to allocate/deallocate IOVA and next patch
link/unlink DMA ranges to that specific IOVA.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
include/linux/dma-map-ops.h | 3 +++
include/linux/dma-mapping.h | 20 ++++++++++++++++++++
kernel/dma/mapping.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+)
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index 4abc60f04209..bd605b44bb57 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -83,6 +83,9 @@ struct dma_map_ops {
size_t (*max_mapping_size)(struct device *dev);
size_t (*opt_mapping_size)(void);
unsigned long (*get_merge_boundary)(struct device *dev);
+
+ dma_addr_t (*alloc_iova)(struct device *dev, size_t size);
+ void (*free_iova)(struct device *dev, dma_addr_t dma_addr, size_t size);
};
#ifdef CONFIG_DMA_OPS
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a658de44ee9..176fb8a86d63 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -91,6 +91,16 @@ static inline void debug_dma_map_single(struct device *dev, const void *addr,
}
#endif /* CONFIG_DMA_API_DEBUG */
+struct dma_iova_attrs {
+ /* OUT field */
+ dma_addr_t addr;
+ /* IN fields */
+ struct device *dev;
+ size_t size;
+ enum dma_data_direction dir;
+ unsigned long attrs;
+};
+
#ifdef CONFIG_HAS_DMA
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
@@ -101,6 +111,9 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
return 0;
}
+int dma_alloc_iova(struct dma_iova_attrs *iova);
+void dma_free_iova(struct dma_iova_attrs *iova);
+
dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
size_t offset, size_t size, enum dma_data_direction dir,
unsigned long attrs);
@@ -159,6 +172,13 @@ void dma_vunmap_noncontiguous(struct device *dev, void *vaddr);
int dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
size_t size, struct sg_table *sgt);
#else /* CONFIG_HAS_DMA */
+static inline int dma_alloc_iova(struct dma_iova_attrs *iova)
+{
+ return -EOPNOTSUPP;
+}
+static inline void dma_free_iova(struct dma_iova_attrs *iova)
+{
+}
static inline dma_addr_t dma_map_page_attrs(struct device *dev,
struct page *page, size_t offset, size_t size,
enum dma_data_direction dir, unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 58db8fd70471..b6b27bab90f3 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -183,6 +183,36 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
}
EXPORT_SYMBOL(dma_unmap_page_attrs);
+int dma_alloc_iova(struct dma_iova_attrs *iova)
+{
+ struct device *dev = iova->dev;
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (dma_map_direct(dev, ops) || !ops->alloc_iova) {
+ iova->addr = 0;
+ return 0;
+ }
+
+ iova->addr = ops->alloc_iova(dev, iova->size);
+ if (dma_mapping_error(dev, iova->addr))
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL(dma_alloc_iova);
+
+void dma_free_iova(struct dma_iova_attrs *iova)
+{
+ struct device *dev = iova->dev;
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (dma_map_direct(dev, ops) || !ops->free_iova)
+ return;
+
+ ops->free_iova(dev, iova->addr, iova->size);
+}
+EXPORT_SYMBOL(dma_free_iova);
+
static int __dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir, unsigned long attrs)
{
--
2.26.3
next prev parent reply other threads:[~2024-05-29 1:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 1:18 [CI v3 01/26] mm/hmm: let users to tag specific PFNs Oak Zeng
2024-05-29 1:14 ` ✗ CI.Patch_applied: failure for series starting with [CI,v3,01/26] " Patchwork
2024-05-29 1:19 ` Oak Zeng [this message]
2024-05-29 1:19 ` [CI v3 03/26] dma-mapping: provide callbacks to link/unlink pages to specific IOVA Oak Zeng
2024-05-29 1:19 ` [CI v3 04/26] iommu/dma: Provide an interface to allow preallocate IOVA Oak Zeng
2024-05-29 1:19 ` [CI v3 05/26] iommu/dma: Prepare map/unmap page functions to receive IOVA Oak Zeng
2024-05-29 1:19 ` [CI v3 06/26] iommu/dma: Implement link/unlink page callbacks Oak Zeng
2024-05-29 1:19 ` [CI v3 07/26] drm: move xe_sg_segment_size to drm layer Oak Zeng
2024-05-29 1:19 ` [CI v3 08/26] drm: Move GPUVA_START/LAST to drm_gpuvm.h Oak Zeng
2024-05-29 1:19 ` [CI v3 09/26] drm/svm: add a mm field to drm_gpuvm struct Oak Zeng
2024-05-29 1:19 ` [CI v3 10/26] drm/svm: introduce drm_mem_region concept Oak Zeng
2024-05-29 1:19 ` [CI v3 11/26] drm/svm: introduce hmmptr and helper functions Oak Zeng
2024-05-29 1:19 ` [CI v3 12/26] drm/svm: Introduce helper to remap drm memory region Oak Zeng
2024-05-29 1:19 ` [CI v3 13/26] drm/svm: handle CPU page fault Oak Zeng
2024-05-29 1:19 ` [CI v3 14/26] drm/svm: Migrate a range of hmmptr to vram Oak Zeng
2024-05-29 1:19 ` [CI v3 15/26] drm/svm: Add DRM SVM documentation Oak Zeng
2024-05-29 1:19 ` [CI v3 16/26] drm/xe: s/xe_tile_migrate_engine/xe_tile_migrate_exec_queue Oak Zeng
2024-05-29 1:19 ` [CI v3 17/26] drm/xe: Add xe_vm_pgtable_update_op to xe_vma_ops Oak Zeng
2024-05-29 1:19 ` [CI v3 18/26] drm/xe: Convert multiple bind ops into single job Oak Zeng
2024-05-29 1:19 ` [CI v3 19/26] drm/xe: Update VM trace events Oak Zeng
2024-05-29 1:19 ` [CI v3 20/26] drm/xe: Update PT layer with better error handling Oak Zeng
2024-05-29 1:19 ` [CI v3 21/26] drm/xe: Retry BO allocation Oak Zeng
2024-05-29 1:19 ` [CI v3 22/26] drm/xe: Rework GPU page fault handling Oak Zeng
2024-05-29 1:19 ` [CI v3 23/26] drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_SYSTEM_ALLOCATOR flag Oak Zeng
2024-05-29 1:19 ` [CI v3 24/26] drm/xe: Add dma_addr res cursor Oak Zeng
2024-05-29 1:19 ` [CI v3 25/26] drm/xe: Use drm_mem_region for xe Oak Zeng
2024-05-29 1:19 ` [CI v3 26/26] drm/xe: use drm_hmmptr in xe Oak Zeng
-- strict thread matches above, loose matches on Subject: below --
2024-05-30 0:47 [CI v3 01/26] mm/hmm: let users to tag specific PFNs Oak Zeng
2024-05-30 0:47 ` [CI v3 02/26] dma-mapping: provide an interface to allocate IOVA Oak Zeng
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=20240529011924.4125173-2-oak.zeng@intel.com \
--to=oak.zeng@intel.com \
--cc=intel-xe@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox