KUnit tests for TTM subsystem

Karolina Stolarek karolina.stolarek at intel.com
Tue May 16 14:02:36 UTC 2023


Hi all,

I'm working on KUnit tests for TTM subsystem (nothing RFC-worthy yet), 
with an aim to provide better test coverage for the code used by i915 
and Xe. Before digging deeper, I wanted to check if the priorities 
outlined here make sense and clarify a couple of things.

My plan is to focus on testing the higher layer structs to cover what's 
below, e.g. test ttm_pool functions by testing ttm_device_init() and 
ttm_tt_populate(). I want to split the work into a couple of batches:

1. Basic testing of structs (init/fini and reserve/unreserve), with an 
introduction of fake VRAM resource manager to test ttm_resource_manager 
init. Add some ttm_bo_validate() test stubs.

2. Eviction-specific testing with ttm_bo_validate() to trigger 
ttm_mem_evict_first(), possibly with a separate testing of 
ttm_resource_*_bulk_move() and ttm_bo(un)pin(). Add tests for 
ttm_resource_manager struct, including ttm_sys_man.

3. ttm_tt_(un)populate() testing, adding more coverage to what was 
implemented in (1) and (2).

4. Testing of ttm_bo_vm_ops and mmap/kmap/other features offered by 
ttm_bo_util (not quite clear on how to approach it; suggestions are 
welcome).

Is there something else I should pay attention to here? I can share more 
detailed plan listing specific functions and what tests could cover 
what, if needed.

Also, I have a question on how should I treat drm_gem_object when 
testing ttm_buffer_object. From what I understand, the majority of 
drivers initialize and use the object, but the TTM BO can work without 
it. Should I write the tests against TTM-backed gem objects or use TTM 
BOs with a dummy gem object embedded?

Many thanks,
Karolina


More information about the dri-devel mailing list