Re: [PATCH 2/2] drm/i915: Agnostic INTEL_INFO

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

 



On Mon, Aug 11, 2014 at 01:25:49PM +0200, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 11:26:07AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> > > On Sat, 09 Aug 2014, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> > > > Adapt the macro so that we can pass either the struct drm_device or the
> > > > struct drm_i915_private pointers and get the answer we want. Over time,
> > > > my plan is to convert all users over to using drm_i915_private and so
> > > > trimming down the pointer dance. Having spent a few hours chasing that
> > > > goal and achieved over 8k of object code saving, it appears to be a
> > > > worthwhile target. This interim macro allows us to slowly convert over.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > > >  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> > > > index 39988940d468..49149406fcd8 100644
> > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > @@ -1585,6 +1585,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
> > > >  	if (!drm_core_check_feature(dev, DRIVER_MODESET) && !dev->agp)
> > > >  		return -EINVAL;
> > > >  
> > > > +	/* For the ugly agnostic INTEL_INFO macro */
> > > > +	BUILD_BUG_ON(sizeof(*dev_priv) == sizeof(*dev));
> > > > +
> > > >  	dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> > > >  	if (dev_priv == NULL)
> > > >  		return -ENOMEM;
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 0aef763ffa75..e66465430bdc 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2063,7 +2063,8 @@ struct drm_i915_cmd_table {
> > > >  	int count;
> > > >  };
> > > >  
> > > > -#define INTEL_INFO(p) 	(&to_i915(p)->info)
> > > > +#define __I915__(p)	((sizeof(*(p)) == sizeof(struct drm_i915_private)) ? (struct drm_i915_private *)(p) : to_i915((struct drm_device *)p))
> > > 
> > > The explicit casts make me uncomfortable. Indeed, aren't they completely
> > > unnecessary? If the sizeof matches, p is expected to be struct
> > > drm_i915_private *, and if not, it's expected to be struct drm_device *,
> > > right?
> > 
> > Yes, killing the typesafety is bad. Sadly it is to quiesce the compiler
> > as the type-mismatch warnings are generated before it does the dead code
> > elimination removing the constant ?: expression. Too bad we couldn't
> > simply write typeof(*p) == typeof(T).
> 
> Do we need the 2nd cast for (struct drm_device *)? If we could drop that
> we'd have about as much type-safety as before, presuming no one manages to
> matche our drm_i915_private exactly in size.

The compiler is happy with that. I can't remember exactly why I added
it first time, it certainly wasn't for its looks.
-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