Quoting Michel Thierry (2017-10-26 19:54:06)
> On 26/10/17 11:51, Michel Thierry wrote:
> > Try to create as many clients as it is currently possible (currently
> > limited to max number of doorbells) and exercise the doorbell
> > alloc/dealloc code.
> >
> > Since our usage mode require very few clients/doorbells, this code has
> > been exercised very lightly and it's good to have a simple test for it.
> >
> > As reference, this test already helped identify the bug fixed by
> > commit 7f1ea2ac3017 ("drm/i915/guc: Fix doorbell id selection").
> >
> > v2: Extend number of clients; check for client allocation failure when
> > number of doorbells is exceeded; validate client properties; reuse
> > guc_init_doorbell_hw (Chris).
>
> This will conflict with Michal's patch ("Add a second client, to be used
> for preemption") but I want to get feedback about reusing
> guc_init_doorbell_hw in the selftest.
It's more work, but I think you basically want both. You want unittests
for the individual lowlevel functions, plus you want to unittest init_hw
as it will typically be called after reset so a failure there may be
hard to disentangle from the cause of the reset.
In essence, we want to treat the doorbell data struct as a library api
and so exercise its contract (if it was easy enough, I would suggest
mocking the hw interactions). And then similar at the next level, we
want to look at the interface guc exposes to the driver and check that
behaves as expected (that is more akin to live testing with hw).
As such, they are probably two different subtests. :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
