On Tue, Jan 07, 2014 at 10:23:58AM +0200, Jani Nikula wrote: > On Tue, 07 Jan 2014, Paulo Zanoni <przanoni@xxxxxxxxx> wrote: > > - You removed INTEL_INFO, but all those IS_SOMETHING and HAS_SOMETHING > > macros still accept dev as argument instead of dev_priv. Do we have > > plans to change this too? I can remember many places where I had to > > add a "dev" variable just because of these macros. Perhaps maybe the > > new goal is a series removing the to_i915 macro? I could see a lot of > > code getting almost entirely rid of "dev" with these changes. > > You can get from dev to dev_priv and back easily enough. Replacing dev > with dev_priv in function parameters seems like pointless churn to > me. If (and that's a big if) we wanted to "standardize" on one or the > other, I'd go for struct drm_device *dev. The long-long-longterm plan is to subclass struct drm_device, then passing around struct drm_device or struct i915_device becomes a moot point - but imho using struct i915_device internally provides a clear separation between boundary functions and our internals. Another bit of churn that would be a win in the long term, would be to starting splitting out a struct intel_device (or whatever) to segregrate the display stuff from GEM. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
