All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.