All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@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 17:54:14 +0200	[thread overview]
Message-ID: <87h9va99zt.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20150128134849.GQ19354@intel.com>

Ville Syrjälä <ville.syrjala@linux.intel.com> writes:

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

I found these:

commit 6af2d180f82151cf3d58952e35a4f96e45bc453a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 26 16:24:50 2012 +0200

    drm/i915: fix forcewake related hangs on snb

commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Sep 1 22:59:50 2012 -0700

    drm/i915: Never read FORCEWAKE

https://bugs.freedesktop.org/show_bug.cgi?id=51738
https://bugs.freedesktop.org/show_bug.cgi?id=52424

The snb here seems to survive gem_dummy_reloc_loop and
gem_ring_sync_loop in here with the get side posting removed.

-Mika

>
> -- 
> 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 15:54 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ä
2015-01-28 15:54         ` Mika Kuoppala [this message]
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=87h9va99zt.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@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.