From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 03/31] drm/i915: lock down pch pll accouting some more Date: Mon, 10 Jun 2013 17:47:21 +0300 Message-ID: <20130610144721.GC5004@intel.com> References: <1370432073-27634-1-git-send-email-daniel.vetter@ffwll.ch> <1370432073-27634-4-git-send-email-daniel.vetter@ffwll.ch> <20130607163256.GR5004@intel.com> <20130607200320.GA22870@phenom.ffwll.local> <20130607204608.GX5004@intel.com> <20130607211332.GC22870@phenom.ffwll.local> <20130610101145.GA5004@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 4E610E5C31 for ; Mon, 10 Jun 2013 07:47:30 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Mon, Jun 10, 2013 at 04:34:05PM +0200, Daniel Vetter wrote: > On Mon, Jun 10, 2013 at 12:11 PM, Ville Syrj=E4l=E4 > wrote: > > On Fri, Jun 07, 2013 at 11:13:32PM +0200, Daniel Vetter wrote: > >> On Fri, Jun 07, 2013 at 11:46:08PM +0300, Ville Syrj=E4l=E4 wrote: > >> > On Fri, Jun 07, 2013 at 10:03:20PM +0200, Daniel Vetter wrote: > >> > > On Fri, Jun 07, 2013 at 07:32:56PM +0300, Ville Syrj=E4l=E4 wrote: > >> > > > On Wed, Jun 05, 2013 at 01:34:05PM +0200, Daniel Vetter wrote: > >> > > > > Before I start to make a complete mess out of this, crank up > >> > > > > the paranoia level a bit. > >> > > > > > >> > > > > Signed-off-by: Daniel Vetter > >> > > > > --- > >> > > > > drivers/gpu/drm/i915/intel_display.c | 9 ++++++++- > >> > > > > 1 file changed, 8 insertions(+), 1 deletion(-) > >> > > > > > >> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gp= u/drm/i915/intel_display.c > >> > > > > index 56fb6ed..39e977f 100644 > >> > > > > --- a/drivers/gpu/drm/i915/intel_display.c > >> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c > >> > > > > @@ -1440,6 +1440,7 @@ static void intel_disable_pch_pll(struct= intel_crtc *intel_crtc) > >> > > > > } > >> > > > > > >> > > > > assert_pch_pll_enabled(dev_priv, pll, NULL); > >> > > > > + WARN_ON(!pll->on); > >> > > > > if (--pll->active) > >> > > > > return; > >> > > > > >> > > > Maybe a WARN_ON(pll->on) near the end of ironlake_enable_pch_pll= () too? > >> > > > >> > > At the very end we set on =3D true, and the only non-error early r= eturn > >> > > (when the active refcount is > 0 to begin with) has alreay a > >> > > WARN_ON(!pll->on). Shouldn't that be good enough? > >> > > >> > Well I was just thinking that since we have this dual bookeeping w/ > >> > active and on, maybe we want to warn if things go out of sync. > >> > >> Now I'm confused. I've tried to explain why I think we already have fu= ll > >> checking of pll->on in enable_shared_dpll ... Can you maybe show in a = diff > >> where you'd want to add more? > > > > Something like this: > > > > if (pll->active++) { > > WARN_ON(!pll->on); > > assert_pch_pll_enabled(dev_priv, pll, NULL); > > return; > > } > > + WARN_ON(pll->on); > = > That one's gonna misfire every time since we set pll->on =3D true only > at the end of the function in this case. > = > > and maybe also: > > + assert_pch_pll_disabled(dev_priv, pll, NULL); > = > This one should already be in the platform-specific pll->enable hook. > It's added in "drm/i915: enable/disable hooks for shared dplls" > = > > Or maybe just kill 'pll->on' as it seems totally redundant. > = > Yeah, I've considered that but independently checking pll->on with the > hw state and pll->active with the number of crtc using it looked > neated. I guess we could rip out pll->on as a follow-up though. > = > > Also maybe we could move most of the asserts and WARNs to some > > central location. Currently there are quite a few early return paths > > from the pll enable/disable functions, and I don't think we perform the > > same checks for all of the branches. So maybe we could just have one > > function that would cross-check pll->on, pll->active and the real hardw= are > > state. We could call said function just before and after > > enable/disable_pch_pll(). > = > The totally paranoid hw state cross checker does that at the very end > of each modeset. The checks in here are simply to assert a bunch of > edge transitions. And like I've said, I think I pretty much have it > all covered. Before we set pll->on to true, pll->on should be false, no? -- = Ville Syrj=E4l=E4 Intel OTC