[Intel-gfx] [PATCH 19/21] drm/i915: move some leftovers to intel_pm.h from i915_drv.h
Chris Wilson
chris at chris-wilson.co.uk
Tue Apr 30 09:55:55 UTC 2019
Quoting Joonas Lahtinen (2019-04-30 08:24:07)
> Quoting Jani Nikula (2019-04-29 16:03:33)
> > On Mon, 29 Apr 2019, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > Quoting Jani Nikula (2019-04-29 13:29:37)
> > >> Commit 696173b064c6 ("drm/i915: extract intel_pm.h from intel_drv.h")
> > >> missed the declarations in i915_drv.h.
> > >
> > > Fwiw, I want to pull these along with gt powermanagement and rps into
> > > gt/intel_gt_pm.c and a few friends.
> > >
> > > Doesn't make much difference for this patch; just planned obsolescence.
> >
> > I'm fine either way, via this patch or directly.
> >
> > In general I like how it's easier to look at the new headers and wonder
> > why on earth some functions are in the files they are, and try to come
> > up with better division into files.
> >
> > ---
> >
> > I'm also trying to probe feedback on some style guidelines I might like
> > to enforce in the future:
> >
> > 1) A file and the non-static functions in it should have the same
> > prefix, i.e. intel_foo.c has functions prefixed intel_foo_*.
> >
> > 2) No file should have platform specific non-static functions, i.e. all
> > the non-static functions should be intel_foo_* and this should
> > internally split to platform_foo_* instead of leaving the if ladders
> > or function pointer initializations to the callers.
>
> Agreed on these. GEM side has been moving to this direction slowly.
>
> > So, thoughts on naming the functions intel_gt_pm_* upon moving them?
>
> Sounds reasonable to me.
And indeed the patches from last year where already making that
transformation :)
Next generation of patches are aiming to split up the different
functions under the intel_gt_pm umbrella, but still following the same
principle.
-Chris
More information about the Intel-gfx
mailing list