[Intel-gfx] [PATCH 2/5] drm/i915: Rename uint_fixed_16_16_t to fixed16_16_t

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-22 16:08:51)
> On Fri, 22 Dec 2017 13:25:53 +0100, Michal Wajdeczko  
> <michal.wajdeczko at intel.com> wrote:
> 
> > Rename uint_fixed_16_16_t to fixed16_16_t to match header name.
> > Also switch into kernel integer types.
> >
> > Suggested-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
> > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/fixed16_16.h | 91  
> > ++++++++++++++++++---------------------
> >  drivers/gpu/drm/i915/i915_drv.h   |  4 +-
> >  drivers/gpu/drm/i915/intel_pm.c   | 50 ++++++++++-----------
> >  3 files changed, 68 insertions(+), 77 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/fixed16_16.h  
> > b/drivers/gpu/drm/i915/fixed16_16.h
> > index a6568df..ec859c0 100644
> > --- a/drivers/gpu/drm/i915/fixed16_16.h
> > +++ b/drivers/gpu/drm/i915/fixed16_16.h
> > @@ -27,26 +27,26 @@
> > #include <linux/kernel.h>
> > -typedef struct {
> > -     uint32_t val;
> > -} uint_fixed_16_16_t;
> > +typedef struct fixed16_16 {
> > +     u32 val;
> > +} fixed16_16_t;
> > #define FP_16_16_MAX ({ \
> > -     uint_fixed_16_16_t fp; \
> > +     fixed16_16_t fp; \
> >       fp.val = UINT_MAX; \
> >       fp; \
> >  })
> > -static inline bool is_fixed16_zero(uint_fixed_16_16_t val)
> > +static inline bool is_fixed16_zero(fixed16_16_t val)
> >  {
> >       if (val.val == 0)
> >               return true;
> >       return false;
> >  }
> > -static inline uint_fixed_16_16_t u32_to_fixed16(uint32_t val)
> > +static inline fixed16_16_t u32_to_fixed16(u32 val)
> 
> Hmm, as we only supports unsigned values, maybe correct new name for
> the type should be prefixed with "u" ?

One of the options was u16_16, but amdgpu used fixed32_32 and
fixed31_32, so conforming to that pattern is easier than demanding they
change :) Eventually I think that header should wind up next to ours
(and perhaps we might need u24_8, u20_12 etc).
-Chris