From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 2/2] drm/doc: Update docs about device instance setup Date: Mon, 10 Aug 2015 14:34:18 +0200 Message-ID: <20150810123417.GA1262@ulmo.nvidia.com> References: <1439200538-25233-1-git-send-email-daniel.vetter@ffwll.ch> <1439200538-25233-2-git-send-email-daniel.vetter@ffwll.ch> <20150810115905.GY1262@ulmo.nvidia.com> <20150810120749.GX17734@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1474537888==" Return-path: In-Reply-To: <20150810120749.GX17734@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Daniel Vetter , Intel Graphics Development , DRI Development , Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org --===============1474537888== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NgLNC/STdjXvE6Rt" Content-Disposition: inline --NgLNC/STdjXvE6Rt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 02:07:49PM +0200, Daniel Vetter wrote: > On Mon, Aug 10, 2015 at 01:59:07PM +0200, Thierry Reding wrote: > > On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote: > > > ->load is depracated, bus functionst are deprecated and everyone > > > should use drm_dev_alloc®ister. > >=20 > > Why would you want to deprecated ->load()? Even if you use > > drm_dev_alloc() and drm_dev_register(), there's still use for ->load() > > because it gives you the subsystem-level initialization entry point. >=20 > ->load is called after the drm /dev node is registered and hence you can't > really do any driver setup in there without risking races. We paper over > that using drm_global_mutex, but that doesn't work for any other > driver/userspace interface like sysfs/debugfs because of deadlocks. >=20 > And we can't just reorder ->load to happen before the /dev nodes are > registered because a lot of drivers would fall over if we do that. >=20 > This is typical midlayer fail where the core calls into the driver instead > of the other way round. Okay, but then if we're going to deprecate ->load(), I think we should also come up with an upgrade plan. As it is, this just says that users shouldn't do ->load(), but it doesn't tell them what to do instead. Would the proper procedure be to fix drivers so that ->load() can be called between drm_dev_alloc() and drm_dev_register()? I suppose we could add some sort of (temporary) flag for drivers to signal this and then have drm_dev_register() call ->load() at the right time. If drivers don't support it, we can keep what we have. That, of course, doesn't get rid of the midlayer, so perhaps a better way forward would be to tell driver writers that they should be doing subsystem-level setup between drm_dev_alloc() and drm_dev_register(). Thierry --NgLNC/STdjXvE6Rt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJVyJpGAAoJEN0jrNd/PrOhjaoQAK9h79HOzBjjvXJKwhXwcHdv tvTPxcjAVrsGS8IroSC/0myJkEmSRUfpMf/8vThzQ/1YIlcWCYaS11TLL15mf9ib O6tp3BeuDA5sy0Eg0Ll4io+iyBjK66waQYvxxANgTFloQUb1Qk8ZXZQ/VnzV0oO2 9aiz1LAMpkZ7u5XN8spDGhhDfRjWHC7+uoNoRzw49IL02VDs+DZIOJPdbg+61mp0 s6tEuGGdP8wM000KghI+hHgkS2dCPtHiqs75NVuH/SD9eCK2OH0gzTrlHkFlDuDs 20yBzCJV9/0fHulyqHuSulBq0tD0X8VTn/HnJUpd+cRuSoPhjLr7TkQmRP7Kf+b1 nHAq5NuYZa5xuou2WBfOPxxfSnnk+EDN9Ro6gOR4IIJvZrgdqawXGX7iM64YDGKF V22asSMr5NSRVTADl4KRVRjkTHIBGdeSMIE0PTSufNXCj0Ei6tV7uMY2ZcX8DaiF jFRwW/vuOJ/80ekrVH0SIJiaZAqf9CVePr/yDeCJZpV8Ltf130rmVqXuWZT/tIBk q+aZWvhRNpaOUgIWvH4/2QGpYjRPY5GimjrOu/M5OcVZz74a//EK1RhgJgIj/cU6 MPpMaJbAje8ojVRRL9QRnJn6EONfGoFkKDtk9i+MQ6T2mVPE7VlonefE1J8atppp S43D9/BcOgE25DsCwixX =EtAY -----END PGP SIGNATURE----- --NgLNC/STdjXvE6Rt-- --===============1474537888== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1474537888==--