[PATCH v5 15/21] drm/tegra: Add new UAPI to header

[Mikko Perttunen]

On 1/14/21 10:36 AM, Dmitry Osipenko wrote:
> 13.01.2021 21:56, Mikko Perttunen пишет:
>> On 1/13/21 8:14 PM, Dmitry Osipenko wrote:
>>> 11.01.2021 16:00, Mikko Perttunen пишет:
>>>> +struct drm_tegra_submit_buf {
>>>> +    /**
>>>> +     * @mapping_id: [in]
>>>> +     *
>>>> +     * Identifier of the mapping to use in the submission.
>>>> +     */
>>>> +    __u32 mapping_id;
>>>
>>> I'm now in process of trying out the UAPI using grate drivers and this
>>> becomes the first obstacle.
>>>
>>> Looks like this is not going to work well for older Tegra SoCs, in
>>> particular for T20, which has a small GART.
>>>
>>> Given that the usefulness of the partial mapping feature is very
>>> questionable until it will be proven with a real userspace, we should
>>> start with a dynamic mappings that are done at a time of job submission.
>>>
>>> DRM already should have everything necessary for creating and managing
>>> caches of mappings, grate kernel driver has been using drm_mm_scan for a
>>> long time now for that.
>>>
>>> It should be fine to support the static mapping feature, but it should
>>> be done separately with the drm_mm integration, IMO.
>>>
>>> What do think?
>>>
>>
>> Can you elaborate on the requirements to be able to use GART? Are there
>> any other reasons this would not work on older chips?
> 
> We have all DRM devices in a single address space on T30+, hence having
> duplicated mappings for each device should be a bit wasteful.

I guess this should be pretty easy to change to only keep one mapping 
per GEM object.

> 
>> I think we should keep CHANNEL_MAP and mapping_ids, but if e.g. for GART
>> we cannot do mapping immediately at CHANNEL_MAP time, we can just treat
>> it as a "registration" call for the GEM object - potentially no-op like
>> direct physical addressing is. We can then do whatever is needed at
>> submit time. This way we can have the best of both worlds.
> 
> I have some thoughts now, but nothing concrete yet. Maybe we will need
> to create a per-SoC ops for MM.

Yep, I think some specialized code will be needed, but hopefully it will 
be relatively minor.

> 
> I'll finish with trying what we currently have to see what else is
> missing and then we will decide what to do about it.
> 

Great :)

>> Note that partial mappings are already not present in this version of
>> the UAPI.
> 
> Oh, right :) I haven't got closely to this part of reviewing yet.
> 

Mikko