From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 1/3] drm/i915: Enable FBC at Haswell. Date: Tue, 16 Apr 2013 16:37:50 +0300 Message-ID: <20130416133750.GI4469@intel.com> References: <1365457784-3412-1-git-send-email-rodrigo.vivi@gmail.com> <1365457784-3412-2-git-send-email-rodrigo.vivi@gmail.com> <20130409083534.GJ4469@intel.com> <20130410081815.GX4469@intel.com> <20130416102847.GG4469@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id BBFC6E6442 for ; Tue, 16 Apr 2013 06:38:21 -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: Rodrigo Vivi Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Tue, Apr 16, 2013 at 10:23:17AM -0300, Rodrigo Vivi wrote: > Yeah, this makes sense. Yes, I tested many times here, with 0 at bit 28 I > always got that bug with missing updates, In the way it is it always work= ed > fine. So did you actually test with this config? FBC_CTL 28 =3D 1 0:3 =3D 0 DPFC_CONTROL_SA 29 =3D 1 0:4 =3D fence number Oh, and for this test you should make sure fence reg !=3D 0, so that we can find out for sure whether the FBC_CTL bits 0:3 have some real effect. > On Tue, Apr 16, 2013 at 7:28 AM, Ville Syrj=E4l=E4 < > ville.syrjala@linux.intel.com> wrote: > = > > On Mon, Apr 15, 2013 at 06:14:46PM -0300, Rodrigo Vivi wrote: > > > On Wed, Apr 10, 2013 at 5:18 AM, Ville Syrj=E4l=E4 < > > > ville.syrjala@linux.intel.com> wrote: > > > > > > > On Tue, Apr 09, 2013 at 03:13:10PM -0300, Rodrigo Vivi wrote: > > > > > On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrj=E4l=E4 < > > > > ville.syrjala@linux.intel.com > > > > > > wrote: > > > > > > > > > > > On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote: > > > > > > > This patch introduce Frame Buffer Compression (FBC) support f= or > > HSW. > > > > > > > It adds a new function haswell_enable_fbc to avoid getting > > > > > > > ironlake_enable_fbc messed with many IS_HASWELL checks. > > > > > > > > > > > > > > Signed-off-by: Rodrigo Vivi > > > > > > > --- > > > > > > > drivers/gpu/drm/i915/i915_drv.c | 1 + > > > > > > > drivers/gpu/drm/i915/i915_reg.h | 6 ++++++ > > > > > > > drivers/gpu/drm/i915/intel_pm.c | 44 > > > > > > ++++++++++++++++++++++++++++++++++++++++- > > > > > > > 3 files changed, 50 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > > > b/drivers/gpu/drm/i915/i915_drv.c > > > > > > > index 0cfc778..88fd6fb 100644 > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > > > > @@ -291,6 +291,7 @@ static const struct intel_device_info > > > > > > intel_haswell_m_info =3D { > > > > > > > GEN7_FEATURES, > > > > > > > .is_haswell =3D 1, > > > > > > > .is_mobile =3D 1, > > > > > > > + .has_fbc =3D 1, > > > > > > > }; > > > > > > > > > > > > > > static const struct pci_device_id pciidlist[] =3D { = /* > > aka > > > > */ > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > > > > b/drivers/gpu/drm/i915/i915_reg.h > > > > > > > index 5e91fbb..cb8e213 100644 > > > > > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > > > > > @@ -849,6 +849,12 @@ > > > > > > > #define SNB_CPU_FENCE_ENABLE (1<<29) > > > > > > > #define DPFC_CPU_FENCE_OFFSET 0x100104 > > > > > > > > > > > > > > +/* Framebuffer compression for Haswell */ > > > > > > > +#define HSW_FBC_RT_BASE 0x7020 > > > > > > > +#define HSW_FBC_RT_BASE_ADDR_SHIFT 12 > > > > > > > + > > > > > > > +#define HSW_DPFC_CTL_FENCE_EN (1<<28) > > > > > > > +#define HSW_DPFC_CTL_DISABLE_SLB_INIT (1<<15) > > > > > > > > > > > > > > /* > > > > > > > * GPIO regs > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > > > > b/drivers/gpu/drm/i915/intel_pm.c > > > > > > > index 27f94cd..94e1c3a 100644 > > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > > > > > @@ -253,6 +253,43 @@ static bool ironlake_fbc_enabled(struct > > > > drm_device > > > > > > *dev) > > > > > > > return I915_READ(ILK_DPFC_CONTROL) & DPFC_CTL_EN; > > > > > > > } > > > > > > > > > > > > > > +static void haswell_enable_fbc(struct drm_crtc *crtc, unsign= ed > > long > > > > > > interval) > > > > > > > +{ > > > > > > > + struct drm_device *dev =3D crtc->dev; > > > > > > > + struct drm_i915_private *dev_priv =3D dev->dev_private; > > > > > > > + struct drm_framebuffer *fb =3D crtc->fb; > > > > > > > + struct intel_framebuffer *intel_fb =3D > > to_intel_framebuffer(fb); > > > > > > > + struct drm_i915_gem_object *obj =3D intel_fb->obj; > > > > > > > + struct intel_crtc *intel_crtc =3D to_intel_crtc(crtc); > > > > > > > + int plane =3D intel_crtc->plane =3D=3D 0 ? DPFC_CTL_PLA= NEA : > > > > > > DPFC_CTL_PLANEB; > > > > > > > + unsigned long stall_watermark =3D 200; > > > > > > > + u32 dpfc_ctl; > > > > > > > + > > > > > > > + dpfc_ctl =3D I915_READ(ILK_DPFC_CONTROL); > > > > > > > + dpfc_ctl |=3D (plane | DPFC_CTL_LIMIT_1X); > > > > > > > > > > > > Accroding to BSpec FBC is always tied to plane A. Bit 30 is MBZ. > > > > > > > > > > > > > > > > Yeah, you are right. I'm going to add a verification at begining > > like: > > > > > if (intel_crtc->plane !=3D PLANE_A) { > > > > > dev_priv->no_fbc_reason =3D FBC_BAD_PLANE; > > > > > return; > > > > > } > > > > > > > > > > > > > > > > Maybe fix up plane C FBC support for IVB while you're poking at= the > > > > > > general direction? > > > > > > > > > > > > > > > > Actually I wasn't trying general directions since I splited it ou= t. > > It > > > > was > > > > > just bad copy and paste actually. > > > > > > > > I'm not a fan of copy pasting code and letting the old code paths r= ot. > > > > > > > > > > > > > > > > > + dpfc_ctl |=3D (HSW_DPFC_CTL_FENCE_EN | obj->fence_reg); > > > > > > > > > > > > The CPU fence field must be written with 0. SNB/IVB could do wi= th > > the > > > > > > same fix. > > > > > > > > > > > > > > > > Where did you get this restriction for HSW? > > > > > > > > BSpec. > > > > > > > > > > Are you talking about bit 28 of 43208h DevHSW? > > > > Bits 0:3 of the same register. > > > > > I couldn't find this restriction anywhere. > > > Besides that, setting it to 0 made me experience bugs like missing so= me > > > small screen updates. I mean, when it is 0 I missed many "****" when > > typing > > > my login password. > > > When it is set FBC works fine. > > > > This is what BSpec is telling us to program: > > > > FBC_CTL > > 28 =3D ? > > 0:3 =3D 0 > > > > DPFC_CONTROL_SA > > 29 =3D 1 > > 0:4 =3D fence number > > > > So the FBC_CTL bit 28 is not clear. BSpec doesn't say whether it should > > be 0 or 1. Did you try both values for that bit? > > > > -- > > Ville Syrj=E4l=E4 > > Intel OTC > > > = > = > = > -- = > Rodrigo Vivi > Blog: http://blog.vivi.eng.br -- = Ville Syrj=E4l=E4 Intel OTC