All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Souza, Jose" <jose.souza@intel.com>
To: "joonas.lahtinen@linux.intel.com"
	<joonas.lahtinen@linux.intel.com>,
	"tvrtko.ursulin@linux.intel.com" <tvrtko.ursulin@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 16/16] drm/i915: Drop display.has_fpga_db from device info
Date: Wed, 11 May 2022 13:56:43 +0000	[thread overview]
Message-ID: <97ae58c7a9d34021ab8950bdadb6b5d2910f5ec7.camel@intel.com> (raw)
In-Reply-To: <76397b0c-e4bc-1bd4-9620-7c677c01a004@linux.intel.com>

On Wed, 2022-05-11 at 08:39 +0100, Tvrtko Ursulin wrote:
> On 10/05/2022 08:41, Jani Nikula wrote:
> > On Tue, 10 May 2022, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> > > Quoting Souza, Jose (2022-05-09 17:19:28)
> > > > On Mon, 2022-05-09 at 15:38 +0300, Joonas Lahtinen wrote:
> > > > > Quoting José Roberto de Souza (2022-05-07 16:28:50)
> > > > > > No need to have this parameter in intel_device_info struct
> > > > > > as this feature is supported by Broadwell, Haswell all platforms with
> > > > > > display version 9 or newer.
> > > > > 
> > > > > This is opposite of the direction we want to move to.
> > > > > 
> > > > > We want to embrace the has_xyz flags, instead of the macro trickery.
> > > > 
> > > > This ever growing flag definition is causing problems when defining new platforms.
> > > 
> > > The ever growing macros that change between kernel versions are much
> > > more painful than easily printable list per SKU.
> > > 
> > > Just to make it clear, a strict NACK from me for merging any patches
> > > into this direction.
> > 
> > I was hoping to start a discussion to reach consensus on this with my
> > mail [1], adding all maintainers in Cc, but merging started before the
> > discussion really even started.
> > 
> > Obviously no further patches on this are to be merged, and the question
> > now is really what to do with the ones that were. Revert?
> 
>  From the process standpoint strictly yes, but in practice I think there 
> is no rush.
> 
> The ones which got merged I definitely do not like are:
> 
> Rc6 - because it creates an inconsistency where rc6p remains a device 
> info flag.
> 
> DDI - because it is not 100% trivial and used from i915_irq.c. But a) I 
> am not sure it is truly on an irq path, and b) it is display code so not 
> my call anyway. (Affects the DP MST one as well by inheritance.)
> 
> The others are at best lukewarm to me - primarily because I am not 
> convinced there is a benefit to it all. One day the need might come to 
> move them back if some platforms drops support or something, which would 
> be more churn. And it is handy to see a consolidated description of a 
> platform in dmesg when looking at bugs. So just not sure it's an 
> improvement.

If platform feature list print is a must, we could print those features converted to platform and IP checks in intel_device_info_print_runtime().

> 
> Give there is much more conversions proposed I guess it may make sense 
> to revert until overall consensus is achieved, since it may be odd to 
> have a handful if we decide to stop there.
> 
> Regards,
> 
> Tvrtko


  reply	other threads:[~2022-05-11 13:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07 13:28 [Intel-gfx] [PATCH 01/16] drm/i915: Drop has_llc from device info José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 02/16] drm/i915: Drop has_ipc " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 03/16] drm/i915/display: Disable DSB for DG2 and Alderlake-P José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 04/16] drm/i915: Drop has_rc6p from device info José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 05/16] drm/i915: Drop has_psr_hw_tracking " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 06/16] drm/i915: Drop supports_tv " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 07/16] drm/i915: Drop has_4tile " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 08/16] drm/i915: Drop has_64bit_reloc " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 09/16] drm/i915: Drop has_global_mocs " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 10/16] drm/i915: Drop has_guc_deprivilege " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 11/16] drm/i915: Drop has_pxp " José Roberto de Souza
2022-05-07 18:05   ` kernel test robot
2022-05-07 19:47   ` kernel test robot
2022-05-07 13:28 ` [Intel-gfx] [PATCH 12/16] drm/i915: Drop has_heci_gscfi " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 13/16] " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 14/16] drm/i915: Drop has_runtime_pm " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 15/16] drm/i915: Drop has_logical_ring_contexts " José Roberto de Souza
2022-05-07 13:28 ` [Intel-gfx] [PATCH 16/16] drm/i915: Drop display.has_fpga_db " José Roberto de Souza
2022-05-09 12:38   ` Joonas Lahtinen
2022-05-09 14:19     ` Souza, Jose
2022-05-10  6:25       ` Joonas Lahtinen
2022-05-10  7:41         ` Jani Nikula
2022-05-11  7:39           ` Tvrtko Ursulin
2022-05-11 13:56             ` Souza, Jose [this message]
2022-05-07 13:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/16] drm/i915: Drop has_llc " Patchwork
2022-05-07 13:43 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-07 13:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-07 15:01 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-05-09 11:09 ` [Intel-gfx] [PATCH 01/16] " Matthew Auld
2022-05-09 14:05   ` Souza, Jose
2022-05-09 14:52     ` Matthew Auld
2022-05-09 14:55       ` Souza, Jose

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=97ae58c7a9d34021ab8950bdadb6b5d2910f5ec7.camel@intel.com \
    --to=jose.souza@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /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.