From: "Souza, Jose" <jose.souza@intel.com>
To: "tvrtko.ursulin@linux.intel.com" <tvrtko.ursulin@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH CI 5/7] drm/i915: Drop has_ddi from device info
Date: Mon, 9 May 2022 14:01:39 +0000 [thread overview]
Message-ID: <2e649496c5028a4fdbcc655308e2f8d7f965fd94.camel@intel.com> (raw)
In-Reply-To: <e0c5e815-53a8-9759-948c-c180a8ecffdd@linux.intel.com>
On Mon, 2022-05-09 at 14:32 +0100, Tvrtko Ursulin wrote:
> On 05/05/2022 20:35, José Roberto de Souza wrote:
> > No need to have this parameter in intel_device_info struct
> > as all platforms with display version 9 or newer, haswell or broadwell
> > supports it.
> >
> > As a side effect of the of removal this flag, it will not be printed
> > in dmesg during driver load anymore and developers will have to rely
> > on to check the macro and compare with platform being used and IP
> > versions of it.
> >
> > Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +++-
> > drivers/gpu/drm/i915/i915_pci.c | 3 ---
> > drivers/gpu/drm/i915/intel_device_info.h | 1 -
> > 3 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 5538564bc1d25..600d8cee272da 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1298,7 +1298,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > #define HAS_DP20(dev_priv) (IS_DG2(dev_priv))
> >
> > #define HAS_CDCLK_CRAWL(dev_priv) (INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
> > -#define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi)
> > +#define HAS_DDI(dev_priv) (DISPLAY_VER(dev_priv) >= 9 || \
> > + IS_BROADWELL(dev_priv) || \
> > + IS_HASWELL(dev_priv))
>
> This one is a bit borderline, not sure it passes Jani's criteria of
> simplicity, which I thought was a good one. And from the OCD angle it
> kind of sucks to expand the conditionals to all call sites (when it's
> even called from i915_irq.c, justifiably or not I don't know).
This might increase code size but I don't believe it will case any performance impact even for interruption handling.
>
> What is the high level motivation for this work?
Add new platforms definitions are becoming huge burden, there is too many features to check if a new platform supports each one of it, what is leading
to platform definition errors.
Also usually when a feature is dropped a HSD will be filed, so the person taking care of that can just adjust the macro upper platform or IP bound and
disable it for good.
>
> Also, why is this in drm-intel-gt-next? :)
To reduce conflicts, moving just one of this patches around already causes conflicts.
>
> Regards,
>
> Tvrtko
>
>
> > #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->display.has_fpga_dbg)
> > #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr)
> > #define HAS_PSR_HW_TRACKING(dev_priv) \
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> > index 2dc0284629d30..a0693d9ff9cee 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -535,7 +535,6 @@ static const struct intel_device_info vlv_info = {
> > .platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) | BIT(VECS0), \
> > .display.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > - .display.has_ddi = 1, \
> > .display.has_fpga_dbg = 1, \
> > .display.has_dp_mst = 1, \
> > .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > @@ -683,7 +682,6 @@ static const struct intel_device_info skl_gt4_info = {
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
> > BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
> > .has_64bit_reloc = 1, \
> > - .display.has_ddi = 1, \
> > .display.has_fpga_dbg = 1, \
> > .display.fbc_mask = BIT(INTEL_FBC_A), \
> > .display.has_hdcp = 1, \
> > @@ -932,7 +930,6 @@ static const struct intel_device_info adl_s_info = {
> > .dbuf.size = 4096, \
> > .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | \
> > BIT(DBUF_S4), \
> > - .display.has_ddi = 1, \
> > .display.has_dmc = 1, \
> > .display.has_dp_mst = 1, \
> > .display.has_dsb = 1, \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
> > index bef65e3f02c55..bc71ce48763ad 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -167,7 +167,6 @@ enum intel_ppgtt_type {
> > func(cursor_needs_physical); \
> > func(has_cdclk_crawl); \
> > func(has_dmc); \
> > - func(has_ddi); \
> > func(has_dp_mst); \
> > func(has_dsb); \
> > func(has_dsc); \
next prev parent reply other threads:[~2022-05-09 14:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 19:35 [Intel-gfx] [PATCH CI 1/7] drm/i915: Drop has_gt_uc from device info José Roberto de Souza
2022-05-05 19:35 ` [Intel-gfx] [PATCH CI 2/7] drm/i915: Drop has_rc6 " José Roberto de Souza
2022-05-05 19:35 ` [Intel-gfx] [PATCH CI 3/7] drm/i915: Drop has_reset_engine " José Roberto de Souza
2022-05-05 19:35 ` [Intel-gfx] [PATCH CI 4/7] drm/i915: Drop has_logical_ring_elsq " José Roberto de Souza
2022-05-05 19:35 ` [Intel-gfx] [PATCH CI 5/7] drm/i915: Drop has_ddi " José Roberto de Souza
2022-05-09 13:32 ` Tvrtko Ursulin
2022-05-09 14:01 ` Souza, Jose [this message]
2022-05-09 14:27 ` Tvrtko Ursulin
2022-05-09 14:52 ` Souza, Jose
2022-05-09 14:05 ` Jani Nikula
2022-05-09 14:23 ` Souza, Jose
2022-05-10 7:48 ` Jani Nikula
2022-05-05 19:35 ` [Intel-gfx] [PATCH CI 6/7] drm/i915: Drop has_dp_mst " José Roberto de Souza
2022-05-05 19:35 ` [Intel-gfx] [PATCH CI 7/7] drm/i915: Drop has_psr " José Roberto de Souza
2022-05-05 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/7] drm/i915: Drop has_gt_uc " Patchwork
2022-05-05 20:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-05 21:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-06 0:57 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-05-19 10:35 ` [Intel-gfx] [PATCH CI 1/7] " Tvrtko Ursulin
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=2e649496c5028a4fdbcc655308e2f8d7f965fd94.camel@intel.com \
--to=jose.souza@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox