[Intel-gfx] [PATCH v2 16/17] drm: Nuke mode->private_flags
abhinavk at codeaurora.org
abhinavk at codeaurora.org
Tue Apr 7 01:26:38 UTC 2020
Hi Jani
On 2020-04-06 02:11, Jani Nikula wrote:
> On Fri, 03 Apr 2020, abhinavk at codeaurora.org wrote:
>> Hi Ville
>>
>> Thanks for the patch.
>>
>> Our understanding of private_flags was that we can use it within our
>> drivers to handle vendor specific features.
>> Hence we do have several features in our downstream drivers as well as
>> some planned work based on this.
>>
>> This was the only method to pass around and consume the driver only
>> information which we have been using.
>>
>> In the current qualcomm upstream display drivers, the only usage of
>> the
>> mode->private_flags is what you have removed in
>> https://patchwork.kernel.org/patch/11473497/.
>>
>> However, for other projects which do not use upstream drivers yet, we
>> have several features already which are using the mode->private_flags.
>>
>> We do have a plan to remove the usage of mode->private_flags for those
>> drivers as well but its not ready yet.
>>
>> These downstream drivers still use the upstream drm files for
>> compilation.
>>
>> So how it works is we use all the headers under include/drm and also
>> the
>> files under drivers/gpu/drm as-it-is from upstream but maintain our
>> drivers on top of this.
>>
>> Removing this will result in compilation failures for us in the near
>> term.
>>
>> Can we keep this one as-it-is and when our changes are ready to post
>> it
>> upstream we shall remove private_flags from the drm_modes.h
>
> If your driver were upstream, Ville would have fixed it in the process
> of removing private_flags. It would be part of this patch series. That
> is the only guarantee you get for kernel internal APIs, and you only
> get
> that guarantee for drivers in the upstream kernel. Otherwise, all bets
> are off.
>
> Taking all the upstream considerations into account is complicated
> enough. It is simply not reasonable to hold back internal kernel
> changes
> due to out-of-tree or downstream drivers. I know it is painful, but
> that's the cost of maintaining a driver out-of-tree.
>
> Sorry, but no. Further reading [1].
>
>
> BR,
> Jani.
>
>
> [1]
> https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html
Thanks for the response. We will plan to remove mode->private_flags in
our downstream driver as well.
Abhinav
More information about the Intel-gfx
mailing list