From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keith Packard <keithp@keithp.com>
Subject: Re: [PATCH 2/2] drm/i915: Drop reference to current
	state wait req as soon as it goes unused
Date: Mon, 08 Aug 2016 08:49:07 -0700
Message-ID: <86oa53jm6k.fsf@hiro.keithp.com>
References: <1470655403-24036-1-git-send-email-maarten.lankhorst@linux.intel.com>
 <1470655403-24036-3-git-send-email-maarten.lankhorst@linux.intel.com>
 <CAKMK7uFWga4UfsghcKAHrH3kaa5+rMKygDQZ2COqRS06FqTevg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1174417914=="
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
In-Reply-To: <CAKMK7uFWga4UfsghcKAHrH3kaa5+rMKygDQZ2COqRS06FqTevg@mail.gmail.com>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Daniel Vetter <daniel@ffwll.ch>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel.vetter@intel.com>, intel-gfx <intel-gfx@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org>
List-Id: dri-devel@lists.freedesktop.org

--===============1174417914==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Daniel Vetter <daniel@ffwll.ch> writes:

> We still need to clean up the reference in case of failure, which
> means latest in intel_plane_destroy_state(). Also hanging onto a
> request isn't that evil really, why can't we just only clean up in the
> destroy function?

Sticking a cleanup there as well is good insurance, but it seems like a
reasonable policy to drop references when values go 'out of scope' as
they do in cleanup_plane_fb. But, you're right, we only *need* to drop
the reference in the destroy function, it's just that the state hangs
around until the next mode setting operation, which is likely to be days
away.

=2D-=20
=2Dkeith

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBV6ip89siGmkAAAARAQjbow//cui2uequeVNXsahW6yqTGqXObbn4m/NY
chLvVWiGFfxETnraPJNGjGl/ACI6PfbxoDOLVvcMyIixTkERf4e9aRW146q8rJWF
55GHFkprweFoLxzD7yFM9KXfY8L2qAjxuJoIfAxBm6a0vOs5Gss9Ft97i4F9Tvoa
Y2TAYLD839X3+1yO1TX/rLLxWCqEgXRX3xhUr2gmPaeOCqWkeeX1oqj/AkVVo8+f
75YHR3XC1GHyaIaaMeNfRS8j+Cy9/FFpKbiv9/Y2D/nzgusejEWYk9n2KMaxxy2j
6nmFWl56RULbpMKK/Asmr0kIZS9G1cfEZ+9GNL27KI1slGfHTTtfVWVmg6fxwCxK
mRLVjZa3XwPl4dCAfGnDj4tY7b6TG/ADrM6yWeLaE8CGHwTqSfFvMxWo6569/CV9
ZHlY2V3+q7A/OW8kpIVPwILvj+x9lmEfokHNbuIIEapoIBVnfOQb3MIGcCW6EeUR
8HLVsrcPqpD6YO4DAQS0ApRNgUZe62B7T7/MtfrKxruWKrkEGP8+sHdUVDQZaK0p
pWcbICVTlplatxBobYan7eruTZ2Exde+gi9wPIbyBTBivaP5oshWa0sfeABb36aE
vqUX/aSyH6a2fqwmLh+F5ynsgUlGzjlxxAzBrCA7S1oNG9SM6QkttMjK8cwGGgxb
53iTkLs6qcs=
=IhkK
-----END PGP SIGNATURE-----
--=-=-=--

--===============1174417914==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4
IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg==

--===============1174417914==--