[PATCH v8 8/8] drm/ttm/tests: Add test cases dependent on fence signaling

Karolina Stolarek karolina.stolarek at intel.com
Wed Dec 6 11:49:53 UTC 2023


Hi Andi,

> For next time, I find it difficult to follow all these variables,
> it's easier to read
> 
> 	man = ttm_manager_type(priv->ttm_dev, TTM_PL_SYSTEM);
> 
> than
> 
> 	mem_type = TTM_PL_SYSTEM;
> 	...
> 	...
> 	...
> 	man = ttm_manager_type(priv->ttm_dev, mem_type);
> 
> 
>> +	bo = ttm_bo_kunit_init(test, test->priv, size);
>> +	bo->type = bo_type;
> 
> same here... the bo_type variable is not giving any value.
> 
> 	bo->type = ttm_bo_type_device;
> 
> is way more readable. You keep doing this all the way and I need
> to check everytime what's the value in the declaration :-)

The idea was that I'd provide these as parameters, but I limited the
scope of my tests and stick to set values. Also, in some cases, I
defined them because I keep checking for them in assertions, and didn't
want to repeat myself.

> 
> I'm not going to comment on this anymore.
> 
>> +	if (params->with_ttm) {
>> +		old_tt = priv->ttm_dev->funcs->ttm_tt_create(bo, 0);
>> +		ttm_pool_alloc(&priv->ttm_dev->pool, old_tt, &ctx);
>> +		bo->ttm = old_tt;
>> +	}
>> +
>> +	err = ttm_resource_alloc(bo, place, &bo->resource);
>> +	KUNIT_EXPECT_EQ(test, err, 0);
>> +	KUNIT_ASSERT_EQ(test, man->usage, size);
>> +
>> +	placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
>> +	KUNIT_ASSERT_NOT_NULL(test, placement);
>> +
>> +	ttm_bo_reserve(bo, false, false, NULL);
>> +	err = ttm_bo_validate(bo, placement, &ctx);
>> +	dma_resv_unlock(bo->base.resv);
> 
> why don't you use here ttm_bo_unreserve()?

That's a good question! I think that unreserve would work here as well.

(...)

>> +static void ttm_bo_validate_move_fence_signaled(struct kunit *test)
>> +{
>> +	struct ttm_test_devices *priv = test->priv;
>> +	struct ttm_buffer_object *bo;
>> +	struct ttm_place *place;
>> +	struct ttm_placement *placement;
>> +	struct ttm_resource_manager *man;
>> +	enum ttm_bo_type bo_type = ttm_bo_type_device;
>> +	uint32_t mem_type = TTM_PL_SYSTEM;
>> +	struct ttm_operation_ctx ctx = { };
>> +	uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
>> +	int err;
>> +
>> +	man = ttm_manager_type(priv->ttm_dev, mem_type);
>> +	spin_lock_init(&fence_lock);
> 
> where are we using the fence_lock here?

Argh, it's a copy-paste mistake, sorry. We don't need it, as we use a
stub fence in man->move. I will delete that.

> 
>> +	man->move = dma_fence_get_stub();
>> +
>> +	bo = ttm_bo_kunit_init(test, test->priv, size);
>> +	bo->type = bo_type;
>> +	place = ttm_place_kunit_init(test, mem_type, 0);
>> +	placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
>> +
>> +	ttm_bo_reserve(bo, false, false, NULL);
>> +	err = ttm_bo_validate(bo, placement, &ctx);
>> +	dma_resv_unlock(bo->base.resv);
>> +
>> +	KUNIT_EXPECT_EQ(test, err, 0);
>> +	KUNIT_EXPECT_EQ(test, bo->resource->mem_type, mem_type);
>> +	KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
> 
> Do we want to check also bo->ttm here?

Hmm, I think that I covered that case with "normal" testing of
ttm_bo_validate, and kept this one minimal. Here, I'm just making sure
that a signaled move fence doesn't get into a way of BO validation.

> 
>> +	ttm_bo_put(bo);
>> +	dma_fence_put(man->move);
>> +}
>> +
>> +static const struct ttm_bo_validate_test_case ttm_bo_validate_wait_cases[] = {
>> +	{
>> +		.description = "Waits for GPU",
>> +		.no_gpu_wait = false,
>> +	},
>> +	{
>> +		.description = "Tries to lock straight away",
>> +		.no_gpu_wait = true,
>> +	},
>> +};
>> +
>> +KUNIT_ARRAY_PARAM(ttm_bo_validate_wait, ttm_bo_validate_wait_cases,
>> +		  ttm_bo_validate_case_desc);
>> +
>> +static int threaded_fence_signal(void *arg)
>> +{
>> +	struct dma_fence *fence = arg;
>> +	int err;
>> +
>> +	msleep(20);
>> +	err = dma_fence_signal(fence);
>> +
>> +	return err;
> 
> if you do here "return dma_fence_signal(fence);" you don't need
> for err.

That is true!

> Not a binding review, though, your choice.

You spotted a couple of things I can improve, so I plan to include them 
in the next version, after getting more review comments.

All the best,
Karolina


More information about the dri-devel mailing list