[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