lkml.org 
[lkml]   [2020]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2] drm/prime: fix extracting of the DMA addresses from a scatterlist
On Fri, Mar 27, 2020 at 6:31 PM Ruhl, Michael J
<michael.j.ruhl@intel.com> wrote:
> Is there an example of what the scatterlist would look like in this case?
>
> Does each SG entry always have the page and dma info? or could you have
> entries that have page information only, and entries that have dma info only?
>
> If the same entry has different size info (page_len = PAGE_SIZE,
> dma_len = 4 * PAGE_SIZE?), are we guaranteed that the arrays (page and addrs) have
> been sized correctly?
>
> Just trying to get my head wrapped around this.
>
> Thanks,
>
> Mike
>

My understanding is that page_len and dma_len in this case could have
different values (looking at iommu_dma_map_sg within dma-iommu.c),
this seems to add some padding calculated by using the device iova
domain to s_length but sg_dma_len is set to the original length

The scatterlists table can also get reduced down within
"__finalise_sg" possibly causing (if reduced) the dma_len of the last
table elements to be 0 (page_len would not be 0 in this case).

Documentation around looping & accessing scatterlists in DMA-API.txt
states that sg_dma_address() and sg_dma_len() should be used when
accessing addr and len rather than sg->address and sg->length.

Maybe it would be worth splitting this out into 2 functions to avoid
potential issues with the above use case ?

Regards,

Shane Francis

\
 
 \ /
  Last update: 2020-03-28 19:37    [W:0.193 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site