From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Subject: Re: [PATCH] drm/i915: Share the common work of disabling active FBC before updating Date: Thu, 07 Jul 2011 13:52:26 -0700 Message-ID: References: <1310070619-19730-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1115201787==" Return-path: Received: from keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTP id E47C49E777 for ; Thu, 7 Jul 2011 13:52:31 -0700 (PDT) In-Reply-To: <1310070619-19730-1-git-send-email-chris@chris-wilson.co.uk> 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: Chris Wilson , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1115201787== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Thu, 7 Jul 2011 21:30:19 +0100, Chris Wilson = wrote: > Upon review, all path share the same dependencies for updating the > registers and so we can benefit from sharing the code and checking > early. yeah, looks good. > + if (intel_fbc_enabled(dev)) { > + /* We update FBC along two paths, after changing fb/crtc > + * configuration (modeswitching) and after page-flipping > + * finishes. For the latter, we know that not only did > + * we disable the FBC at the start of the page-flip > + * sequence, but also more than one vblank has passed. > + * > + * For the former case of modeswitching, it is possible > + * to switch between two FBC valid configurations > + * instantaneously so we do need to disable the FBC > + * before we can modify its control registers. We also > + * have to wait for the next vblank for that to take > + * effect. > + * > + * In the scenario that we go from a valid to invalid > + * and then back to valid FBC configuration we have > + * no strict enforcement that a vblank occurred since > + * disabling the FBC. However, along all current pipe > + * disabling paths we do need to wait for a vblank at > + * some point... > + */ > + DRM_DEBUG_KMS("disabling active FBC for update\n"); > + intel_disable_fbc(dev); > + intel_wait_for_vblank(dev, intel_crtc->pipe); > + } > + > intel_enable_fbc(crtc, 500); Should this path queue a worker function to re-enable FBC after 'a while'? Is there any particular reason it needs to be done synchronously here? That would avoid a 'wait_for_vblank' call with the mutex held. =2D-=20 keith.packard@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFOFhyKQp8BWwlsTdMRAruDAJ4wjnE+gwll17AgSWDB5fE7VCvoGQCfRyvV lqy6GFwYbKcXXX71xUe/Xdk= =mkUx -----END PGP SIGNATURE----- --=-=-=-- --===============1115201787== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1115201787==--