Am 12.04.2018 um 08:26 schrieb Christoph Hellwig:
On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote:
On 10/04/18 21:59, Sinan Kaya wrote:Yes, relying on dma_map_sg returning the same number of entries as passed
Code is expecing to observe the same number of buffers returned fromSo why not fix said code? It's clearly not a real hardware limitation, and
dma_map_sg() function compared to sg_alloc_table_from_pages(). This
doesn't hold true universally especially for systems with IOMMU.
the map_sg() APIs have potentially returned fewer than nents since forever,
so there's really no excuse.
it is completely bogus.
I agree that the common DRM functions should be able to deal with both, but we should let the driver side decide if it wants multiple addresses combined or not.
Agreed.IOMMU driver tries to combine buffers into a single DMA address as muchDisagree; this is a dodgy hack, since you'll now end up passing
as it can. The right thing is to tell the DMA layer how much combining
IOMMU can do.
scatterlists into dma_map_sg() which already violate max_seg_size to begin
with, and I think a conscientious DMA API implementation would be at rights
to fail the mapping for that reason (I know arm64 happens not to, but that
was a deliberate design decision to make my life easier at the time).
Sounds like my understanding of max_seg_size is incorrect, what exactly should that describe?