Re: Supporting fused display configurations v4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux