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

Mikko Perttunen
2021-01-14T10:35:34Z

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