diff mbox series

[v2,16/17] drm: Nuke mode->private_flags

Message ID 20200403204008.14864-17-ville.syrjala@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series drm: Put drm_display_mode on diet | expand

Commit Message

Ville Syrjälä April 3, 2020, 8:40 p.m. UTC
From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The last two uses of mode->private_flags (in i915 and gma500)
are now gone. So let's remove mode->private_flags entirely.

CC: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 include/drm/drm_modes.h | 10 ----------
 1 file changed, 10 deletions(-)

Comments

Abhinav Kumar April 4, 2020, 1:40 a.m. UTC | #1
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

Thanks

Abhinav

On 2020-04-03 13:40, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The last two uses of mode->private_flags (in i915 and gma500)
> are now gone. So let's remove mode->private_flags entirely.
> 
> CC: Sam Ravnborg <sam@ravnborg.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  include/drm/drm_modes.h | 10 ----------
>  1 file changed, 10 deletions(-)
> 
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 47d62b9d8d20..1e97138a9b8c 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -348,16 +348,6 @@ struct drm_display_mode {
>  	 */
>  	u8 type;
> 
> -	/**
> -	 * @private_flags:
> -	 *
> -	 * Driver private flags. private_flags can only be used for mode
> -	 * objects passed to drivers in modeset operations. It shouldn't be 
> used
> -	 * by atomic drivers since they can store any additional data by
> -	 * subclassing state structures.
> -	 */
> -	u8 private_flags;
> -
>  	/**
>  	 * @head:
>  	 *
Jani Nikula April 6, 2020, 9:11 a.m. UTC | #2
On Fri, 03 Apr 2020, abhinavk@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
Abhinav Kumar April 7, 2020, 1:26 a.m. UTC | #3
Hi Jani

On 2020-04-06 02:11, Jani Nikula wrote:
> On Fri, 03 Apr 2020, abhinavk@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
Sam Ravnborg April 7, 2020, 6:58 p.m. UTC | #4
On Fri, Apr 03, 2020 at 11:40:07PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The last two uses of mode->private_flags (in i915 and gma500)
> are now gone. So let's remove mode->private_flags entirely.
> 
> CC: Sam Ravnborg <sam@ravnborg.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Nice quest.

Reviewed-by: Sam Ravnborg <sam@ravnborg.org>


> ---
>  include/drm/drm_modes.h | 10 ----------
>  1 file changed, 10 deletions(-)
> 
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 47d62b9d8d20..1e97138a9b8c 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -348,16 +348,6 @@ struct drm_display_mode {
>  	 */
>  	u8 type;
>  
> -	/**
> -	 * @private_flags:
> -	 *
> -	 * Driver private flags. private_flags can only be used for mode
> -	 * objects passed to drivers in modeset operations. It shouldn't be used
> -	 * by atomic drivers since they can store any additional data by
> -	 * subclassing state structures.
> -	 */
> -	u8 private_flags;
> -
>  	/**
>  	 * @head:
>  	 *
> -- 
> 2.24.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
diff mbox series

Patch

diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 47d62b9d8d20..1e97138a9b8c 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -348,16 +348,6 @@  struct drm_display_mode {
 	 */
 	u8 type;
 
-	/**
-	 * @private_flags:
-	 *
-	 * Driver private flags. private_flags can only be used for mode
-	 * objects passed to drivers in modeset operations. It shouldn't be used
-	 * by atomic drivers since they can store any additional data by
-	 * subclassing state structures.
-	 */
-	u8 private_flags;
-
 	/**
 	 * @head:
 	 *