dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: abhinavk@codeaurora.org
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	jeykumar@quicinc.com, Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	Emil Velikov <emil.l.velikov@gmail.com>,
	dri-devel@lists.freedesktop.org, aravindh@quicinc.com,
	nganji@quicinc.com, pdhaval@quicinc.com, sean@poorly.run
Subject: Re: [PATCH v2 16/17] drm: Nuke mode->private_flags
Date: Mon, 06 Apr 2020 18:26:38 -0700	[thread overview]
Message-ID: <b9fe52f5ff363c3631889b74cd34e3ec@codeaurora.org> (raw)
In-Reply-To: <87r1x1kmgr.fsf@intel.com>

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-07  1:27 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 20:39 [PATCH v2 00/17] drm: Put drm_display_mode on diet Ville Syrjala
2020-04-03 20:39 ` [PATCH v2 01/17] drm: Nuke mode->hsync Ville Syrjala
2020-04-07 18:30   ` Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 02/17] drm/i915: Introduce some local intel_dp variables Ville Syrjala
2020-04-03 20:39 ` [PATCH v2 03/17] drm: Nuke mode->vrefresh Ville Syrjala
2020-04-03 20:58   ` Laurent Pinchart
2020-04-04  2:01   ` abhinavk
2020-04-06  8:32     ` Jani Nikula
2020-04-07  1:23       ` abhinavk
2020-04-03 20:39 ` [PATCH v2 04/17] drm/msm/dpu: Stop copying around mode->private_flags Ville Syrjala
2020-04-03 20:39 ` [PATCH v2 05/17] drm: Shrink {width,height}_mm to u16 Ville Syrjala
2020-04-07 18:37   ` Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 06/17] drm: Shrink mode->type to u8 Ville Syrjala
2020-04-07 18:38   ` Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 07/17] drm: Make mode->flags u32 Ville Syrjala
2020-04-07 18:38   ` Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 08/17] drm: Shrink drm_display_mode timings Ville Syrjala
2020-04-07 18:43   ` Sam Ravnborg
2020-04-03 20:40 ` [PATCH v2 09/17] drm: Flatten drm_mode_vrefresh() Ville Syrjala
2020-04-07 18:46   ` Sam Ravnborg
2020-04-03 20:40 ` [PATCH v2 10/17] drm: Shrink mode->private_flags Ville Syrjala
2020-04-07 18:52   ` Sam Ravnborg
2020-04-07 19:10     ` Ville Syrjälä
2020-04-03 20:40 ` [PATCH v2 11/17] drm: pahole struct drm_display_mode Ville Syrjala
2020-04-03 20:40 ` [PATCH v2 12/17] drm/mcde: Use mode->clock instead of reverse calculating it from the vrefresh Ville Syrjala
2020-04-07  7:27   ` Daniel Vetter
2020-04-07 18:53   ` Sam Ravnborg
2020-04-12  0:42   ` Linus Walleij
2020-04-03 20:40 ` [PATCH v2 13/17] drm/i915: Stop using mode->private_flags Ville Syrjala
2020-04-07  7:38   ` Daniel Vetter
2020-04-07 15:20     ` Ville Syrjälä
2020-04-08  9:34       ` [Intel-gfx] " Jani Nikula
2020-04-03 20:40 ` [PATCH v2 14/17] drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean Ville Syrjala
2020-04-07  7:42   ` Daniel Vetter
2020-04-03 20:40 ` [PATCH v2 15/17] drm/gma500: Stop using mode->private_flags Ville Syrjala
2020-04-07  7:46   ` Daniel Vetter
2020-04-07 18:56   ` Sam Ravnborg
2020-04-07 19:08     ` Ville Syrjälä
2020-04-07 19:35       ` Sam Ravnborg
2020-04-09 19:49         ` Ville Syrjälä
2020-04-09 19:54           ` Ville Syrjälä
2020-04-09 20:47           ` Sam Ravnborg
2020-04-14 15:11             ` Ville Syrjälä
2020-04-03 20:40 ` [PATCH v2 16/17] drm: Nuke mode->private_flags Ville Syrjala
2020-04-04  1:40   ` abhinavk
2020-04-06  9:11     ` Jani Nikula
2020-04-07  1:26       ` abhinavk [this message]
2020-04-07 18:58   ` Sam Ravnborg
2020-04-03 20:40 ` [PATCH v2 17/17] drm: Replace mode->export_head with a boolean Ville Syrjala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9fe52f5ff363c3631889b74cd34e3ec@codeaurora.org \
    --to=abhinavk@codeaurora.org \
    --cc=aravindh@quicinc.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jeykumar@quicinc.com \
    --cc=nganji@quicinc.com \
    --cc=pdhaval@quicinc.com \
    --cc=sam@ravnborg.org \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).