From: "Christian König" <christian.koenig@amd.com>
To: Karolina Stolarek <karolina.stolarek@intel.com>,
dri-devel@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Mauro Carvalho Chehab" <mauro.chehab@linux.intel.com>,
"Andi Shyti" <andi.shyti@linux.intel.com>
Subject: Re: KUnit tests for TTM subsystem
Date: Thu, 25 May 2023 10:30:05 +0200 [thread overview]
Message-ID: <7b324b38-833a-070e-7f95-e1bd2c48782f@amd.com> (raw)
In-Reply-To: <cc04343a-de20-4e60-aca0-695ba69253df@intel.com>
Hi Karolina,
Am 16.05.23 um 16:02 schrieb Karolina Stolarek:
>
> 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.
oh, yes please finally somebody taking care of this :)
>
> 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.
Sounds like a plan to me. But I suggest to start with the ttm_pool since
that one is easy to test and initialize without the
drm_device/drm_gem_object stuff etc... Write a patch for that, get it
reviewed and upstream and then extend from there.
>
> 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?
IIRC VMWGFX was the last one to not use the GEM object, but Zack
implemented that a whole ago. So the GEM object is now mandatory.
It should be trivial to initialize. Just see the GEM unit tests how to
come up with a dummy GEM driver and GEM objects. IIRC it was something
like 10 lines of code for the EXEC unit test I've wrote.
Thanks,
Christian.
>
> Many thanks,
> Karolina
next prev parent reply other threads:[~2023-05-25 8:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 14:02 KUnit tests for TTM subsystem Karolina Stolarek
2023-05-25 8:30 ` Christian König [this message]
2023-05-25 10:38 ` Karolina Stolarek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b324b38-833a-070e-7f95-e1bd2c48782f@amd.com \
--to=christian.koenig@amd.com \
--cc=andi.shyti@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=karolina.stolarek@intel.com \
--cc=mauro.chehab@linux.intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox