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@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |