All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
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, dri-devel@lists.freedesktop.org,
	aravindh@quicinc.com, nganji@quicinc.com, pdhaval@quicinc.com
Subject: Re: [Intel-gfx] [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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Thread overview: 113+ 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 ` [Intel-gfx] " Ville Syrjala
2020-04-03 20:39 ` [PATCH v2 01/17] drm: Nuke mode->hsync Ville Syrjala
2020-04-03 20:39   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:30   ` Sam Ravnborg
2020-04-07 18:30     ` [Intel-gfx] " 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   ` [Intel-gfx] " Ville Syrjala
2020-04-03 20:39 ` [PATCH v2 03/17] drm: Nuke mode->vrefresh Ville Syrjala
2020-04-03 20:39   ` [Intel-gfx] " Ville Syrjala
2020-04-03 20:39   ` Ville Syrjala
2020-04-03 20:39   ` Ville Syrjala
2020-04-03 20:58   ` Laurent Pinchart
2020-04-03 20:58     ` [Intel-gfx] " Laurent Pinchart
2020-04-03 20:58     ` Laurent Pinchart
2020-04-03 20:58     ` Laurent Pinchart
2020-04-04  2:01   ` abhinavk
2020-04-04  2:01     ` [Intel-gfx] " abhinavk
2020-04-04  2:01     ` abhinavk
2020-04-04  2:01     ` abhinavk
2020-04-06  8:32     ` Jani Nikula
2020-04-06  8:32       ` [Intel-gfx] " Jani Nikula
2020-04-06  8:32       ` Jani Nikula
2020-04-06  8:32       ` Jani Nikula
2020-04-07  1:23       ` abhinavk
2020-04-07  1:23         ` [Intel-gfx] " abhinavk
2020-04-07  1:23         ` abhinavk
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   ` [Intel-gfx] " Ville Syrjala
2020-04-03 20:39   ` Ville Syrjala
2020-04-03 20:39 ` [PATCH v2 05/17] drm: Shrink {width,height}_mm to u16 Ville Syrjala
2020-04-03 20:39   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:37   ` Sam Ravnborg
2020-04-07 18:37     ` [Intel-gfx] [PATCH v2 05/17] drm: Shrink {width, height}_mm " Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 06/17] drm: Shrink mode->type to u8 Ville Syrjala
2020-04-03 20:39   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:38   ` Sam Ravnborg
2020-04-07 18:38     ` [Intel-gfx] " Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 07/17] drm: Make mode->flags u32 Ville Syrjala
2020-04-03 20:39   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:38   ` Sam Ravnborg
2020-04-07 18:38     ` [Intel-gfx] " Sam Ravnborg
2020-04-03 20:39 ` [PATCH v2 08/17] drm: Shrink drm_display_mode timings Ville Syrjala
2020-04-03 20:39   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:43   ` Sam Ravnborg
2020-04-07 18:43     ` [Intel-gfx] " Sam Ravnborg
2020-04-03 20:40 ` [PATCH v2 09/17] drm: Flatten drm_mode_vrefresh() Ville Syrjala
2020-04-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:46   ` Sam Ravnborg
2020-04-07 18:46     ` [Intel-gfx] " Sam Ravnborg
2020-04-03 20:40 ` [PATCH v2 10/17] drm: Shrink mode->private_flags Ville Syrjala
2020-04-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-07 18:52   ` Sam Ravnborg
2020-04-07 18:52     ` [Intel-gfx] " Sam Ravnborg
2020-04-07 19:10     ` Ville Syrjälä
2020-04-07 19:10       ` [Intel-gfx] " 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   ` [Intel-gfx] " Ville Syrjala
2020-04-06  0:24   ` kbuild test robot
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-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-07  7:27   ` Daniel Vetter
2020-04-07  7:27     ` [Intel-gfx] " Daniel Vetter
2020-04-07 18:53   ` Sam Ravnborg
2020-04-07 18:53     ` [Intel-gfx] " Sam Ravnborg
2020-04-12  0:42   ` Linus Walleij
2020-04-12  0:42     ` [Intel-gfx] " Linus Walleij
2020-04-03 20:40 ` [PATCH v2 13/17] drm/i915: Stop using mode->private_flags Ville Syrjala
2020-04-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-07  7:38   ` Daniel Vetter
2020-04-07  7:38     ` [Intel-gfx] " Daniel Vetter
2020-04-07 15:20     ` Ville Syrjälä
2020-04-07 15:20       ` [Intel-gfx] " Ville Syrjälä
2020-04-08  9:34       ` Jani Nikula
2020-04-08  9:34         ` 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-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-07  7:42   ` Daniel Vetter
2020-04-07  7:42     ` [Intel-gfx] " Daniel Vetter
2020-04-03 20:40 ` [PATCH v2 15/17] drm/gma500: Stop using mode->private_flags Ville Syrjala
2020-04-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-07  7:46   ` Daniel Vetter
2020-04-07  7:46     ` [Intel-gfx] " Daniel Vetter
2020-04-07 18:56   ` Sam Ravnborg
2020-04-07 18:56     ` [Intel-gfx] " Sam Ravnborg
2020-04-07 19:08     ` Ville Syrjälä
2020-04-07 19:08       ` [Intel-gfx] " Ville Syrjälä
2020-04-07 19:35       ` Sam Ravnborg
2020-04-07 19:35         ` [Intel-gfx] " Sam Ravnborg
2020-04-09 19:49         ` Ville Syrjälä
2020-04-09 19:49           ` [Intel-gfx] " Ville Syrjälä
2020-04-09 19:54           ` Ville Syrjälä
2020-04-09 19:54             ` [Intel-gfx] " Ville Syrjälä
2020-04-09 20:47           ` Sam Ravnborg
2020-04-09 20:47             ` [Intel-gfx] " Sam Ravnborg
2020-04-14 15:11             ` Ville Syrjälä
2020-04-14 15:11               ` [Intel-gfx] " Ville Syrjälä
2020-04-03 20:40 ` [PATCH v2 16/17] drm: Nuke mode->private_flags Ville Syrjala
2020-04-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-04  1:40   ` abhinavk
2020-04-04  1:40     ` [Intel-gfx] " abhinavk
2020-04-06  9:11     ` Jani Nikula
2020-04-06  9:11       ` [Intel-gfx] " Jani Nikula
2020-04-07  1:26       ` abhinavk [this message]
2020-04-07  1:26         ` abhinavk
2020-04-07 18:58   ` Sam Ravnborg
2020-04-07 18:58     ` [Intel-gfx] " Sam Ravnborg
2020-04-03 20:40 ` [PATCH v2 17/17] drm: Replace mode->export_head with a boolean Ville Syrjala
2020-04-03 20:40   ` [Intel-gfx] " Ville Syrjala
2020-04-03 22:04 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Put drm_display_mode on diet (rev2) Patchwork
2020-04-03 22:29 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-04-24 17:32 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Put drm_display_mode on diet (rev3) Patchwork

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.