All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915: Do only one posting read on forcewake put sequence
Date: Wed, 28 Jan 2015 15:48:49 +0200	[thread overview]
Message-ID: <20150128134849.GQ19354@intel.com> (raw)
In-Reply-To: <87r3uf825j.fsf@gaia.fi.intel.com>

On Wed, Jan 28, 2015 at 03:28:56PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > On Wed, Jan 28, 2015 at 02:43:25PM +0200, Mika Kuoppala wrote:
> >> commit 05a2fb157e44a53c79133805d30eaada43911941
> >> Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >> Date:   Mon Jan 19 16:20:43 2015 +0200
> >> 
> >>     drm/i915: Consolidate forcewake code
> >> 
> >> introduced domain handling where each domain has it's own posting
> >> read registers. This changed the forcewake sequence on 'put' side when
> >> there is multiple domains as there would be extra read between the domain
> >> puts. Any posting read should be enough to flush all the changes.
> >> 
> >> Do a posting read only once, at the end of the sequence and for
> >> the first domain. Like it was before.
> >> 
> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
> >
> > fwiw, I would argue that the posting read in _get() is superfluous as we
> > will serialise the fw with not only the ack, but any subsequent mmio.
> >
> > On the _put() side we do want to flush the write so that the hw can
> > power down as early as possible. So just kill the posting read from _get
> > and otherwise drop the patch. :)
> 
> Yes, both put/get patches should be dropped. I posted a patch removing
> the posting read on get side and with your explanations in commit message.
> 
> This all starts to make so much sense that some gen is bound to break ;)

IIRC the posting read from same cache line actually fixed real bugs. So
I'm a bit worried about dropping them. But I suppose it's possible only
the _put side was important for those bugs.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-01-28 13:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 12:43 [PATCH 1/3] drm/i915: Do uncore early sanitize after domain init Mika Kuoppala
2015-01-28 12:43 ` [PATCH 2/3] drm/i915: Do only one posting read on forcewake put sequence Mika Kuoppala
2015-01-28 12:58   ` Chris Wilson
2015-01-28 13:25     ` [PATCH] drm/i915: Don't do posting reads on getting forcewake Mika Kuoppala
2015-01-28 14:04       ` Chris Wilson
2015-01-30 16:16         ` Daniel Vetter
2015-01-31  9:13       ` shuang.he
2015-01-28 13:28     ` [PATCH 2/3] drm/i915: Do only one posting read on forcewake put sequence Mika Kuoppala
2015-01-28 13:48       ` Ville Syrjälä [this message]
2015-01-28 15:54         ` Mika Kuoppala
2015-01-28 16:43           ` Chris Wilson
2015-01-28 12:43 ` [PATCH 3/3] drm/i915: Do only one posting read on forcewake get sequence Mika Kuoppala
2015-01-28 12:59   ` Chris Wilson
2015-01-31  7:52   ` shuang.he
2015-01-28 13:01 ` [PATCH 1/3] drm/i915: Do uncore early sanitize after domain init Chris Wilson

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=20150128134849.GQ19354@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@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 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.