[RFC PATCH v2 00/17] Host1x/TegraDRM UAPI
Mikko Perttunen
cyndis at kapsi.fi
Wed Sep 9 08:44:18 UTC 2020
On 9/9/20 5:20 AM, Dmitry Osipenko wrote:
> 05.09.2020 13:34, Mikko Perttunen пишет:
>> Hi all,
>>
>> here's a second revision of the Host1x/TegraDRM UAPI proposal,
>> hopefully with most issues from v1 resolved, and also with
>> an implementation. There are still open issues with the
>> implementation:
>>
>> * Relocs are now handled on TegraDRM side instead of Host1x,
>> so the firewall is not aware of them, causing submission
>> failure where the firewall is enabled. Proposed solution
>> is to move the firewall to TegraDRM side, but this hasn't
>> been done yet.
>> * For the new UAPI, syncpoint recovery on job timeout is
>> disabled. What this means is that upon job timeout,
>> all further jobs using that syncpoint are cancelled,
>> and the syncpoint is marked unusable until it is freed.
>> However, there is currently a race between the timeout
>> handler and job submission, where submission can observe
>> the syncpoint in non-locked state and yet the job
>> cancellations won't cancel the new job.
>> * Waiting for DMA reservation fences is not implemented yet.
>> * I have only tested on Tegra186.
>>
>> The series consists of three parts:
>>
>> * The first part contains some fixes and improvements to
>> the Host1x driver of more general nature,
>> * The second part adds the Host1x side UAPI, as well as
>> Host1x-side changes needed for the new TegraDRM UAPI,
>> * The third part adds the new TegraDRM UAPI.
>>
>> I have written some tests to test the new interface,
>> see https://github.com/cyndis/uapi-test. Porting of proper
>> userspace (e.g. opentegra, vdpau-tegra) will come once
>> there is some degree of conclusion on the UAPI definition.
>
> Could you please enumerate all the currently opened questions?
>
Which open questions do you refer to? The open items of v1 should be
closed now; for fences we setup an SW timeout to prevent them from
sticking around forever, and regarding GEM the GEM IOCTLs are again
being used.
More information about the dri-devel
mailing list