[PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem

Thomas Hellström thomas.hellstrom at linux.intel.com
Tue May 18 12:04:48 UTC 2021


On 5/18/21 1:55 PM, Christian König wrote:
>
>
> Am 18.05.21 um 10:26 schrieb Thomas Hellström:
>> The internal ttm_bo_util memcpy uses vmap functionality, and while it
>> probably might be possible to use it for copying in- and out of
>> sglist represented io memory, using io_mem_reserve() / io_mem_free()
>> callbacks, that would cause problems with fault().
>> Instead, implement a method mapping page-by-page using kmap_local()
>> semantics. As an additional benefit we then avoid the occasional global
>> TLB flushes of vmap() and consuming vmap space, elimination of a 
>> critical
>> point of failure and with a slight change of semantics we could also 
>> push
>> the memcpy out async for testing and async driver develpment purposes.
>> Pushing out async can be done since there is no memory allocation 
>> going on
>> that could violate the dma_fence lockdep rules.
>>
>> For copies from iomem, use the WC prefetching memcpy variant for
>> additional speed.
>>
>> Note that drivers that don't want to use struct io_mapping but relies on
>> memremap functionality, and that don't want to use scatterlists for
>> VRAM may well define specialized (hopefully reusable) iterators for 
>> their
>> particular environment.
>
> In general yes please since I have that as TODO for TTM for a very 
> long time.
>
> But I would prefer to fix the implementation in TTM instead and give 
> it proper cursor handling.
>
> Amdgpu is also using page based iomem and we are having similar 
> workarounds in place there as well.
>
> I think it makes sense to unify this inside TTM and remove the old 
> memcpy util function when done.
>
> Regards,
> Christian.

Christian,

I was thinking when we replace the bo.mem with a pointer (and perhaps 
have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all mapping 
in one way or another). That would mean perhaps land this is i915 now 
and sort out the unification once the struct ttm_resource, struct 
ttm_buffer_object separation has landed?

/Thomas




More information about the dri-devel mailing list