On Thu, Mar 15, 2018 at 11:07:04AM -0700, Lucas De Marchi wrote:
> On Thu, Mar 15, 2018 at 11:54:19AM +0200, Ville Syrjälä wrote:
> > > We can even (or alternatively) make dpll_info part of intel_shared_dpll.
> >
> > You mean something like?
> >
> > struct intel_shared_dpll {
> > ...
> > -
On Thu, Mar 15, 2018 at 11:54:19AM +0200, Ville Syrjälä wrote:
> > We can even (or alternatively) make dpll_info part of intel_shared_dpll.
>
> You mean something like?
>
> struct intel_shared_dpll {
> ...
> - id;
> - name;
> - flags;
> + const struct dpll_info *info;
>
On Thu, Mar 15, 2018 at 08:16:32AM -0300, Jani Nikula wrote:
> On Wed, 14 Mar 2018, 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.
>
> Does GCC have anything like
On Wed, 14 Mar 2018, 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.
Does GCC have anything like the Clang -Wpadded option to warn us about
alignment holes and
On Thu, Mar 15, 2018 at 01:01:14AM -0700, Lucas De Marchi wrote:
> On Wed, Mar 14, 2018 at 07:19:18PM +0200, Ville Syrjälä wrote:
> > 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
On Wed, Mar 14, 2018 at 07:19:18PM +0200, Ville Syrjälä wrote:
> 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
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
> ---
>
> Is this something desirable? I
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
---
Is this something desirable? I happened to be looking at
intel_shared_dpll and noticed the hole. I haven't