From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH 1/3] drm/i915/gen11+: First assume next platforms will inherit stuff
Date: Mon, 11 Mar 2019 12:13:19 -0700 [thread overview]
Message-ID: <20190311191319.GA10454@intel.com> (raw)
In-Reply-To: <87k1h5lqqh.fsf@intel.com>
On Mon, Mar 11, 2019 at 11:12:06AM +0200, Jani Nikula wrote:
> On Fri, 08 Mar 2019, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> > On Fri, Mar 08, 2019 at 02:39:36PM -0800, Rodrigo Vivi wrote:
> >>> Given that every platform so far has had different oa configurations,
> >>> that looks to be a hasty assumption that future platforms will be fixed.
> >>
> >>I know... But my hope is that at some point it gets stabilized.
> >>
> >>Well, or at least start with this so any other gen11 could reuse and
> >>gen12 would start with that and change later for >= gen12 and on...
> >
> > If it's different, there's no harm in making this assumption now and
> > then later change to cover the differences. Making it consistent
> > everywhere allows to more easily add the next platform.
>
> At some point in time we deliberately made the if ladders and switch
> cases avoid matching future platforms, and liberally sprinkled
> MISSING_CASE() all over the place so we would catch each location that
> needed updating. So we wouldn't miss any.
>
> This is the opposite of that approach. I'm not against the new approach,
> because we do have a lot of places where the existing code just works,
> but if you do know something will break, or will need to be updated to
> work, why not use the MISSING_CASE() there?
If you know in advance and you don't have any internal patch handling that
a MISSING_CASE is useful indeed.
Notice that there were cases that I intentionally left ICL behind.
I will double check if I think this or any of those cases deserves
the MISSING_CASES, but my current guess is that we are fine without it.
Also I'm wondering if we should make some macros:
if GEN_GREATER_THAN(dev_priv, 11) {
icl_func();
}
#define GEN_GREATER_THAN(dev_priv, n) \
if n > latest_implemented_gen() \
MISSING_CASE()
or something like that...
hmm but this wouldn't help us later, when gen12 is
already defined in some internal and we might forget anyways...
so maybe something like
#define GEN_GREATER_THAN(dev_priv, g) \
if g != .gen \
DRM_DEBUG_DRIVER("Reusing %s from gen %d\n", __FUNCTION__, g)
But for now let's please just use this approach to save internal little
patches here and there.
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-03-11 19:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 21:42 [PATCH 1/3] drm/i915/gen11+: First assume next platforms will inherit stuff Rodrigo Vivi
2019-03-08 21:42 ` [PATCH 2/3] drm/i915: Move PCH_NOP to -1 Rodrigo Vivi
2019-03-08 21:43 ` [PATCH 3/3] drm/i915: Start using comparative INTEL_PCH_TYPE Rodrigo Vivi
2019-03-13 17:30 ` Lucas De Marchi
2019-03-13 20:02 ` Rodrigo Vivi
2019-03-08 21:58 ` ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/gen11+: First assume next platforms will inherit stuff Patchwork
2019-03-08 22:23 ` [PATCH 1/3] " Chris Wilson
2019-03-08 22:39 ` Rodrigo Vivi
2019-03-09 7:43 ` Lucas De Marchi
2019-03-11 9:12 ` Jani Nikula
2019-03-11 19:13 ` Rodrigo Vivi [this message]
2019-03-12 10:27 ` Jani Nikula
2019-03-08 22:41 ` ✓ Fi.CI.BAT: success for series starting with [1/3] " Patchwork
2019-03-09 4:53 ` ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2019-03-04 22:48 [PATCH 1/3] " Rodrigo Vivi
2019-03-05 17:12 ` Lucas De Marchi
2019-03-05 17:43 ` Tvrtko Ursulin
2019-03-05 18:36 ` 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=20190311191319.GA10454@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=lucas.demarchi@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