On Wed, Mar 14, 2018 at 09:31:32AM -0700, Lucas De Marchi wrote:
> Reorder fields so we save 8 bytes per instance: this removes a 4-bytes
> hole after enum intel_dpll_id and a 4-bytes padding.
>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
> ---
>
> Is this something desirable? I happened to be looking at
> intel_shared_dpll and noticed the hole. I haven't checked any other struct
> yet, but there are probably more and more important ones. This one saves
> only 8 * I915_NUM_PLLS.
>
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index f24ccf443d25..9635522dcb32 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -238,11 +238,6 @@ struct intel_shared_dpll {
> */
> enum intel_dpll_id id;
>
> - /**
> - * @funcs: platform specific hooks
> - */
> - struct intel_shared_dpll_funcs funcs;
> -
> #define INTEL_DPLL_ALWAYS_ON (1 << 0)
> /**
> * @flags:
> @@ -252,6 +247,11 @@ struct intel_shared_dpll {
> * not in use by any CRTC.
> */
> uint32_t flags;
> +
> + /**
> + * @funcs: platform specific hooks
> + */
> + struct intel_shared_dpll_funcs funcs;
Why do we need to copy the entire thing here anyway? Can't we just
make this a pointer?
> };
>
> #define SKL_DPLL0 0
> --
> 2.14.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
