Re: [PATCH v5 00/21] Host1x/TegraDRM UAPI

[Dmitry Osipenko <digetx@gmail.com>]

28.01.2021 00:57, Mikko Perttunen пишет:
> 
> 
> On 1/27/21 11:26 PM, Dmitry Osipenko wrote:
>> 26.01.2021 05:45, Mikko Perttunen пишет:
>>>> 5. The hardware state of sync points should be reset when sync point is
>>>> requested, not when host1x driver is initialized.
>>>
>>> This may be doable, but I don't think it is critical for this UAPI, so
>>> let's consider it after this series.
>>>
>>> The userspace should anyway not be able to assume the initial value of
>>> the syncpoint upon allocation. The kernel should set it to some high
>>> value to catch any issues related to wraparound.
>>
>> This is critical because min != max when sync point is requested.
> 
> That I would just consider a bug, and it can be fixed. But it's
> orthogonal to whether the value gets reset every time the syncpoint is
> allocated.
> 
>>
>>> Also, this makes code more complicated since it now needs to ensure all
>>> waits on the syncpoint have completed before freeing the syncpoint,
>>> which can be nontrivial e.g. if the waiter is in a different virtual
>>> machine or some other device connected via PCIe (a real usecase).
>>
>> It sounds to me that these VM sync points should be treated very
>> separately from a generic sync points, don't you think so? Let's not mix
>> them and get the generic sync points usable first.
>>
> 
> They are not special in any way, I'm just referring to cases where the
> waiter (consumer) is remote. The allocator of the syncpoint (producer)
> doesn't necessarily even need to know about it. The same concern is
> applicable within a single VM, or single application as well. Just
> putting out the point that this is something that needs to be taken care
> of if we were to reset the value.

Will kernel driver know that it deals with a VM sync point?

Will it be possible to get a non-VM sync point explicitly?

If driver knows that it deals with a VM sync point, then we can treat it
specially, avoiding the reset and etc.