From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 09/16] drm/irq: Use unsigned int pipe in public API Date: Fri, 25 Sep 2015 14:26:36 +0200 Message-ID: <20150925122636.GB30567@ulmo> References: <1443112538-9616-1-git-send-email-thierry.reding@gmail.com> <1443112538-9616-9-git-send-email-thierry.reding@gmail.com> <20150924192153.GD21513@n2100.arm.linux.org.uk> <20150924202054.GI26517@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1337305393==" Return-path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by gabe.freedesktop.org (Postfix) with ESMTPS id 13FB16F0CD for ; Fri, 25 Sep 2015 05:26:39 -0700 (PDT) Received: by wicge5 with SMTP id ge5so18435482wic.0 for ; Fri, 25 Sep 2015 05:26:37 -0700 (PDT) In-Reply-To: <20150924202054.GI26517@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: Thomas Hellstrom , Russell King - ARM Linux , Alison Wang , dri-devel@lists.freedesktop.org, Tomi Valkeinen , Laurent Pinchart , Benjamin Gaignard , Alex Deucher , Daniel Vetter , Christian =?utf-8?B?S8O2bmln?= , Ben Skeggs List-Id: dri-devel@lists.freedesktop.org --===============1337305393== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 24, 2015 at 11:20:54PM +0300, Ville Syrj=C3=A4l=C3=A4 wrote: > On Thu, Sep 24, 2015 at 08:21:53PM +0100, Russell King - ARM Linux wrote: > > On Thu, Sep 24, 2015 at 06:35:31PM +0200, Thierry Reding wrote: > > > This continues the pattern started in commit cc1ef118fc09 ("drm/irq: > > > Make pipe unsigned and name consistent"). This is applied to the publ= ic > > > APIs and driver callbacks, so pretty much all drivers need to be upda= ted > > > to match the new prototypes. > >=20 > > I don't like being forced to use the "pipe" naming in all drivers; I > > found that really confusing when I first looked at DRM, and it took > > a long time to work out that "pipe" basically means "crtc" or "gpu". >=20 > crtc mean "cathode ray tube controller". If you weren't used to it, > it would be pretty much impossible to guess what piece of modern > hardware that means. So I think it's more a case of "a lot of this > junk used to be in what people called the crtc, so we'll call > this modern thing a crtc too". Although I think most of the > hardware people moved on from using that name quite a long time ago. >=20 > "gpu" can mean either just the part that does the rendering and=20 > whatnot, or it can mean the entire graphics "card". But calling > a display pipeline a "gpu" is not done. Now _that_ would be > confusing. >=20 > "pipe" is fairly nice term, meaning "pipeline". That describes the > thing quite nicely. Stuff comes in from one end, flows through the > pipe, and goes out the other end. >=20 > At least both Intel and OMAP used the term pipe or pipeline in the > hardware docs. Can't really say aything about other brands, at least > if I discount the more ancient junk I'm familiar with. >=20 > > What's wrong with keeping "crtc" as the index terminology for crtc > > things? Surely that's more descriptive of what's going on here? >=20 > I can't speak for Thierry, but I assume the real motivation for this > renaming was to make it clear which is the "index", and which is the > crtc object. "pipe" for one, "crtc" for the other. Avoids having > to call the object "dcrtc", "drm_crtc" or something else entirely. > And since the object is called "crtc" everywhere else, it's nice not > to have to make an exception in the vblank code. Exactly this. I find it to be very confusing to read through drivers and see completely inconsistent naming for what's really the same thing. The list isn't limited to "pipe", "crtc" or "index". There are others that use "head" or "crtc_id". The latter in particular is very confusing because, at least in most of the cases I've seen, it refers to the pipe rather than the CRTC object ID. That said this is all only temporary, though it may take us a while to get rid of it. The ultimate goal is to convert all drivers over to using struct drm_crtc * everywhere, at which point we don't have to bother with what to call the CRTC index. As a preliminary step, having drivers use consistent naming is hopefully going to make it easier to replace. Thierry --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWBT17AAoJEN0jrNd/PrOhqs8P/jEqZP4cw88FB1jKAA+JfWlx zNuzEubFLCf2a+Xrer+HrmrrLNBbMfP8NQY11tRcZpSAuV7D0+WmI5IwnMW6REjc YznX0GtKULJA5Q21ODSWu0EDHzC5anwmYEIaYKcUWgQmkxAQDq0vuKB7L6VW08PR SRefA/YtIWL1J61gFO/cl/eT+AcmHWuqhGiyAVcG4/7M/RowPOEk9DGmmMcjshia F60Zb92nLW3m4gcp+C07IUdaCiBuwfIzTIrQ/ErLP23Z85j2b2xp/iSug4vnMfo1 m8brIXzRk9DXP1f9ijW40uguyeVVx+4HDn0dn5U84Wa2WQwgfCzu+6CeU4S3f/jZ e+UsbSybLN1ncPwNuCTQ2S/KbfAEXpFWlw/c9DTsWGxQ+eyM1SFBlaxQZK/X1Gdi CYJXS2OBk7ZWGvUCePzqhIkosGNZoVce3qM6QbUHaW49TLpTL0kO2eelVY1iPytS dPufZuBwNOYHiaAsVGSfRYglSRlm5VArowVhPoal52o9aKAoKaAdhaE6d7ziJiS5 g5Jlc+FG1db64Rl1KdSPbHA6rS6bb4YDtekOxlMn6R57Zvl2Cz/eJ+pByAHzkuam Z86ppaO/WRJPEFQEIVkm2BWtvhHlThYI5KL5tLUoFV9qj1voF8qoIC4JzgWmW0ct hLaEqg1p3hLMjEWJMKe4 =DxyB -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- --===============1337305393== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1337305393==--