Am 12.03.20 um 11:47 schrieb Christoph Hellwig:
On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
[SNIP]
I mean we could come up with a new structure for this, but to me that just
looks like reinventing the wheel. Especially since drivers need to be able
to handle both I/O to system memory and I/O to PCIe BARs.
The structure for holding the struct page side of the scatterlist is
called struct bio_vec, so far mostly used by the block and networking
code.
Yeah, I'm aware of this.
The structure for holding dma addresses doesn't really exist
in a generic form, but would be an array of these structures:
struct dma_sg {
dma_addr_t addr;
u32 len;
};
So the whole idea is to nuke scatterlist/sg_table in the long term and
switch over to using bio_vec as input and dma_sg as output for a DMA
mapping operation.
Is that correct? If yes I could live with that, but it makes my patchset
much more complicated.
Keeping them separate is important as most IOMMU drivers will return
less entries than you can feed them. E.g. if your input boundaries
are 4k aligned you will usually just get a single IOVA entry back.
I will soon also have a dma mapping interface that will take advantage
of that fact.
Yeah, I noticed as well that this is not really well handled.
Thanks for the feedback,
Christian.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
