From: Eugeni Dodonov <eugeni.dodonov@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: hold forcewake around ring hw init
Date: Mon, 04 Jun 2012 09:47:54 -0300 [thread overview]
Message-ID: <4FCCAE7A.2030709@linux.intel.com> (raw)
In-Reply-To: <1338801495-30228-1-git-send-email-daniel.vetter@ffwll.ch>
On 06/04/2012 06:18 AM, Daniel Vetter wrote:
> Empirical evidence suggests that we need to: On at least one ivb
> machine when running the hangman i-g-t test, the rings don't properly
> initialize properly - the RING_START registers seems to be stuck at
> all zeros.
>
> Holding forcewake around this register init sequences makes chip reset
> reliable again. Note that this is not the first such issue:
>
> commit f01db988ef6f6c70a6cc36ee71e4a98a68901229
> Author: Sean Paul<seanpaul@chromium.org>
> Date: Fri Mar 16 12:43:22 2012 -0400
>
> drm/i915: Add wait_for in init_ring_common
>
> added delay loops to make RING_START and RING_CTL initialization
> reliable on the blt ring at boot-up. So I guess it won't hurt if we do
> this unconditionally for all force_wake needing gpus.
>
> To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
> intel_info bit for that.
>
> v2: Fixup missing commas in static struct and properly handling the
> error case in init_ring_common, both noticed by Jani Nikula.
>
> Cc: stable@vger.kernel.org
> Reported-by: Yang Guang<guang.a.yang@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
> Signed-Off-by: Daniel Vetter<daniel.vetter@ffwll.ch>
The new .has_forcewake looks nice! Just one very tiny bikeshed below :).
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> @@ -285,6 +285,7 @@ struct intel_device_info {
> u8 is_ivybridge:1;
> u8 is_valleyview:1;
> u8 has_pch_split:1;
> + u8 has_force_wake:1;
> u8 is_haswell:1;
> u8 has_fbc:1;
> u8 has_pipe_cxsr:1;
While you are on it, maybe it would make sense to move is_haswell up, so
all the 'is_*' and 'has_*' flags would stay together?
It is partly may fault though, due to the has_pch_split which ended up
in wrong place, but as you are touching those fields anyway, perhaps we
could rectify it for the future? :)
Eugeni
next prev parent reply other threads:[~2012-06-04 12:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 8:40 [PATCH] drm/i915: hold forcewake around ring hw init Daniel Vetter
2012-06-04 9:04 ` Jani Nikula
2012-06-04 9:16 ` Daniel Vetter
2012-06-04 9:21 ` Chris Wilson
2012-06-04 9:18 ` Daniel Vetter
2012-06-04 9:39 ` Daniel Vetter
2012-06-04 12:47 ` Eugeni Dodonov [this message]
2012-06-04 18:26 ` Daniel Vetter
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=4FCCAE7A.2030709@linux.intel.com \
--to=eugeni.dodonov@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=eugeni.dodonov@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
/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.