[PATCH 12/13] drm/irq: Expel legacy API

Daniel Vetter daniel at ffwll.ch
Tue Dec 16 10:00:54 PST 2014


On Tue, Dec 16, 2014 at 06:59:28PM +0100, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 05:53:34PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > These legacy functions all operate on the struct drm_device * and an
> > index to the CRTC that they should access. This is bad because it
> > requires keeping track of a global data structures to resolve the index
> > to CRTC object lookup. In order to get rid of this global data new APIs
> > have been introduced that operate directly on these objects. Currently
> > the new functions still operate on the old data, but the goal is to
> > eventually move that data into struct drm_crtc. In order to start
> > conversion of drivers to the new API, move the old API away.
> > 
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> 
> Imo we should try to share code between the legacy vblank code and what
> we're now building up with the drm_crtc_ prefixed functions for native kms
> drivers. Instead I think we should do full copies with the following
> recipe:
> - Look at a given function and make sure all kms drivers (and any
>   callchains used by kms drivers) uses the drm_crtc_ variant and that any
>   ums drivers uses the drm_vblank_ version. So big audit.
> - Then for each such function copy it to drm_irq_legacy.c and mark the old
>   copy in drm_irq.c as static and drop the EXPORT_SYMBOL for it.
> - Then inline the logic for native kms drivers.
> 
> Just moving the functions around doesn't really help us at all since we
> still have the problem that both ums and kms code uses them. Which means
> we can't use drm_crtc and store vblank data in there.

There's the added problem that moving breaks git blame (at least in
default mode) a bit, so better to keep the version that we want to
transform into the kms-native ones where they currently are.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list