[Intel-gfx] Supporting fused display configurations v4
Chris Wilson
chris at chris-wilson.co.uk
Tue Jan 7 11:00:25 CET 2014
On Tue, Jan 07, 2014 at 10:23:58AM +0200, Jani Nikula wrote:
> On Tue, 07 Jan 2014, Paulo Zanoni <przanoni at gmail.com> 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
More information about the Intel-gfx
mailing list