On Fri, 29 Sep 2017 12:37:17 +0200, Joonas Lahtinen
<joonas.lahtinen@xxxxxxxxxxxxxxx> wrote:
On Wed, 2017-09-27 at 14:36 +0300, Joonas Lahtinen wrote:
On Wed, 2017-09-27 at 11:22 +0000, Michal Wajdeczko wrote:
> In old header structure we were mixing type definitions and
> declarations that prevent us from exposing some functions
> as inline. Lets try to fix that.
>
> v2: keep old order of the structs, pull fwif.h (Sagar)
>
> Suggested-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx>
> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
> Acked-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Ping, does this sound like a solid idea to you, Michal?
Idea is fine (I was the one who vote for intel_huc.c) but this
patch was to solve different problem: we can't define inline
functions in private headers if they depend on INTEL_INFO/GEN
macros as these macros requires drm_i915_private definition
that is defined later in #include chain.
But maybe you're right and we should start to clean our stuff
first and then later focus on inline implementations. @Chris?
Regards,
Michal
Regards, Joonas
Like I mentioned in the other patch, lets make future ourselves life
easier and take this cleanup further;
intel_uc.{c,h}
intel_guc.{c,h} .h includes "intel_uc.h"
intel_huc.{c,h} ditto
intel_guc_ct.h includes "intel_guc.h"
That way we're not driving ourselves towards the spaghetti insanity
that i915_drv.h is currently. Aka. move a declaration, spend hours
fixing the ordering of things.
Regards, Joonas
PS. Free beer offered for the one to first remove all "filename.c"
sections from i915_drv.h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
