Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test

[Laura Abbott <labbott@redhat.com>]

On 3/15/19 1:13 PM, John Stultz wrote:
> On Fri, Mar 15, 2019 at 1:07 PM Laura Abbott <labbott@redhat.com> wrote:
>>
>> On 3/6/19 9:01 AM, John Stultz wrote:
>>> On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
>>> <benjamin.gaignard@linaro.org> wrote:
>>>> Le mar. 5 mars 2019 à 21:54, John Stultz <john.stultz@linaro.org> a écrit :
>>>>> +
>>>>> +       printf("Allocating 1 MEG\n");
>>>>> +       ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, &dmabuf_fd);
>>>>> +       if (ret)
>>>>> +               goto out;
>>>>> +
>>>>> +       /* DO SOMETHING WITH THE DMABUF HERE? */
>>>>
>>>> You can do a call to mmap and write a pattern in the buffer.
>>>
>>> Yea. I can also do some invalid allocations to make sure things fail properly.
>>>
>>> But I was talking a bit w/ Sumit about the lack of any general dmabuf
>>> tests, and am curious if we need to have a importer device driver that
>>> can validate its a real dmabuf and exercise more of the dmabuf ops.
>>>
>>> thanks
>>> -john
>>>
>>
>> There's the vgem driver in drm. I did some work to clean that
>> up so it could take an import af33a9190d02 ("drm/vgem: Enable dmabuf import
>> interfaces") . I mostly used it for private tests and never ended
>> up upstreaming any of the tests.
> 
> Thanks for the poitner, I'll check that out as well!  Also, if you
> still have them around, I'd be interested in checking out the tests to
> try to get something integrated into kselftest.
> 
> Talking with Brian yesterday, there was some thought that we should
> try to put together some sort of example dmabuf pipeline that isn't
> hardware dependent and can be used to demonstrate the usage model as
> well as validate the frameworks and maybe even benchmark some of the
> ideas floating around right now.  So suggestions here would be
> welcome!
> 

So the existing ion selftest (tools/testing/selftests/android/ion)
does make use of the import to do some very simple tests.
I can't seem to find the more complex tests I had though
they may have been lost during my last machine move :(

I do think building off of vgem would be a good first step
for a testing pipeline, although I worry we wouldn't be
able to measure caching effects without a real device since
setting up coherency testing otherwise seems error prone.

Thanks,
Laura

> thanks
> -john
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel