All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Add a policy note for removing workarounds
Date: Fri, 17 Nov 2017 09:33:49 -0800	[thread overview]
Message-ID: <20171117173349.pbbnxo4ayklsdomp@intel.com> (raw)
In-Reply-To: <87fu9d5fdr.fsf@intel.com>

On Fri, Nov 17, 2017 at 11:11:28AM +0000, Jani Nikula wrote:
> On Fri, 17 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > Rodrigo gave a persuasive argument for keeping workarounds: that they
> > serve as a good guide for the bring up of the next generation. Not only
> > do workarounds persist into the early revisions, they show where the
> > workarounds were previously added to the code flow and sometimes the old
> > workarounds have an explanation that give insight into their wider
> > implications.

Thanks! :)

> >
> > Based on his suggestion, document the policy that we want to keep the
> > workarounds from the current generation to guide the next. Older
> > preproduction workarounds we still want to remove to keep the code
> > clean.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index 57dfaf04d819..fbfa9434c1d1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -833,6 +833,11 @@ static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
> >   * We don't keep the workarounds for pre-production hardware, so we expect our
> >   * driver to fail on these machines in one way or another. A little warning on
> >   * dmesg may help both the user and the bug triagers.
> > + *
> > + * Our policy for removing pre-production workarounds is to keep the
> > + * current gen workarounds as a guide to the bring-up of the next gen
> > + * (workarounds have a habit of persisting!). Anything older than that
> > + * should be removed along with the complications they introduce.
> >   */

Maybe it would be good to mention that they should be at least protected
by the REVID checks if they stay around.

But with or without this change:

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>



> >  static void intel_detect_preproduction_hw(struct drm_i915_private *dev_priv)
> >  {
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-11-17 17:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 10:26 [PATCH] drm/i915: Add a policy note for removing workarounds Chris Wilson
2017-11-17 10:53 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-11-17 11:11 ` [PATCH] " Jani Nikula
2017-11-17 17:33   ` Rodrigo Vivi [this message]
2017-11-17 17:51     ` Chris Wilson
2017-11-17 12:36 ` ✓ Fi.CI.IGT: success for " Patchwork

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=20171117173349.pbbnxo4ayklsdomp@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@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.