From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 08/12] drm/irq: Add kms-native crtc interface functions Date: Thu, 15 May 2014 12:42:12 +0200 Message-ID: <20140515104211.GI6434@ulmo> References: <1400093477-3217-1-git-send-email-daniel.vetter@ffwll.ch> <1400093477-3217-9-git-send-email-daniel.vetter@ffwll.ch> <20140515073425.GC5952@ulmo> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1281648124==" Return-path: In-Reply-To: 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: Intel Graphics Development , DRI Development List-Id: dri-devel@lists.freedesktop.org --===============1281648124== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OfrWf2Fun5Ae4m0Y" Content-Disposition: inline --OfrWf2Fun5Ae4m0Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 15, 2014 at 12:10:16PM +0200, Daniel Vetter wrote: > On Thu, May 15, 2014 at 9:34 AM, Thierry Reding > wrote: > > This seems slightly backwards. Since drm_vblank_get() is what's being > > deprecated here, wouldn't it make more sense to write > > drm_crtc_vblank_get() in terms of struct drm_crtc and make > > drm_vblank_get() call that instead? I can't seem to find a helper to get > > the CRTC from an index, but it seems like that wouldn't be hard to do. >=20 > Two reasons against this: > - More ugly churn since it's a flag day, and when handling vblank > refactorings what I _definitely_ want to avoid is whole-subsystem wide > flag days. > - drm_crtc_ is the common prefix used by many of the crtc functions. >=20 > What I actually forgotten to do is drop the dev parameter, we can fish > that out of the crtc. Then it should be even more obvious that this is > a crtc function and rightfully deserve the drm_crtc_ prefix ;-) I think you misunderstood what I was saying. What I proposed wasn't that drm_vblank_get() was replaced by a new implementation with different signature. Rather my suggestion was to implement the old drm_vblank_get() by calling drm_crtc_vblank_get() rather than the other way around. Something like this: int drm_crtc_vblank_get(struct drm_crtc *crtc) { new code using CRTC } int drm_vblank_get(struct drm_device *drm, int crtc) { struct drm_crtc *c =3D drm_crtc_from_index(crtc); return drm_crtc_vblank_get(c); } > > I guess it doesn't matter all that much either way, though, since we > > could equally well make that change when drm_vblank_get() is dropped, in > > which case at least there's no longer a need for the reverse lookup. >=20 > Yeah, the reverse lookup is something I want to add later on > eventually. But that requires more thought since it only makes sense > if we also switch the driver callbacks for vblank_enable/disable over. On that note, is there a plan to move the vblank fields out of the DRM device and into drm_crtc as well? That seems like a logical next step since presumably every CRTC can handle it's own vblank events itself. Thierry --OfrWf2Fun5Ae4m0Y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTdJoDAAoJEN0jrNd/PrOhiGMP/A7Jaw6omi3jnRFMzXMRxRHt 2CSO0iPGU1TvU4NE43yYAOVdfOaaYFRXr4xB64QPoQv853J0q5Yjwx8Tt9Ca3tRP F5HZ1kGOP9gF3fptpkQiNjpTeAuR3SPmDbcU6bi1e2bL+L/k29QWpmsnu/XyI34D LS2GMtW2oPV56kvKsFkMbPQgWNKgAO8x1zyUhX6SUISq/Fg3YgKi+O5UMT7cIc2W NvuBh6Azj4c/SBy3N47t7r1uDxQXWZfiR+YvzDcuDETcht6/ZfcK7blLPYrmtxWu 4I5uUOdaePr3INf3kBUj96DMYs1/H8OplxPSwA+AUD+fVDOejNtfRGX/6deoJpqi 0UkEtbW/EPB/c/U4807Vab1wV2HChDZYgo9dUc049/vBJxPxGaz7tyUSP8P3qHI3 KzE3lvEazg5pmxNx5wAeHgWmyUIsuXpow1LvGZqzLHCKIgE61oXLqbsnP0VpyDbt FnHP4cPXuXahRe37Jp37kL+xASxcOEIC32SKw2N0qwAD1JXU/EwuLY7xs+QkuyQI J296MeysUkSN2aDO7/Fsf5FjHzIwi5STsvDrzYCJ2VfWQm0+AxX+IJioGdd3/foW mUnsLxd1HWBolZDUx2Tqx6zXQJnsoRgVjo6q0amgQsaHDl9SxMuX2LKrJEAV61Mt GUYGjhvzgBOMVlmG02kH =g4FG -----END PGP SIGNATURE----- --OfrWf2Fun5Ae4m0Y-- --===============1281648124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1281648124==--