From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Jani Nikula" <jani.nikula@intel.com>,
"Ville Syrjälä" <ville.syrjala@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [RFC 1/4] drm/i915: Add Display Gen info.
Date: Tue, 30 Oct 2018 10:47:58 -0700 [thread overview]
Message-ID: <20181030174758.GD2164@intel.com> (raw)
In-Reply-To: <87va5joj6p.fsf@intel.com>
+cc Ville
On Tue, Oct 30, 2018 at 11:52:30AM +0200, Jani Nikula wrote:
> On Mon, 29 Oct 2018, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > Introduce Display Gen. The goal is to use this to minimize
> > the amount of platform codename checks we have nowdays on
> > display code.
> >
> > The introduction of a new platform should be just
> > gen >= current.
>
> So the patches 1-3 look nice for GLK. The thing that bugs me here is
> that this doesn't help VLV/CHV
Couldn't we define
cherryview platform with
DISPLAY_GEN(7) /* 7.5 */
and also a
#define IS_DISPLAY_GEN7_LP(dev_priv) IS_DISPLAY_GEN7(dev_priv) && IS_LP(dev_priv)
this would cover most of IS_CHERRYVIEW || IS_VALLEYVIEW code.
> GMCH display at all.
For GMCH I believe with this gen display range in place
we could use IS_DISPLAY(dev_priv, 2, 4) for most cases.
For the intersection with VLV/CHV I would define a
info.has_cxsr_wm
This would be a real feature based ting instead of "gmch_display"
> We'll still continue
> to have the more feature oriented HAS_GMCH_DISPLAY,
maybe very little cases would be:
IS_DISPLAY(dev_priv, 2, 4) || IS_DISPLAY_GEN7_LP(dev_priv)
so we could kill GMCH entirely.
> HAS_DDI, and
> HAS_PCH_SPLIT.
HAS_PCH_SPLIT makes sense in my opinion because of the south display
stuff that is on PCH. That one I would keep.
> Haswell display is still better represented by HAS_DDI
> than gen because it's 7.5.
Maybe this is also a place to define Haswell with:
DISPLAY_GEN(7) /* 7.5 */
And kill all HAS_DDI in favor of Display ranges as well.
>
> Patch 4 means continued pedantic review about not mixing up IS_GEN and
> IS_DISPLAY_GEN. If we aren't strict about the separation, then what's
> the point? It's not immediately obvious that it's worth the hassle. Only
> time will tell.
I agree it is not clear yet it's worth the hassle.
I believe that the conversion can be slowly with only places that
we are changing to have IS_DISPLAY_GEN(dev_priv) >= 7 we change
the entire block to use DISPLAY_GEN instead of IS_GEN or platform
codenames.
>
> I'll want to hear more opinions before merging.
Yeap, that's the idea here ;)
My ultimate goal is to stop the current mixed cases where we have
if INTEL_GEN > 11
else PLATFORM_CODENAME
and also expand the places where we have IS_ICELAKE
to be INTEL_GEN > 11
So adding the next gen gets easier and without bureaucracy
just gen++...
Thanks a lot for the comments,
Rodrigo.
>
> One note inline below.
>
>
> BR,
> Jani.
>
>
> >
> > Just a gen++ without exposing any new feature or ip.
> > so this would minimize the amount of patches needed
> > for a bring-up specially holding them on internal branches.
> >
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 28 ++++++++++++++++++++++--
> > drivers/gpu/drm/i915/i915_pci.c | 5 ++++-
> > drivers/gpu/drm/i915/intel_device_info.h | 2 ++
> > 3 files changed, 32 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index c9e5bab6861b..3242229688e3 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2349,8 +2349,9 @@ intel_info(const struct drm_i915_private *dev_priv)
> > #define INTEL_INFO(dev_priv) intel_info((dev_priv))
> > #define DRIVER_CAPS(dev_priv) (&(dev_priv)->caps)
> >
> > -#define INTEL_GEN(dev_priv) ((dev_priv)->info.gen)
> > -#define INTEL_DEVID(dev_priv) ((dev_priv)->info.device_id)
> > +#define INTEL_GEN(dev_priv) ((dev_priv)->info.gen)
> > +#define INTEL_DISPLAY_GEN(dev_priv) ((dev_priv)->info.display_gen)
> > +#define INTEL_DEVID(dev_priv) ((dev_priv)->info.device_id)
> >
> > #define REVID_FOREVER 0xff
> > #define INTEL_REVID(dev_priv) ((dev_priv)->drm.pdev->revision)
> > @@ -2363,6 +2364,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> > /* Returns true if Gen is in inclusive range [Start, End] */
> > #define IS_GEN(dev_priv, s, e) \
> > (!!((dev_priv)->info.gen_mask & INTEL_GEN_MASK((s), (e))))
> > +#define IS_DISPLAY_GEN(dev_priv, s, e) \
> > + (!!((dev_priv)->info.display_gen_mask & INTEL_GEN_MASK((s), (e))))
> >
> > /*
> > * Return true if revision is in range [since,until] inclusive.
> > @@ -2532,6 +2535,27 @@ intel_info(const struct drm_i915_private *dev_priv)
> > #define IS_GEN10(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(9)))
> > #define IS_GEN11(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(10)))
> >
> > +#define IS_DISPLAY_GEN2(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(2)))
> > +#define IS_DISPLAY_GEN3(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(3)))
> > +#define IS_DISPLAY_GEN4(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(4)))
> > +#define IS_DISPLAY_GEN5(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(5)))
> > +#define IS_DISPLAY_GEN6(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(6)))
> > +#define IS_DISPLAY_GEN7(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(7)))
> > +#define IS_DISPLAY_GEN8(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(8)))
> > +#define IS_DISPLAY_GEN9(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(9)))
> > +#define IS_DISPLAY_GEN10(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(10)))
> > +#define IS_DISPLAY_GEN11(dev_priv) (!!((dev_priv)->info.display_gen_mask \
> > + & BIT(11)))
>
> I know this is the same pattern as in IS_GEN<N> above, but shouldn't the
> compiler end up with the same result if these were simply:
>
> #define IS_DISPLAY_GEN2(dev_priv) IS_DISPLAY_GEN(dev_priv, 2, 2)
>
>
> > +
> > #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp)
> > #define IS_GEN9_LP(dev_priv) (IS_GEN9(dev_priv) && IS_LP(dev_priv))
> > #define IS_GEN9_BC(dev_priv) (IS_GEN9(dev_priv) && !IS_LP(dev_priv))
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> > index 44e745921ac1..fb8caf846c02 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -30,7 +30,10 @@
> > #include "i915_selftest.h"
> >
> > #define PLATFORM(x) .platform = (x), .platform_mask = BIT(x)
> > -#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1)
> > +#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), \
> > + .display_gen = (x), .display_gen_mask = BIT((x))
> > +/* Unless explicitly stated otherwise Display gen inherits platform gen */
> > +#define DISPLAY_GEN(x) .display_gen = (x), .display_gen_mask = BIT((x))
> >
> > #define GEN_DEFAULT_PIPEOFFSETS \
> > .pipe_offsets = { PIPE_A_OFFSET, PIPE_B_OFFSET, \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
> > index b4c2c4eae78b..9f31f29186a8 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -151,8 +151,10 @@ typedef u8 intel_ring_mask_t;
> > struct intel_device_info {
> > u16 device_id;
> > u16 gen_mask;
> > + u16 display_gen_mask;
> >
> > u8 gen;
> > + u8 display_gen;
> > u8 gt; /* GT number, 0 if undefined */
> > u8 num_rings;
> > intel_ring_mask_t ring_mask; /* Rings supported by the HW */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-10-30 17:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-30 0:34 [RFC 1/4] drm/i915: Add Display Gen info Rodrigo Vivi
2018-10-30 0:34 ` [RFC 2/4] drm/i915: Finally recognize Geminilake as Gen10 Display Rodrigo Vivi
2018-10-30 0:34 ` [RFC 3/4] drm/i915: Use Display gen9 for gen9_bc || bxt Rodrigo Vivi
2018-10-30 0:34 ` [RFC 4/4] drm/i915: Expand DISPLAY_GEN macro usage to display related files Rodrigo Vivi
2018-10-30 1:19 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/4] drm/i915: Add Display Gen info Patchwork
2018-10-30 1:21 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-10-30 1:39 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-10-30 9:52 ` [RFC 1/4] " Jani Nikula
2018-10-30 17:47 ` Rodrigo Vivi [this message]
2018-10-30 18:25 ` Lucas De Marchi
2018-10-31 8:13 ` Jani Nikula
2018-10-31 8:44 ` Tvrtko Ursulin
2018-10-31 9:00 ` Jani Nikula
2018-10-31 15:53 ` Rodrigo Vivi
2018-10-31 17:55 ` Jani Nikula
2018-10-31 18:13 ` Lucas De Marchi
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=20181030174758.GD2164@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=ville.syrjala@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