[Intel-gfx] [PATCH v2 1/2] drm/i915/uc: Move uC related types into dedicated header

[Michal Wajdeczko]

On Fri, 29 Sep 2017 12:37:17 +0200, Joonas Lahtinen  
<joonas.lahtinen at linux.intel.com> 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 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: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>> > Cc: Sagar Arun Kamble <sagar.a.kamble at intel.com>
>> > Acked-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>
> 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