Re: linux-next: manual merge of the tip tree with the pm tree
Hi all, On Wed, 17 Feb 2021 16:07:14 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > arch/x86/platform/intel-mid/device_libs/platform_bt.c > > between commit: > > 4590d98f5a4f ("sfi: Remove framework for deprecated firmware") > > from the pm tree and commit: > > bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon") > > from the tip tree. > > I fixed it up (the former removed the file, so I did that) and can > carry the fix as necessary. This is now fixed as far as linux-next is > concerned, but any non trivial conflicts should be mentioned to your > upstream maintainer when your tree is submitted for merging. You may > also want to consider cooperating with the maintainer of the conflicting > tree to minimise any particularly complex conflicts. This is now a conflict between the pm tree and Linus' tree. -- Cheers, Stephen Rothwell pgp6xfpbQ9y0Z.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the pm tree
On Wed, Feb 17, 2021 at 7:38 AM Stephen Rothwell wrote: > > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > arch/x86/platform/intel-mid/device_libs/platform_bt.c > > between commit: > > 4590d98f5a4f ("sfi: Remove framework for deprecated firmware") > > from the pm tree and commit: > > bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon") > > from the tip tree. > > I fixed it up (the former removed the file, so I did that) and can > carry the fix as necessary. This is now fixed as far as linux-next is > concerned, but any non trivial conflicts should be mentioned to your > upstream maintainer when your tree is submitted for merging. You may > also want to consider cooperating with the maintainer of the conflicting > tree to minimise any particularly complex conflicts. Yes, the file removal is the right thing to do. Thanks! -- With Best Regards, Andy Shevchenko
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/x86/platform/intel-mid/device_libs/platform_bt.c between commit: 4590d98f5a4f ("sfi: Remove framework for deprecated firmware") from the pm tree and commit: bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon") from the tip tree. I fixed it up (the former removed the file, so I did that) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell pgppcBkiaaYcx.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the pm tree
On Mon, Oct 08, 2018 at 12:05:02PM +0200, Rafael J. Wysocki wrote: > On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote: > > > > --Sig_/8A/3tsSoWQOAryCmuI_nxw6 > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: quoted-printable > > > > Hi all, > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > drivers/idle/intel_idle.c > > > > between commit: > > > > a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro") > > > > from the pm tree and commit: > > > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > > > from the tip tree. > > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > > > --=20 > > Cheers, > > Stephen Rothwell > > > > diff --cc drivers/idle/intel_idle.c > > index 791b8a366e6e,c4bb67ed8da3.. > > --- a/drivers/idle/intel_idle.c > > +++ b/drivers/idle/intel_idle.c > > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d > > .disable_promotion_to_c1e =3D true, > > }; > > =20 > > -#define ICPU(model, cpu) \ > > - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) } > > - > > static const struct x86_cpu_id intel_idle_ids[] __initconst =3D { > > - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom), > > - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft), > > - ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb), > > - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb), > > - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom), > > - ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt), > > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier), > > - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht), > > - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb), > > - ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt), > > - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw), > > - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw), > > - ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw), > > - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw), > > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn), > > - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw), > > - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw), > > - ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw), > > - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw), > > - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl), > > - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl), > > - ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl), > > - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl), > > - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx), > > - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl), > > - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl), > > - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt), > > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt), > > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv), > > + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem), > > + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem), > > - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom), > > - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft), > > ++ INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom), > > ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft), > > + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb), > > + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb), > > - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom), > > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt), > > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier), > > ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom), > > ++
Re: linux-next: manual merge of the tip tree with the pm tree
On Mon, Oct 08, 2018 at 12:05:02PM +0200, Rafael J. Wysocki wrote: > On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote: > > > > --Sig_/8A/3tsSoWQOAryCmuI_nxw6 > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: quoted-printable > > > > Hi all, > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > drivers/idle/intel_idle.c > > > > between commit: > > > > a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro") > > > > from the pm tree and commit: > > > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > > > from the tip tree. > > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > > > --=20 > > Cheers, > > Stephen Rothwell > > > > diff --cc drivers/idle/intel_idle.c > > index 791b8a366e6e,c4bb67ed8da3.. > > --- a/drivers/idle/intel_idle.c > > +++ b/drivers/idle/intel_idle.c > > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d > > .disable_promotion_to_c1e =3D true, > > }; > > =20 > > -#define ICPU(model, cpu) \ > > - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) } > > - > > static const struct x86_cpu_id intel_idle_ids[] __initconst =3D { > > - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom), > > - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft), > > - ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem), > > - ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb), > > - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb), > > - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom), > > - ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt), > > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier), > > - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht), > > - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb), > > - ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt), > > - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw), > > - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw), > > - ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw), > > - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw), > > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn), > > - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw), > > - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw), > > - ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw), > > - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw), > > - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl), > > - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl), > > - ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl), > > - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl), > > - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx), > > - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl), > > - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl), > > - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt), > > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt), > > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv), > > + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem), > > + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem), > > - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom), > > - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft), > > ++ INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom), > > ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft), > > + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem), > > + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb), > > + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb), > > - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom), > > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt), > > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier), > > ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom), > > ++
Re: linux-next: manual merge of the tip tree with the pm tree
On Mon, Oct 8, 2018 at 1:11 PM Rafael J. Wysocki wrote: > > On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote: > > > > --Sig_/bNRy8ryxcqLmcoGqvlETGhp > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: quoted-printable > > > > Hi all, > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > drivers/powercap/intel_rapl.c > > > > between commit: > > > > 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro") > > > > from the pm tree and commit: > > > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > > > from the tip tree. > > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > > > --=20 > > Cheers, > > Stephen Rothwell > > > > diff --cc drivers/powercap/intel_rapl.c > > index bb92874b1175,8cbfcce57a06.. > > --- a/drivers/powercap/intel_rapl.c > > +++ b/drivers/powercap/intel_rapl.c > > @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_ > > .compute_time_window =3D rapl_compute_time_window_atom, > > }; > > =20 > > -#define RAPL_CPU(_model, _ops) {\ > > -.vendor =3D X86_VENDOR_INTEL, \ > > -.family =3D 6, \ > > -.model =3D _model, \ > > -.driver_data =3D (kernel_ulong_t)&_ops, \ > > -} > > - > > static const struct x86_cpu_id rapl_ids[] __initconst =3D { > > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server), > > - > > -RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server), > > - > > -RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server), > > -RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt), > > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht), > > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng), > > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann), > > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server), > > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server), > > +INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core), > > +INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core), > > + > > +INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core), > > +INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core), > > + > > +INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core), > > +INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core), > > +INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core), > > +INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server), > > + > > +INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), > > +INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core), > > +INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core), > > +INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server), > > + > > +INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), > > +INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core), > > +INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server), > > +INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core), > > +
Re: linux-next: manual merge of the tip tree with the pm tree
On Mon, Oct 8, 2018 at 1:11 PM Rafael J. Wysocki wrote: > > On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote: > > > > --Sig_/bNRy8ryxcqLmcoGqvlETGhp > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: quoted-printable > > > > Hi all, > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > drivers/powercap/intel_rapl.c > > > > between commit: > > > > 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro") > > > > from the pm tree and commit: > > > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > > > from the tip tree. > > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > > > --=20 > > Cheers, > > Stephen Rothwell > > > > diff --cc drivers/powercap/intel_rapl.c > > index bb92874b1175,8cbfcce57a06.. > > --- a/drivers/powercap/intel_rapl.c > > +++ b/drivers/powercap/intel_rapl.c > > @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_ > > .compute_time_window =3D rapl_compute_time_window_atom, > > }; > > =20 > > -#define RAPL_CPU(_model, _ops) {\ > > -.vendor =3D X86_VENDOR_INTEL, \ > > -.family =3D 6, \ > > -.model =3D _model, \ > > -.driver_data =3D (kernel_ulong_t)&_ops, \ > > -} > > - > > static const struct x86_cpu_id rapl_ids[] __initconst =3D { > > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server), > > - > > -RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server), > > - > > -RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server), > > -RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt), > > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht), > > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng), > > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann), > > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core), > > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core), > > - > > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server), > > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server), > > +INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core), > > +INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core), > > + > > +INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core), > > +INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core), > > + > > +INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core), > > +INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core), > > +INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core), > > +INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server), > > + > > +INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), > > +INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core), > > +INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core), > > +INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server), > > + > > +INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), > > +INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core), > > +INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server), > > +INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core), > > +
Re: linux-next: manual merge of the tip tree with the pm tree
On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote: > > --Sig_/bNRy8ryxcqLmcoGqvlETGhp > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/powercap/intel_rapl.c > > between commit: > > 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro") > > from the pm tree and commit: > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > --=20 > Cheers, > Stephen Rothwell > > diff --cc drivers/powercap/intel_rapl.c > index bb92874b1175,8cbfcce57a06.. > --- a/drivers/powercap/intel_rapl.c > +++ b/drivers/powercap/intel_rapl.c > @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_ > .compute_time_window =3D rapl_compute_time_window_atom, > }; > =20 > -#define RAPL_CPU(_model, _ops) {\ > -.vendor =3D X86_VENDOR_INTEL, \ > -.family =3D 6, \ > -.model =3D _model, \ > -.driver_data =3D (kernel_ulong_t)&_ops, \ > -} > - > static const struct x86_cpu_id rapl_ids[] __initconst =3D { > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server), > - > -RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server), > - > -RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server), > -RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt), > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht), > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng), > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann), > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server), > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server), > +INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core), > +INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core), > + > +INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core), > +INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core), > + > +INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core), > +INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core), > +INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core), > +INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server), > + > +INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), > +INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core), > +INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core), > +INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server), > + > +INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), > +INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core), > +INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server), > +INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core), > +INTEL_CPU_FAM6(KABYLAKE_DESKTOP,rapl_defaults_core), > +INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core), > + > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,rapl_defaults_byt), > ++INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt), >
Re: linux-next: manual merge of the tip tree with the pm tree
On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote: > > --Sig_/bNRy8ryxcqLmcoGqvlETGhp > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/powercap/intel_rapl.c > > between commit: > > 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro") > > from the pm tree and commit: > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > --=20 > Cheers, > Stephen Rothwell > > diff --cc drivers/powercap/intel_rapl.c > index bb92874b1175,8cbfcce57a06.. > --- a/drivers/powercap/intel_rapl.c > +++ b/drivers/powercap/intel_rapl.c > @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_ > .compute_time_window =3D rapl_compute_time_window_atom, > }; > =20 > -#define RAPL_CPU(_model, _ops) {\ > -.vendor =3D X86_VENDOR_INTEL, \ > -.family =3D 6, \ > -.model =3D _model, \ > -.driver_data =3D (kernel_ulong_t)&_ops, \ > -} > - > static const struct x86_cpu_id rapl_ids[] __initconst =3D { > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server), > - > -RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server), > - > -RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server), > -RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt), > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht), > -RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng), > -RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann), > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core), > -RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core), > - > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server), > -RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server), > +INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core), > +INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core), > + > +INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core), > +INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core), > + > +INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core), > +INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core), > +INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core), > +INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server), > + > +INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), > +INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core), > +INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core), > +INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server), > + > +INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), > +INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core), > +INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server), > +INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core), > +INTEL_CPU_FAM6(KABYLAKE_DESKTOP,rapl_defaults_core), > +INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core), > + > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,rapl_defaults_byt), > ++INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt), >
Re: linux-next: manual merge of the tip tree with the pm tree
On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote: > > --Sig_/8A/3tsSoWQOAryCmuI_nxw6 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/idle/intel_idle.c > > between commit: > > a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro") > > from the pm tree and commit: > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > --=20 > Cheers, > Stephen Rothwell > > diff --cc drivers/idle/intel_idle.c > index 791b8a366e6e,c4bb67ed8da3.. > --- a/drivers/idle/intel_idle.c > +++ b/drivers/idle/intel_idle.c > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d > .disable_promotion_to_c1e =3D true, > }; > =20 > -#define ICPU(model, cpu) \ > -{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) } > - > static const struct x86_cpu_id intel_idle_ids[] __initconst =3D { > -ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem), > -ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem), > -ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom), > -ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft), > -ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem), > -ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb), > -ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb), > -ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom), > -ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt), > -ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier), > -ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht), > -ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb), > -ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt), > -ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw), > -ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw), > -ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw), > -ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw), > -ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn), > -ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw), > -ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw), > -ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw), > -ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw), > -ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl), > -ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl), > -ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl), > -ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl), > -ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx), > -ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl), > -ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl), > -ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt), > -ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt), > -ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv), > +INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem), > +INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem), > +INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem), > +INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem), > +INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem), > +INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem), > - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom), > - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft), > ++INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom), > ++INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft), > +INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem), > +INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb), > +INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb), > - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom), > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt), > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier), > ++INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom), > ++INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt), > ++INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier), > +
Re: linux-next: manual merge of the tip tree with the pm tree
On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote: > > --Sig_/8A/3tsSoWQOAryCmuI_nxw6 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/idle/intel_idle.c > > between commit: > > a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro") > > from the pm tree and commit: > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > --=20 > Cheers, > Stephen Rothwell > > diff --cc drivers/idle/intel_idle.c > index 791b8a366e6e,c4bb67ed8da3.. > --- a/drivers/idle/intel_idle.c > +++ b/drivers/idle/intel_idle.c > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d > .disable_promotion_to_c1e =3D true, > }; > =20 > -#define ICPU(model, cpu) \ > -{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) } > - > static const struct x86_cpu_id intel_idle_ids[] __initconst =3D { > -ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem), > -ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem), > -ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem), > -ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom), > -ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft), > -ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem), > -ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb), > -ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb), > -ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom), > -ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt), > -ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier), > -ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht), > -ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb), > -ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt), > -ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw), > -ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw), > -ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw), > -ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw), > -ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn), > -ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw), > -ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw), > -ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw), > -ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw), > -ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl), > -ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl), > -ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl), > -ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl), > -ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx), > -ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl), > -ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl), > -ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt), > -ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt), > -ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv), > +INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem), > +INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem), > +INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem), > +INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem), > +INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem), > +INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem), > - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom), > - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft), > ++INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom), > ++INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft), > +INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem), > +INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb), > +INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb), > - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom), > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt), > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier), > ++INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom), > ++INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt), > ++INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier), > +
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/powercap/intel_rapl.c between commit: 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro") from the pm tree and commit: f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/powercap/intel_rapl.c index bb92874b1175,8cbfcce57a06.. --- a/drivers/powercap/intel_rapl.c +++ b/drivers/powercap/intel_rapl.c @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_ .compute_time_window = rapl_compute_time_window_atom, }; -#define RAPL_CPU(_model, _ops) { \ - .vendor = X86_VENDOR_INTEL, \ - .family = 6,\ - .model = _model,\ - .driver_data = (kernel_ulong_t)&_ops, \ - } - static const struct x86_cpu_id rapl_ids[] __initconst = { - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server), - - RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server), - - RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server), - RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt), - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht), - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng), - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann), - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server), - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server), + INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core), + INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core), + + INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core), + INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core), + + INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core), + INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core), + INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core), + INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server), + + INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), + INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core), + INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core), + INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server), + + INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), + INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core), + INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server), + INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core), + INTEL_CPU_FAM6(KABYLAKE_DESKTOP,rapl_defaults_core), + INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core), + - INTEL_CPU_FAM6(ATOM_SILVERMONT1,rapl_defaults_byt), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt), + INTEL_CPU_FAM6(ATOM_AIRMONT,rapl_defaults_cht), - INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng), - INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng), ++
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/powercap/intel_rapl.c between commit: 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro") from the pm tree and commit: f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/powercap/intel_rapl.c index bb92874b1175,8cbfcce57a06.. --- a/drivers/powercap/intel_rapl.c +++ b/drivers/powercap/intel_rapl.c @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_ .compute_time_window = rapl_compute_time_window_atom, }; -#define RAPL_CPU(_model, _ops) { \ - .vendor = X86_VENDOR_INTEL, \ - .family = 6,\ - .model = _model,\ - .driver_data = (kernel_ulong_t)&_ops, \ - } - static const struct x86_cpu_id rapl_ids[] __initconst = { - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server), - - RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server), - - RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server), - RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt), - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht), - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng), - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann), - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core), - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core), - - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server), - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server), + INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core), + INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core), + + INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core), + INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core), + + INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core), + INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core), + INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core), + INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server), + + INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), + INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core), + INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core), + INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server), + + INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), + INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core), + INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server), + INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core), + INTEL_CPU_FAM6(KABYLAKE_DESKTOP,rapl_defaults_core), + INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core), + - INTEL_CPU_FAM6(ATOM_SILVERMONT1,rapl_defaults_byt), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt), + INTEL_CPU_FAM6(ATOM_AIRMONT,rapl_defaults_cht), - INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng), - INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng), ++
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/idle/intel_idle.c between commit: a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro") from the pm tree and commit: f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/idle/intel_idle.c index 791b8a366e6e,c4bb67ed8da3.. --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d .disable_promotion_to_c1e = true, }; -#define ICPU(model, cpu) \ - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) } - static const struct x86_cpu_id intel_idle_ids[] __initconst = { - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem), - ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem), - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem), - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem), - ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem), - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem), - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom), - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft), - ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem), - ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb), - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb), - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom), - ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt), - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier), - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht), - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb), - ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt), - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw), - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw), - ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw), - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw), - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn), - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw), - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw), - ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw), - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw), - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl), - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl), - ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl), - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl), - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx), - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl), - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl), - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt), - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt), - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv), + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem), + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem), + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem), + INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem), + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem), + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem), - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom), - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft), ++ INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom), ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft), + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem), + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb), + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb), - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom), - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt), - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier), ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier), + INTEL_CPU_FAM6(ATOM_AIRMONT,idle_cpu_cht), + INTEL_CPU_FAM6(IVYBRIDGE, idle_cpu_ivb), + INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt), + INTEL_CPU_FAM6(HASWELL_CORE,idle_cpu_hsw), + INTEL_CPU_FAM6(HASWELL_X,
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/idle/intel_idle.c between commit: a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro") from the pm tree and commit: f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/idle/intel_idle.c index 791b8a366e6e,c4bb67ed8da3.. --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d .disable_promotion_to_c1e = true, }; -#define ICPU(model, cpu) \ - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) } - static const struct x86_cpu_id intel_idle_ids[] __initconst = { - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem), - ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem), - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem), - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem), - ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem), - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem), - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom), - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft), - ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem), - ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb), - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb), - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom), - ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt), - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier), - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht), - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb), - ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt), - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw), - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw), - ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw), - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw), - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn), - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw), - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw), - ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw), - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw), - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl), - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl), - ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl), - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl), - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx), - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl), - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl), - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt), - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt), - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv), + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem), + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem), + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem), + INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem), + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem), + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem), - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom), - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft), ++ INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom), ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft), + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem), + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb), + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb), - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom), - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt), - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier), ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt), ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier), + INTEL_CPU_FAM6(ATOM_AIRMONT,idle_cpu_cht), + INTEL_CPU_FAM6(IVYBRIDGE, idle_cpu_ivb), + INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt), + INTEL_CPU_FAM6(HASWELL_CORE,idle_cpu_hsw), + INTEL_CPU_FAM6(HASWELL_X,
Re: linux-next: manual merge of the tip tree with the pm tree
* Rafael J. Wysockiwrote: > On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote: > > > > * Stephen Rothwell wrote: > > > > > Hi all, > > > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > > > kernel/sched/cpufreq_schedutil.c > > > > > > between commit: > > > > > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") > > > > Rafael, could you please send that to the scheduler tree? > > You can apply from > > https://patchwork.kernel.org/patch/10278127/ > > and I will drop it from my tree. > > Thanks! Great - Thomas picked it up and it's now in tip:sched/core: e97a90f7069b: sched/cpufreq: Rate limits for SCHED_DEADLINE and it should hit -next on Monday. Thanks, Ingo
Re: linux-next: manual merge of the tip tree with the pm tree
* Rafael J. Wysocki wrote: > On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote: > > > > * Stephen Rothwell wrote: > > > > > Hi all, > > > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > > > kernel/sched/cpufreq_schedutil.c > > > > > > between commit: > > > > > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") > > > > Rafael, could you please send that to the scheduler tree? > > You can apply from > > https://patchwork.kernel.org/patch/10278127/ > > and I will drop it from my tree. > > Thanks! Great - Thomas picked it up and it's now in tip:sched/core: e97a90f7069b: sched/cpufreq: Rate limits for SCHED_DEADLINE and it should hit -next on Monday. Thanks, Ingo
Re: linux-next: manual merge of the tip tree with the pm tree
On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote: > > * Stephen Rothwellwrote: > > > Hi all, > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > kernel/sched/cpufreq_schedutil.c > > > > between commit: > > > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") > > Rafael, could you please send that to the scheduler tree? You can apply from https://patchwork.kernel.org/patch/10278127/ and I will drop it from my tree. Thanks!
Re: linux-next: manual merge of the tip tree with the pm tree
On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote: > > * Stephen Rothwell wrote: > > > Hi all, > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > kernel/sched/cpufreq_schedutil.c > > > > between commit: > > > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") > > Rafael, could you please send that to the scheduler tree? You can apply from https://patchwork.kernel.org/patch/10278127/ and I will drop it from my tree. Thanks!
Re: linux-next: manual merge of the tip tree with the pm tree
* Stephen Rothwellwrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > kernel/sched/cpufreq_schedutil.c > > between commit: > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") Rafael, could you please send that to the scheduler tree? Thanks, Ingo
Re: linux-next: manual merge of the tip tree with the pm tree
* Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > kernel/sched/cpufreq_schedutil.c > > between commit: > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") Rafael, could you please send that to the scheduler tree? Thanks, Ingo
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/sched/cpufreq_schedutil.c between commit: 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") from the pm tree and commit: 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc kernel/sched/cpufreq_schedutil.c index 04d3fe9ba7d2,89fe78ecb88c.. --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@@ -280,11 -276,9 +286,11 @@@ static void sugov_update_single(struct unsigned int next_f; bool busy; - sugov_set_iowait_boost(sg_cpu, time); + sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; + ignore_dl_rate_limit(sg_cpu, sg_policy); + if (!sugov_should_update_freq(sg_policy, time)) return; @@@ -366,12 -353,7 +365,9 @@@ sugov_update_shared(struct update_util_ raw_spin_lock(_policy->update_lock); + ignore_dl_rate_limit(sg_cpu, sg_policy); + - sugov_get_util(sg_cpu); - sg_cpu->flags = flags; - - sugov_set_iowait_boost(sg_cpu, time); + sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; if (sugov_should_update_freq(sg_policy, time)) { pgpZIg2uKjFPY.pgp Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/sched/cpufreq_schedutil.c between commit: 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE") from the pm tree and commit: 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc kernel/sched/cpufreq_schedutil.c index 04d3fe9ba7d2,89fe78ecb88c.. --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@@ -280,11 -276,9 +286,11 @@@ static void sugov_update_single(struct unsigned int next_f; bool busy; - sugov_set_iowait_boost(sg_cpu, time); + sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; + ignore_dl_rate_limit(sg_cpu, sg_policy); + if (!sugov_should_update_freq(sg_policy, time)) return; @@@ -366,12 -353,7 +365,9 @@@ sugov_update_shared(struct update_util_ raw_spin_lock(_policy->update_lock); + ignore_dl_rate_limit(sg_cpu, sg_policy); + - sugov_get_util(sg_cpu); - sg_cpu->flags = flags; - - sugov_set_iowait_boost(sg_cpu, time); + sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; if (sugov_should_update_freq(sg_policy, time)) { pgpZIg2uKjFPY.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the pm tree
On Monday, November 6, 2017 3:10:40 AM CET Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/idle/intel_idle.c > > between commit: > > 0563bb7ba67e ("intel_idle: replace conditionals with > static_cpu_has(X86_FEATURE_ARAT)") > > from the pm tree and commit: > > 675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. The fix looks good to me, thanks!
Re: linux-next: manual merge of the tip tree with the pm tree
On Monday, November 6, 2017 3:10:40 AM CET Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/idle/intel_idle.c > > between commit: > > 0563bb7ba67e ("intel_idle: replace conditionals with > static_cpu_has(X86_FEATURE_ARAT)") > > from the pm tree and commit: > > 675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. The fix looks good to me, thanks!
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/idle/intel_idle.c between commit: 0563bb7ba67e ("intel_idle: replace conditionals with static_cpu_has(X86_FEATURE_ARAT)") from the pm tree and commit: 675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/idle/intel_idle.c index 5db5e3176f6a,f0b06b14e782.. --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@@ -913,24 -913,19 +913,25 @@@ static __cpuidle int intel_idle(struct struct cpuidle_state *state = >states[index]; unsigned long eax = flg2MWAIT(state->flags); unsigned int cstate; + bool uninitialized_var(tick); + int cpu = smp_processor_id(); - cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1; - /* -* NB: if CPUIDLE_FLAG_TLB_FLUSHED is set, this idle transition -* will probably flush the TLB. It's not guaranteed to flush -* the TLB, though, so it's not clear that we can do anything -* useful with this knowledge. +* leave_mm() to avoid costly and often unnecessary wakeups +* for flushing the user TLB's associated with the active mm. */ + if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED) + leave_mm(cpu); - if (!(lapic_timer_reliable_states & (1 << (cstate - tick_broadcast_enter(); + if (!static_cpu_has(X86_FEATURE_ARAT)) { + cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & + MWAIT_CSTATE_MASK) + 1; + tick = false; + if (!(lapic_timer_reliable_states & (1 << (cstate { + tick = true; + tick_broadcast_enter(); + } + } mwait_idle_with_hints(eax, ecx);
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/idle/intel_idle.c between commit: 0563bb7ba67e ("intel_idle: replace conditionals with static_cpu_has(X86_FEATURE_ARAT)") from the pm tree and commit: 675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/idle/intel_idle.c index 5db5e3176f6a,f0b06b14e782.. --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@@ -913,24 -913,19 +913,25 @@@ static __cpuidle int intel_idle(struct struct cpuidle_state *state = >states[index]; unsigned long eax = flg2MWAIT(state->flags); unsigned int cstate; + bool uninitialized_var(tick); + int cpu = smp_processor_id(); - cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1; - /* -* NB: if CPUIDLE_FLAG_TLB_FLUSHED is set, this idle transition -* will probably flush the TLB. It's not guaranteed to flush -* the TLB, though, so it's not clear that we can do anything -* useful with this knowledge. +* leave_mm() to avoid costly and often unnecessary wakeups +* for flushing the user TLB's associated with the active mm. */ + if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED) + leave_mm(cpu); - if (!(lapic_timer_reliable_states & (1 << (cstate - tick_broadcast_enter(); + if (!static_cpu_has(X86_FEATURE_ARAT)) { + cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & + MWAIT_CSTATE_MASK) + 1; + tick = false; + if (!(lapic_timer_reliable_states & (1 << (cstate { + tick = true; + tick_broadcast_enter(); + } + } mwait_idle_with_hints(eax, ecx);
Re: linux-next: manual merge of the tip tree with the pm tree
Hi all, On Fri, 11 Aug 2017 14:06:46 +1000 Stephen Rothwellwrote: > > Today's linux-next merge of the tip tree got a conflict in: > > kernel/sched/fair.c > > between commit: > > 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks") > > from the pm tree and commit: > > a030d7381d8b ("sched/fair: Call cpufreq update util handlers less > frequently on UP") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > -- > Cheers, > Stephen Rothwell > > diff --cc kernel/sched/fair.c > index d378d02fdfcb,8d5868771cb3.. > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st > } > #endif /* CONFIG_FAIR_GROUP_SCHED */ > > + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) > + { > -if (_rq()->cfs == cfs_rq) { > ++struct rq *rq = rq_of(cfs_rq); > ++ > ++if (>cfs == cfs_rq) { > + /* > + * There are a few boundary cases this might miss but it should > + * get called often enough that that should (hopefully) not be > + * a real problem -- added to that it only calls on the local > + * CPU, so if we enqueue remotely we'll miss an update, but > + * the next tick/schedule should update. > + * > + * It will not get called when we go idle, because the idle > + * thread is a different class (!fair), nor will the utilization > + * number include things like RT tasks. > + * > + * As is, the util number is not freq-invariant (we'd have to > + * implement arch_scale_freq_capacity() for that). > + * > + * See cpu_util(). > + */ > -cpufreq_update_util(rq_of(cfs_rq), 0); > ++cpufreq_update_util(rq, 0); > + } > + } > + > #ifdef CONFIG_SMP > /* >* Approximate: Just a reminder that the above conflict still exists. -- Cheers, Stephen Rothwell
Re: linux-next: manual merge of the tip tree with the pm tree
Hi all, On Fri, 11 Aug 2017 14:06:46 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > kernel/sched/fair.c > > between commit: > > 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks") > > from the pm tree and commit: > > a030d7381d8b ("sched/fair: Call cpufreq update util handlers less > frequently on UP") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > -- > Cheers, > Stephen Rothwell > > diff --cc kernel/sched/fair.c > index d378d02fdfcb,8d5868771cb3.. > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st > } > #endif /* CONFIG_FAIR_GROUP_SCHED */ > > + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) > + { > -if (_rq()->cfs == cfs_rq) { > ++struct rq *rq = rq_of(cfs_rq); > ++ > ++if (>cfs == cfs_rq) { > + /* > + * There are a few boundary cases this might miss but it should > + * get called often enough that that should (hopefully) not be > + * a real problem -- added to that it only calls on the local > + * CPU, so if we enqueue remotely we'll miss an update, but > + * the next tick/schedule should update. > + * > + * It will not get called when we go idle, because the idle > + * thread is a different class (!fair), nor will the utilization > + * number include things like RT tasks. > + * > + * As is, the util number is not freq-invariant (we'd have to > + * implement arch_scale_freq_capacity() for that). > + * > + * See cpu_util(). > + */ > -cpufreq_update_util(rq_of(cfs_rq), 0); > ++cpufreq_update_util(rq, 0); > + } > + } > + > #ifdef CONFIG_SMP > /* >* Approximate: Just a reminder that the above conflict still exists. -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/sched/fair.c between commit: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks") from the pm tree and commit: a030d7381d8b ("sched/fair: Call cpufreq update util handlers less frequently on UP") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc kernel/sched/fair.c index d378d02fdfcb,8d5868771cb3.. --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st } #endif /* CONFIG_FAIR_GROUP_SCHED */ + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) + { - if (_rq()->cfs == cfs_rq) { ++ struct rq *rq = rq_of(cfs_rq); ++ ++ if (>cfs == cfs_rq) { + /* +* There are a few boundary cases this might miss but it should +* get called often enough that that should (hopefully) not be +* a real problem -- added to that it only calls on the local +* CPU, so if we enqueue remotely we'll miss an update, but +* the next tick/schedule should update. +* +* It will not get called when we go idle, because the idle +* thread is a different class (!fair), nor will the utilization +* number include things like RT tasks. +* +* As is, the util number is not freq-invariant (we'd have to +* implement arch_scale_freq_capacity() for that). +* +* See cpu_util(). +*/ - cpufreq_update_util(rq_of(cfs_rq), 0); ++ cpufreq_update_util(rq, 0); + } + } + #ifdef CONFIG_SMP /* * Approximate:
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/sched/fair.c between commit: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks") from the pm tree and commit: a030d7381d8b ("sched/fair: Call cpufreq update util handlers less frequently on UP") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc kernel/sched/fair.c index d378d02fdfcb,8d5868771cb3.. --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st } #endif /* CONFIG_FAIR_GROUP_SCHED */ + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) + { - if (_rq()->cfs == cfs_rq) { ++ struct rq *rq = rq_of(cfs_rq); ++ ++ if (>cfs == cfs_rq) { + /* +* There are a few boundary cases this might miss but it should +* get called often enough that that should (hopefully) not be +* a real problem -- added to that it only calls on the local +* CPU, so if we enqueue remotely we'll miss an update, but +* the next tick/schedule should update. +* +* It will not get called when we go idle, because the idle +* thread is a different class (!fair), nor will the utilization +* number include things like RT tasks. +* +* As is, the util number is not freq-invariant (we'd have to +* implement arch_scale_freq_capacity() for that). +* +* See cpu_util(). +*/ - cpufreq_update_util(rq_of(cfs_rq), 0); ++ cpufreq_update_util(rq, 0); + } + } + #ifdef CONFIG_SMP /* * Approximate:
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/idle/Kconfig drivers/idle/i7300_idle.c between commits: f2f31bb3f50b ("idle / i7300: Add CONFIG_PCI dependency") ccd29e2ed6bc ("i7300_idle: avoid theoretical uninitialized data usage") 881ef1847b2d ("i7300_idle: fix typo in parameter description") from the pm tree and commit: b65ce83f2a60 ("i7300_idle: Remove this driver") from the tip tree. I fixed it up (I just used the latter version) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/idle/Kconfig drivers/idle/i7300_idle.c between commits: f2f31bb3f50b ("idle / i7300: Add CONFIG_PCI dependency") ccd29e2ed6bc ("i7300_idle: avoid theoretical uninitialized data usage") 881ef1847b2d ("i7300_idle: fix typo in parameter description") from the pm tree and commit: b65ce83f2a60 ("i7300_idle: Remove this driver") from the tip tree. I fixed it up (I just used the latter version) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/powercap/intel_rapl.c between commit: 9b1d0794b70d ("powercap / RAPL: add support for Skylake-X") from the pm tree and commit: 62d167330679 ("x86, powercap, rapl: Use Intel model macros intead of open-coding") 0bb04b5f2c24 ("x86, powercap, rapl: Reorder CPU detection table") d40671e30cb4 ("x86, powercap, rapl: Add Skylake Server model number") from the tip tree. I fixed it up (I think that last tip tree commit does the same as the pm tree one, so I used that) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/powercap/intel_rapl.c between commit: 9b1d0794b70d ("powercap / RAPL: add support for Skylake-X") from the pm tree and commit: 62d167330679 ("x86, powercap, rapl: Use Intel model macros intead of open-coding") 0bb04b5f2c24 ("x86, powercap, rapl: Reorder CPU detection table") d40671e30cb4 ("x86, powercap, rapl: Add Skylake Server model number") from the tip tree. I fixed it up (I think that last tip tree commit does the same as the pm tree one, so I used that) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/cpufreq/longhaul.c between commit: b49c22a6ca36 ("cpufreq: Convert printk(KERN_ to pr_") from the pm tree and commit: 93984fbd4e33 ("x86/cpufeature: Replace cpu_has_apic with boot_cpu_has() usage") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/cpufreq/longhaul.c index beae5cf5c62c,247bfa8eaddb.. --- a/drivers/cpufreq/longhaul.c +++ b/drivers/cpufreq/longhaul.c @@@ -932,8 -945,9 +932,8 @@@ static int __init longhaul_init(void } #endif #ifdef CONFIG_X86_IO_APIC - if (cpu_has_apic) { + if (boot_cpu_has(X86_FEATURE_APIC)) { - printk(KERN_ERR PFX "APIC detected. Longhaul is currently " - "broken in this configuration.\n"); + pr_err("APIC detected. Longhaul is currently broken in this configuration.\n"); return -ENODEV; } #endif
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/cpufreq/longhaul.c between commit: b49c22a6ca36 ("cpufreq: Convert printk(KERN_ to pr_") from the pm tree and commit: 93984fbd4e33 ("x86/cpufeature: Replace cpu_has_apic with boot_cpu_has() usage") from the tip tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/cpufreq/longhaul.c index beae5cf5c62c,247bfa8eaddb.. --- a/drivers/cpufreq/longhaul.c +++ b/drivers/cpufreq/longhaul.c @@@ -932,8 -945,9 +932,8 @@@ static int __init longhaul_init(void } #endif #ifdef CONFIG_X86_IO_APIC - if (cpu_has_apic) { + if (boot_cpu_has(X86_FEATURE_APIC)) { - printk(KERN_ERR PFX "APIC detected. Longhaul is currently " - "broken in this configuration.\n"); + pr_err("APIC detected. Longhaul is currently broken in this configuration.\n"); return -ENODEV; } #endif
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: tools/power/x86/turbostat/turbostat.c between commit: 58cc30a4e608 ("tools/power turbostat: fix compiler warnings") from the pm tree and commit: 1b69317d2dc8 ("tools/power turbostat: fix various build warnings") from the tip tree. I fixed it up (I arbitrarily used the pm tree version) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: tools/power/x86/turbostat/turbostat.c between commit: 58cc30a4e608 ("tools/power turbostat: fix compiler warnings") from the pm tree and commit: 1b69317d2dc8 ("tools/power turbostat: fix various build warnings") from the tip tree. I fixed it up (I arbitrarily used the pm tree version) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell
Re: linux-next: manual merge of the tip tree with the pm tree
On Friday, March 11, 2016 12:57:46 PM Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > kernel/sched/sched.h > > between commit: > > adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory") > > from the pm tree and commit: > > e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary (no action > is required). Looks good to me, thanks! Rafael
Re: linux-next: manual merge of the tip tree with the pm tree
On Friday, March 11, 2016 12:57:46 PM Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > kernel/sched/sched.h > > between commit: > > adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory") > > from the pm tree and commit: > > e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") > > from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary (no action > is required). Looks good to me, thanks! Rafael
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/sched/sched.h between commit: adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory") from the pm tree and commit: e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell diff --cc kernel/sched/sched.h index faf7e2758dd0,e6d4a3fa3660.. --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@@ -1739,50 -1794,15 +1794,63 @@@ static inline u64 irq_time_read(int cpu #endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ +#ifdef CONFIG_CPU_FREQ +DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data); + +/** + * cpufreq_update_util - Take a note about CPU utilization changes. + * @time: Current time. + * @util: Current utilization. + * @max: Utilization ceiling. + * + * This function is called by the scheduler on every invocation of + * update_load_avg() on the CPU whose utilization is being updated. + * + * It can only be called from RCU-sched read-side critical sections. + */ +static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) +{ + struct update_util_data *data; + + data = rcu_dereference_sched(*this_cpu_ptr(_update_util_data)); + if (data) + data->func(data, time, util, max); +} + +/** + * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed. + * @time: Current time. + * + * The way cpufreq is currently arranged requires it to evaluate the CPU + * performance state (frequency/voltage) on a regular basis to prevent it from + * being stuck in a completely inadequate performance level for too long. + * That is not guaranteed to happen if the updates are only triggered from CFS, + * though, because they may not be coming in if RT or deadline tasks are active + * all the time (or there are RT and DL tasks only). + * + * As a workaround for that issue, this function is called by the RT and DL + * sched classes to trigger extra cpufreq updates to prevent it from stalling, + * but that really is a band-aid. Going forward it should be replaced with + * solutions targeted more specifically at RT and DL tasks. + */ +static inline void cpufreq_trigger_update(u64 time) +{ + cpufreq_update_util(time, ULONG_MAX, 0); +} +#else +static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) {} +static inline void cpufreq_trigger_update(u64 time) {} +#endif /* CONFIG_CPU_FREQ */ ++ + static inline void account_reset_rq(struct rq *rq) + { + #ifdef CONFIG_IRQ_TIME_ACCOUNTING + rq->prev_irq_time = 0; + #endif + #ifdef CONFIG_PARAVIRT + rq->prev_steal_time = 0; + #endif + #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING + rq->prev_steal_time_rq = 0; + #endif + }
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/sched/sched.h between commit: adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory") from the pm tree and commit: e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell diff --cc kernel/sched/sched.h index faf7e2758dd0,e6d4a3fa3660.. --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@@ -1739,50 -1794,15 +1794,63 @@@ static inline u64 irq_time_read(int cpu #endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ +#ifdef CONFIG_CPU_FREQ +DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data); + +/** + * cpufreq_update_util - Take a note about CPU utilization changes. + * @time: Current time. + * @util: Current utilization. + * @max: Utilization ceiling. + * + * This function is called by the scheduler on every invocation of + * update_load_avg() on the CPU whose utilization is being updated. + * + * It can only be called from RCU-sched read-side critical sections. + */ +static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) +{ + struct update_util_data *data; + + data = rcu_dereference_sched(*this_cpu_ptr(_update_util_data)); + if (data) + data->func(data, time, util, max); +} + +/** + * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed. + * @time: Current time. + * + * The way cpufreq is currently arranged requires it to evaluate the CPU + * performance state (frequency/voltage) on a regular basis to prevent it from + * being stuck in a completely inadequate performance level for too long. + * That is not guaranteed to happen if the updates are only triggered from CFS, + * though, because they may not be coming in if RT or deadline tasks are active + * all the time (or there are RT and DL tasks only). + * + * As a workaround for that issue, this function is called by the RT and DL + * sched classes to trigger extra cpufreq updates to prevent it from stalling, + * but that really is a band-aid. Going forward it should be replaced with + * solutions targeted more specifically at RT and DL tasks. + */ +static inline void cpufreq_trigger_update(u64 time) +{ + cpufreq_update_util(time, ULONG_MAX, 0); +} +#else +static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) {} +static inline void cpufreq_trigger_update(u64 time) {} +#endif /* CONFIG_CPU_FREQ */ ++ + static inline void account_reset_rq(struct rq *rq) + { + #ifdef CONFIG_IRQ_TIME_ACCOUNTING + rq->prev_irq_time = 0; + #endif + #ifdef CONFIG_PARAVIRT + rq->prev_steal_time = 0; + #endif + #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING + rq->prev_steal_time_rq = 0; + #endif + }
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/cpufreq/intel_pstate.c between commit: 7791e4aa59ad ("cpufreq: intel_pstate: Enable HWP by default") from the pm tree and commit: bc696ca05f5a ("x86/cpufeature: Replace the old static_cpu_has() with safe variant") from the tip tree. I fixed it up (the former removed the code modified by the latter) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/cpufreq/intel_pstate.c between commit: 7791e4aa59ad ("cpufreq: intel_pstate: Enable HWP by default") from the pm tree and commit: bc696ca05f5a ("x86/cpufeature: Replace the old static_cpu_has() with safe variant") from the tip tree. I fixed it up (the former removed the code modified by the latter) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/arm64/kernel/acpi.c between commit: f26527b1428f ("irqchip / GIC: Convert the GIC driver to ACPI probing") from the pm tree and commit: 89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm64/kernel/acpi.c index d6463bba2360,137d537ddceb.. --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@@ -205,3 -210,52 +210,27 @@@ void __init acpi_boot_table_init(void disable_acpi(); } } + -void __init acpi_gic_init(void) -{ - struct acpi_table_header *table; - acpi_status status; - acpi_size tbl_size; - int err; - - if (acpi_disabled) - return; - - status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, , _size); - if (ACPI_FAILURE(status)) { - const char *msg = acpi_format_exception(status); - - pr_err("Failed to get MADT table, %s\n", msg); - return; - } - - err = gic_v2_acpi_init(table); - if (err) - pr_err("Failed to initialize GIC IRQ controller"); - - early_acpi_os_unmap_memory((char *)table, tbl_size); -} - + #ifdef CONFIG_ACPI_APEI + pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) + { + /* +* According to "Table 8 Map: EFI memory types to AArch64 memory +* types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is +* mapped to a corresponding MAIR attribute encoding. +* The EFI memory attribute advises all possible capabilities +* of a memory region. We use the most efficient capability. +*/ + + u64 attr; + + attr = efi_mem_attributes(addr); + if (attr & EFI_MEMORY_WB) + return PAGE_KERNEL; + if (attr & EFI_MEMORY_WT) + return __pgprot(PROT_NORMAL_WT); + if (attr & EFI_MEMORY_WC) + return __pgprot(PROT_NORMAL_NC); + return __pgprot(PROT_DEVICE_nGnRnE); + } + #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/arm64/kernel/acpi.c between commit: f26527b1428f ("irqchip / GIC: Convert the GIC driver to ACPI probing") from the pm tree and commit: 89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm64/kernel/acpi.c index d6463bba2360,137d537ddceb.. --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@@ -205,3 -210,52 +210,27 @@@ void __init acpi_boot_table_init(void disable_acpi(); } } + -void __init acpi_gic_init(void) -{ - struct acpi_table_header *table; - acpi_status status; - acpi_size tbl_size; - int err; - - if (acpi_disabled) - return; - - status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, , _size); - if (ACPI_FAILURE(status)) { - const char *msg = acpi_format_exception(status); - - pr_err("Failed to get MADT table, %s\n", msg); - return; - } - - err = gic_v2_acpi_init(table); - if (err) - pr_err("Failed to initialize GIC IRQ controller"); - - early_acpi_os_unmap_memory((char *)table, tbl_size); -} - + #ifdef CONFIG_ACPI_APEI + pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) + { + /* +* According to "Table 8 Map: EFI memory types to AArch64 memory +* types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is +* mapped to a corresponding MAIR attribute encoding. +* The EFI memory attribute advises all possible capabilities +* of a memory region. We use the most efficient capability. +*/ + + u64 attr; + + attr = efi_mem_attributes(addr); + if (attr & EFI_MEMORY_WB) + return PAGE_KERNEL; + if (attr & EFI_MEMORY_WT) + return __pgprot(PROT_NORMAL_WT); + if (attr & EFI_MEMORY_WC) + return __pgprot(PROT_NORMAL_NC); + return __pgprot(PROT_DEVICE_nGnRnE); + } + #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with the pm tree
On Tuesday, March 31, 2015 06:58:44 PM Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got conflicts in > include/linux/clockchips.h, kernel/time/tick-broadcast.c, > kernel/time/tick-common.c and kernel/time/tick-internal.h between > commit 01b9fdf7e540 ("tick: Move core only declarations and functions > to core") (and others) from the pm tree and commit 77e32c89a711 > ("clockevents: Manage device's state separately for the core") (and > others) from the tip tree. > > I fixed it up (I *think* I may have figured it all out, but please > check - see below and teh final tree later) and can carry the fix as > necessary (no action is required). The resolution looks good from the PM tree perspective, thanks! Rafael signature.asc Description: This is a digitally signed message part.
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got conflicts in include/linux/clockchips.h, kernel/time/tick-broadcast.c, kernel/time/tick-common.c and kernel/time/tick-internal.h between commit 01b9fdf7e540 ("tick: Move core only declarations and functions to core") (and others) from the pm tree and commit 77e32c89a711 ("clockevents: Manage device's state separately for the core") (and others) from the tip tree. I fixed it up (I *think* I may have figured it all out, but please check - see below and teh final tree later) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc include/linux/clockchips.h index 4350d7101982,e20232c3320a.. --- a/include/linux/clockchips.h +++ b/include/linux/clockchips.h diff --cc kernel/time/tick-broadcast.c index f8e27cd0b7ab,f0f8ee9dbc28.. --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@@ -553,9 -541,10 +553,9 @@@ static int tick_broadcast_set_event(str return ret; } -int tick_resume_broadcast_oneshot(struct clock_event_device *bc) +static void tick_resume_broadcast_oneshot(struct clock_event_device *bc) { - clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT); + clockevents_set_state(bc, CLOCK_EVT_STATE_ONESHOT); - return 0; } /* diff --cc kernel/time/tick-common.c index d9e769e31ee4,a5b877130ae9.. --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@@ -386,19 -380,13 +387,20 @@@ void tick_suspend_local(void clockevents_shutdown(td->evtdev); } -void tick_resume(void) +/** + * tick_resume_local - Resume the local tick device + * + * Called from the local CPU for unfreeze or XEN resume magic. + * + * No locks required. Nothing can change the per cpu device. + */ +void tick_resume_local(void) { struct tick_device *td = this_cpu_ptr(_cpu_device); - int broadcast = tick_resume_broadcast(); + bool broadcast = tick_resume_check_broadcast(); - clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_RESUME); + clockevents_tick_resume(td->evtdev); + if (!broadcast) { if (td->mode == TICKDEV_MODE_PERIODIC) tick_setup_periodic(td->evtdev, 0); diff --cc kernel/time/tick-internal.h index 1c7560a533d5,98700e4a2000.. --- a/kernel/time/tick-internal.h +++ b/kernel/time/tick-internal.h @@@ -27,31 -30,15 +27,32 @@@ extern void tick_resume(void) extern bool tick_check_replacement(struct clock_event_device *curdev, struct clock_event_device *newdev); extern void tick_install_replacement(struct clock_event_device *dev); +extern int tick_is_oneshot_available(void); +extern struct tick_device *tick_get_device(int cpu); + +/* Check, if the device is functional or a dummy for broadcast */ +static inline int tick_device_is_functional(struct clock_event_device *dev) +{ + return !(dev->features & CLOCK_EVT_FEAT_DUMMY); +} extern void clockevents_shutdown(struct clock_event_device *dev); + extern int clockevents_tick_resume(struct clock_event_device *dev); - +extern void clockevents_exchange_device(struct clock_event_device *old, + struct clock_event_device *new); - extern void clockevents_set_mode(struct clock_event_device *dev, -enum clock_event_mode mode); ++extern void clockevents_set_state(struct clock_event_device *dev, ++enum clock_event_state state); +extern int clockevents_program_event(struct clock_event_device *dev, + ktime_t expires, bool force); +extern void clockevents_handle_noop(struct clock_event_device *dev); +extern int __clockevents_update_freq(struct clock_event_device *dev, u32 freq); extern ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt); +#else +static inline void tick_suspend(void) { } +static inline void tick_resume(void) { } +#endif /* GENERIC_CLOCKEVENTS */ -/* - * NO_HZ / high resolution timer shared code - */ +/* Oneshot related functions */ #ifdef CONFIG_TICK_ONESHOT extern void tick_setup_oneshot(struct clock_event_device *newdev, void (*handler)(struct clock_event_device *), pgpPM1QN1kuJp.pgp Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/arm/common/bL_switcher.c between commit bf03f36d239f ("arm: bl_switcher: Kill tick suspend hackery") from the pm tree and commit 77e32c89a711 ("clockevents: Manage device's state separately for the core") from the tip tree. I fixed it up (the former removed all the code changed by the latter) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpgMkcehwAVv.pgp Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/arm/common/bL_switcher.c between commit bf03f36d239f (arm: bl_switcher: Kill tick suspend hackery) from the pm tree and commit 77e32c89a711 (clockevents: Manage device's state separately for the core) from the tip tree. I fixed it up (the former removed all the code changed by the latter) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpgMkcehwAVv.pgp Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got conflicts in include/linux/clockchips.h, kernel/time/tick-broadcast.c, kernel/time/tick-common.c and kernel/time/tick-internal.h between commit 01b9fdf7e540 (tick: Move core only declarations and functions to core) (and others) from the pm tree and commit 77e32c89a711 (clockevents: Manage device's state separately for the core) (and others) from the tip tree. I fixed it up (I *think* I may have figured it all out, but please check - see below and teh final tree later) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc include/linux/clockchips.h index 4350d7101982,e20232c3320a.. --- a/include/linux/clockchips.h +++ b/include/linux/clockchips.h diff --cc kernel/time/tick-broadcast.c index f8e27cd0b7ab,f0f8ee9dbc28.. --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@@ -553,9 -541,10 +553,9 @@@ static int tick_broadcast_set_event(str return ret; } -int tick_resume_broadcast_oneshot(struct clock_event_device *bc) +static void tick_resume_broadcast_oneshot(struct clock_event_device *bc) { - clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT); + clockevents_set_state(bc, CLOCK_EVT_STATE_ONESHOT); - return 0; } /* diff --cc kernel/time/tick-common.c index d9e769e31ee4,a5b877130ae9.. --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@@ -386,19 -380,13 +387,20 @@@ void tick_suspend_local(void clockevents_shutdown(td-evtdev); } -void tick_resume(void) +/** + * tick_resume_local - Resume the local tick device + * + * Called from the local CPU for unfreeze or XEN resume magic. + * + * No locks required. Nothing can change the per cpu device. + */ +void tick_resume_local(void) { struct tick_device *td = this_cpu_ptr(tick_cpu_device); - int broadcast = tick_resume_broadcast(); + bool broadcast = tick_resume_check_broadcast(); - clockevents_set_mode(td-evtdev, CLOCK_EVT_MODE_RESUME); + clockevents_tick_resume(td-evtdev); + if (!broadcast) { if (td-mode == TICKDEV_MODE_PERIODIC) tick_setup_periodic(td-evtdev, 0); diff --cc kernel/time/tick-internal.h index 1c7560a533d5,98700e4a2000.. --- a/kernel/time/tick-internal.h +++ b/kernel/time/tick-internal.h @@@ -27,31 -30,15 +27,32 @@@ extern void tick_resume(void) extern bool tick_check_replacement(struct clock_event_device *curdev, struct clock_event_device *newdev); extern void tick_install_replacement(struct clock_event_device *dev); +extern int tick_is_oneshot_available(void); +extern struct tick_device *tick_get_device(int cpu); + +/* Check, if the device is functional or a dummy for broadcast */ +static inline int tick_device_is_functional(struct clock_event_device *dev) +{ + return !(dev-features CLOCK_EVT_FEAT_DUMMY); +} extern void clockevents_shutdown(struct clock_event_device *dev); + extern int clockevents_tick_resume(struct clock_event_device *dev); - +extern void clockevents_exchange_device(struct clock_event_device *old, + struct clock_event_device *new); - extern void clockevents_set_mode(struct clock_event_device *dev, -enum clock_event_mode mode); ++extern void clockevents_set_state(struct clock_event_device *dev, ++enum clock_event_state state); +extern int clockevents_program_event(struct clock_event_device *dev, + ktime_t expires, bool force); +extern void clockevents_handle_noop(struct clock_event_device *dev); +extern int __clockevents_update_freq(struct clock_event_device *dev, u32 freq); extern ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt); +#else +static inline void tick_suspend(void) { } +static inline void tick_resume(void) { } +#endif /* GENERIC_CLOCKEVENTS */ -/* - * NO_HZ / high resolution timer shared code - */ +/* Oneshot related functions */ #ifdef CONFIG_TICK_ONESHOT extern void tick_setup_oneshot(struct clock_event_device *newdev, void (*handler)(struct clock_event_device *), pgpPM1QN1kuJp.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the pm tree
On Tuesday, March 31, 2015 06:58:44 PM Stephen Rothwell wrote: Hi all, Today's linux-next merge of the tip tree got conflicts in include/linux/clockchips.h, kernel/time/tick-broadcast.c, kernel/time/tick-common.c and kernel/time/tick-internal.h between commit 01b9fdf7e540 (tick: Move core only declarations and functions to core) (and others) from the pm tree and commit 77e32c89a711 (clockevents: Manage device's state separately for the core) (and others) from the tip tree. I fixed it up (I *think* I may have figured it all out, but please check - see below and teh final tree later) and can carry the fix as necessary (no action is required). The resolution looks good from the PM tree perspective, thanks! Rafael signature.asc Description: This is a digitally signed message part.
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/x86/kernel/apic/io_apic.c between commit 16394fd03114 ("x86 / PM: Replace CONFIG_PM_RUNTIME in io_apic.c") from the pm tree and various commits from the tip tree. I fixed it up (the tip tree seems to have made extensive changes to this file and there are no longer any references to CONFIG_PM_RUNTIME, so I used the tip tree version) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpf2yS2rfLBb.pgp Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/x86/kernel/apic/io_apic.c between commit 16394fd03114 (x86 / PM: Replace CONFIG_PM_RUNTIME in io_apic.c) from the pm tree and various commits from the tip tree. I fixed it up (the tip tree seems to have made extensive changes to this file and there are no longer any references to CONFIG_PM_RUNTIME, so I used the tip tree version) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpf2yS2rfLBb.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the pm tree
On Tuesday, November 25, 2014 04:46:40 PM Stephen Rothwell wrote: > > --Sig_/T.+7iMvUwEH92u+UTGF86Po > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Hi all, > > Today's linux-next merge of the tip tree got a conflict in > drivers/acpi/processor_core.c between commit 9d48ea9f967b ("ACPI / > processor: Convert apic_id to phys_id to make it arch agnostic") from > the pm tree and commits 5922b6f497ed ("ACPI: Fix minor syntax issues in > processor_core.c") and 717ed6192d16 ("ACPI: Add interfaces to parse > IOAPIC ID for IOAPIC hotplug") from the tip tree. > > I fixed it up (see below) and can carry the fix as necessary (no action > is required). Since the material in my acpi-processor branch is only a cleanup, I'm dropping it from linux-next. We'll rebase it and apply it later when the IOAPIC hotplug stuff settles. Rafael > diff --cc drivers/acpi/processor_core.c > index 0f6f73ed41f2,f124cbb491d9.. > --- a/drivers/acpi/processor_core.c > +++ b/drivers/acpi/processor_core.c > @@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su > static int map_madt_entry(int type, u32 acpi_id) > { > unsigned long madt_end, entry; > - static struct acpi_table_madt *madt; > - static int read_madt; > -int apic_id =3D -1; > +int phys_id =3D -1; /* CPU hardware ID */ > + struct acpi_table_madt *madt; > =20 > - if (!read_madt) { > - if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0, > - (struct acpi_table_header ** > - madt =3D NULL; > - read_madt++; > - } > -=20 > + madt =3D get_madt_table(); > if (!madt) > -return apic_id; > +return phys_id; > =20 > entry =3D (unsigned long)madt; > madt_end =3D entry + madt->header.length; > @@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha > } > =20 > header =3D (struct acpi_subtable_header *)obj->buffer.pointer; > - if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC) { > + if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC) > -map_lapic_id(header, acpi_id, _id); > +map_lapic_id(header, acpi_id, _id); > - } else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC) { > + else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC) > -map_lsapic_id(header, type, acpi_id, _id); > +map_lsapic_id(header, type, acpi_id, _id); > - } else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC) { > + else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC) > -map_x2apic_id(header, type, acpi_id, _id); > +map_x2apic_id(header, type, acpi_id, _id); > - } > =20 > exit: > kfree(buffer.pointer); > @@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp > =20 > int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id) > { > -int apic_id; > +int phys_id; > =20 > -apic_id =3D acpi_get_apicid(handle, type, acpi_id); > +phys_id =3D acpi_get_phys_id(handle, type, acpi_id); > =20 > -return acpi_map_cpuid(apic_id, acpi_id); > +return acpi_map_cpuid(phys_id, acpi_id); > } > EXPORT_SYMBOL_GPL(acpi_get_cpuid); > +=20 > + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC > + static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base, > + u64 *phys_addr, int *ioapic_id) > + { > + struct acpi_madt_io_apic *ioapic =3D (struct acpi_madt_io_apic *)entry; > +=20 > + if (ioapic->global_irq_base !=3D gsi_base) > + return 0; > +=20 > + *phys_addr =3D ioapic->address; > + *ioapic_id =3D ioapic->id; > + return 1; > + } > +=20 > + static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr) > + { > + struct acpi_subtable_header *hdr; > + unsigned long madt_end, entry; > + struct acpi_table_madt *madt; > + int apic_id =3D -1; > +=20 > + madt =3D get_madt_table(); > + if (!madt) > + return apic_id; > +=20 > + entry =3D (unsigned long)madt; > + madt_end =3D entry + madt->header.length; > +=20 > + /* Parse all entries looking for a match. */ > + entry +=3D sizeof(struct acpi_table_madt); > + while (entry + sizeof(struct acpi_subtable_header) < madt_end) { > + hdr =3D (struct acpi_subtable_header *)entry; > + if (hdr->type =3D=3D ACPI_MADT_TYPE_IO_APIC && > + get_ioapic_id(hdr, gsi_base, phys_addr, _id)) > + break; > + else > + entry +=3D hdr->length; > + } > +=20 > + return apic_id; > + } > +=20 > + static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base, > + u64 *phys_addr) > + { > + struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL }; > + struct acpi_subtable_header *header; > + union acpi_object *obj; > +
Re: linux-next: manual merge of the tip tree with the pm tree
On Tuesday, November 25, 2014 04:46:40 PM Stephen Rothwell wrote: --Sig_/T.+7iMvUwEH92u+UTGF86Po Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/processor_core.c between commit 9d48ea9f967b (ACPI / processor: Convert apic_id to phys_id to make it arch agnostic) from the pm tree and commits 5922b6f497ed (ACPI: Fix minor syntax issues in processor_core.c) and 717ed6192d16 (ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Since the material in my acpi-processor branch is only a cleanup, I'm dropping it from linux-next. We'll rebase it and apply it later when the IOAPIC hotplug stuff settles. Rafael diff --cc drivers/acpi/processor_core.c index 0f6f73ed41f2,f124cbb491d9.. --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su static int map_madt_entry(int type, u32 acpi_id) { unsigned long madt_end, entry; - static struct acpi_table_madt *madt; - static int read_madt; -int apic_id =3D -1; +int phys_id =3D -1; /* CPU hardware ID */ + struct acpi_table_madt *madt; =20 - if (!read_madt) { - if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0, - (struct acpi_table_header **)madt))) - madt =3D NULL; - read_madt++; - } -=20 + madt =3D get_madt_table(); if (!madt) -return apic_id; +return phys_id; =20 entry =3D (unsigned long)madt; madt_end =3D entry + madt-header.length; @@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha } =20 header =3D (struct acpi_subtable_header *)obj-buffer.pointer; - if (header-type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC) { + if (header-type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC) -map_lapic_id(header, acpi_id, apic_id); +map_lapic_id(header, acpi_id, phys_id); - } else if (header-type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC) { + else if (header-type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC) -map_lsapic_id(header, type, acpi_id, apic_id); +map_lsapic_id(header, type, acpi_id, phys_id); - } else if (header-type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC) { + else if (header-type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC) -map_x2apic_id(header, type, acpi_id, apic_id); +map_x2apic_id(header, type, acpi_id, phys_id); - } =20 exit: kfree(buffer.pointer); @@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp =20 int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id) { -int apic_id; +int phys_id; =20 -apic_id =3D acpi_get_apicid(handle, type, acpi_id); +phys_id =3D acpi_get_phys_id(handle, type, acpi_id); =20 -return acpi_map_cpuid(apic_id, acpi_id); +return acpi_map_cpuid(phys_id, acpi_id); } EXPORT_SYMBOL_GPL(acpi_get_cpuid); +=20 + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC + static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base, + u64 *phys_addr, int *ioapic_id) + { + struct acpi_madt_io_apic *ioapic =3D (struct acpi_madt_io_apic *)entry; +=20 + if (ioapic-global_irq_base !=3D gsi_base) + return 0; +=20 + *phys_addr =3D ioapic-address; + *ioapic_id =3D ioapic-id; + return 1; + } +=20 + static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr) + { + struct acpi_subtable_header *hdr; + unsigned long madt_end, entry; + struct acpi_table_madt *madt; + int apic_id =3D -1; +=20 + madt =3D get_madt_table(); + if (!madt) + return apic_id; +=20 + entry =3D (unsigned long)madt; + madt_end =3D entry + madt-header.length; +=20 + /* Parse all entries looking for a match. */ + entry +=3D sizeof(struct acpi_table_madt); + while (entry + sizeof(struct acpi_subtable_header) madt_end) { + hdr =3D (struct acpi_subtable_header *)entry; + if (hdr-type =3D=3D ACPI_MADT_TYPE_IO_APIC + get_ioapic_id(hdr, gsi_base, phys_addr, apic_id)) + break; + else + entry +=3D hdr-length; + } +=20 + return apic_id; + } +=20 + static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base, + u64 *phys_addr) + { + struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_subtable_header *header; + union acpi_object *obj; + int apic_id =3D -1; +=20 + if (ACPI_FAILURE(acpi_evaluate_object(handle, _MAT, NULL, buffer))) +
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/processor_core.c between commit 9d48ea9f967b ("ACPI / processor: Convert apic_id to phys_id to make it arch agnostic") from the pm tree and commits 5922b6f497ed ("ACPI: Fix minor syntax issues in processor_core.c") and 717ed6192d16 ("ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/processor_core.c index 0f6f73ed41f2,f124cbb491d9.. --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su static int map_madt_entry(int type, u32 acpi_id) { unsigned long madt_end, entry; - static struct acpi_table_madt *madt; - static int read_madt; - int apic_id = -1; + int phys_id = -1; /* CPU hardware ID */ + struct acpi_table_madt *madt; - if (!read_madt) { - if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0, - (struct acpi_table_header ** - madt = NULL; - read_madt++; - } - + madt = get_madt_table(); if (!madt) - return apic_id; + return phys_id; entry = (unsigned long)madt; madt_end = entry + madt->header.length; @@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha } header = (struct acpi_subtable_header *)obj->buffer.pointer; - if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) { + if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) - map_lapic_id(header, acpi_id, _id); + map_lapic_id(header, acpi_id, _id); - } else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) { + else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) - map_lsapic_id(header, type, acpi_id, _id); + map_lsapic_id(header, type, acpi_id, _id); - } else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) { + else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) - map_x2apic_id(header, type, acpi_id, _id); + map_x2apic_id(header, type, acpi_id, _id); - } exit: kfree(buffer.pointer); @@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id) { - int apic_id; + int phys_id; - apic_id = acpi_get_apicid(handle, type, acpi_id); + phys_id = acpi_get_phys_id(handle, type, acpi_id); - return acpi_map_cpuid(apic_id, acpi_id); + return acpi_map_cpuid(phys_id, acpi_id); } EXPORT_SYMBOL_GPL(acpi_get_cpuid); + + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC + static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base, +u64 *phys_addr, int *ioapic_id) + { + struct acpi_madt_io_apic *ioapic = (struct acpi_madt_io_apic *)entry; + + if (ioapic->global_irq_base != gsi_base) + return 0; + + *phys_addr = ioapic->address; + *ioapic_id = ioapic->id; + return 1; + } + + static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr) + { + struct acpi_subtable_header *hdr; + unsigned long madt_end, entry; + struct acpi_table_madt *madt; + int apic_id = -1; + + madt = get_madt_table(); + if (!madt) + return apic_id; + + entry = (unsigned long)madt; + madt_end = entry + madt->header.length; + + /* Parse all entries looking for a match. */ + entry += sizeof(struct acpi_table_madt); + while (entry + sizeof(struct acpi_subtable_header) < madt_end) { + hdr = (struct acpi_subtable_header *)entry; + if (hdr->type == ACPI_MADT_TYPE_IO_APIC && + get_ioapic_id(hdr, gsi_base, phys_addr, _id)) + break; + else + entry += hdr->length; + } + + return apic_id; + } + + static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base, + u64 *phys_addr) + { + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_subtable_header *header; + union acpi_object *obj; + int apic_id = -1; + + if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, ))) + goto exit; + + if (!buffer.length || !buffer.pointer) + goto exit; + + obj = buffer.pointer; + if (obj->type != ACPI_TYPE_BUFFER || + obj->buffer.length < sizeof(struct acpi_subtable_header)) + goto exit; + + header = (struct acpi_subtable_header *)obj->buffer.pointer; + if (header->type == ACPI_MADT_TYPE_IO_APIC) +
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/processor_core.c between commit 9d48ea9f967b (ACPI / processor: Convert apic_id to phys_id to make it arch agnostic) from the pm tree and commits 5922b6f497ed (ACPI: Fix minor syntax issues in processor_core.c) and 717ed6192d16 (ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/processor_core.c index 0f6f73ed41f2,f124cbb491d9.. --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su static int map_madt_entry(int type, u32 acpi_id) { unsigned long madt_end, entry; - static struct acpi_table_madt *madt; - static int read_madt; - int apic_id = -1; + int phys_id = -1; /* CPU hardware ID */ + struct acpi_table_madt *madt; - if (!read_madt) { - if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0, - (struct acpi_table_header **)madt))) - madt = NULL; - read_madt++; - } - + madt = get_madt_table(); if (!madt) - return apic_id; + return phys_id; entry = (unsigned long)madt; madt_end = entry + madt-header.length; @@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha } header = (struct acpi_subtable_header *)obj-buffer.pointer; - if (header-type == ACPI_MADT_TYPE_LOCAL_APIC) { + if (header-type == ACPI_MADT_TYPE_LOCAL_APIC) - map_lapic_id(header, acpi_id, apic_id); + map_lapic_id(header, acpi_id, phys_id); - } else if (header-type == ACPI_MADT_TYPE_LOCAL_SAPIC) { + else if (header-type == ACPI_MADT_TYPE_LOCAL_SAPIC) - map_lsapic_id(header, type, acpi_id, apic_id); + map_lsapic_id(header, type, acpi_id, phys_id); - } else if (header-type == ACPI_MADT_TYPE_LOCAL_X2APIC) { + else if (header-type == ACPI_MADT_TYPE_LOCAL_X2APIC) - map_x2apic_id(header, type, acpi_id, apic_id); + map_x2apic_id(header, type, acpi_id, phys_id); - } exit: kfree(buffer.pointer); @@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id) { - int apic_id; + int phys_id; - apic_id = acpi_get_apicid(handle, type, acpi_id); + phys_id = acpi_get_phys_id(handle, type, acpi_id); - return acpi_map_cpuid(apic_id, acpi_id); + return acpi_map_cpuid(phys_id, acpi_id); } EXPORT_SYMBOL_GPL(acpi_get_cpuid); + + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC + static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base, +u64 *phys_addr, int *ioapic_id) + { + struct acpi_madt_io_apic *ioapic = (struct acpi_madt_io_apic *)entry; + + if (ioapic-global_irq_base != gsi_base) + return 0; + + *phys_addr = ioapic-address; + *ioapic_id = ioapic-id; + return 1; + } + + static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr) + { + struct acpi_subtable_header *hdr; + unsigned long madt_end, entry; + struct acpi_table_madt *madt; + int apic_id = -1; + + madt = get_madt_table(); + if (!madt) + return apic_id; + + entry = (unsigned long)madt; + madt_end = entry + madt-header.length; + + /* Parse all entries looking for a match. */ + entry += sizeof(struct acpi_table_madt); + while (entry + sizeof(struct acpi_subtable_header) madt_end) { + hdr = (struct acpi_subtable_header *)entry; + if (hdr-type == ACPI_MADT_TYPE_IO_APIC + get_ioapic_id(hdr, gsi_base, phys_addr, apic_id)) + break; + else + entry += hdr-length; + } + + return apic_id; + } + + static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base, + u64 *phys_addr) + { + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_subtable_header *header; + union acpi_object *obj; + int apic_id = -1; + + if (ACPI_FAILURE(acpi_evaluate_object(handle, _MAT, NULL, buffer))) + goto exit; + + if (!buffer.length || !buffer.pointer) + goto exit; + + obj = buffer.pointer; + if (obj-type != ACPI_TYPE_BUFFER || + obj-buffer.length sizeof(struct acpi_subtable_header)) + goto exit; + + header = (struct acpi_subtable_header *)obj-buffer.pointer; + if (header-type == ACPI_MADT_TYPE_IO_APIC) +
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/x86/Kconfig between commit 8a1664be0b92 ("ACPI: add config for BIOS table scan") from the pm tree and commit 44a69f619562 ("acpi, apei, ghes: Make NMI error notification to be GHES architecture extension") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/x86/Kconfig index ac5a788d2432,4559c4e114d1.. --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@@ -133,7 -132,8 +133,9 @@@ config X8 select GENERIC_CPU_AUTOPROBE select HAVE_ARCH_AUDITSYSCALL select ARCH_SUPPORTS_ATOMIC_RMW + select ACPI_LEGACY_TABLES_LOOKUP if ACPI + select HAVE_ACPI_APEI if ACPI + select HAVE_ACPI_APEI_NMI if ACPI config INSTRUCTION_DECODER def_bool y signature.asc Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/x86/Kconfig between commit 8a1664be0b92 (ACPI: add config for BIOS table scan) from the pm tree and commit 44a69f619562 (acpi, apei, ghes: Make NMI error notification to be GHES architecture extension) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/x86/Kconfig index ac5a788d2432,4559c4e114d1.. --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@@ -133,7 -132,8 +133,9 @@@ config X8 select GENERIC_CPU_AUTOPROBE select HAVE_ARCH_AUDITSYSCALL select ARCH_SUPPORTS_ATOMIC_RMW + select ACPI_LEGACY_TABLES_LOOKUP if ACPI + select HAVE_ACPI_APEI if ACPI + select HAVE_ACPI_APEI_NMI if ACPI config INSTRUCTION_DECODER def_bool y signature.asc Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in kernel/sched/idle.c between commit 52c324f8a87b ("cpuidle: Combine cpuidle_enabled() with cpuidle_select()") from the pm tree and commit 37352273ad48 ("sched/idle: Reflow cpuidle_idle_call()") from the tip tree. I fixed it up (I hope - see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc kernel/sched/idle.c index a8f12247ce7c,34083c9ac976.. --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@@ -101,77 -98,74 +98,69 @@@ static void cpuidle_idle_call(void rcu_idle_enter(); /* - * Check if the cpuidle framework is ready, otherwise fallback - * to the default arch specific idle method + * Ask the cpuidle framework to choose a convenient idle state. + * Fall back to the default arch specific idle method on errors. */ - if (cpuidle_enabled(drv, dev)) { + next_state = cpuidle_select(drv, dev); + - ret = next_state; - if (ret >= 0) { ++ if (next_state < 0) { + use_default: /* -* The idle task must be scheduled, it is pointless to -* go to idle, just update no idle residency and get -* out of this function +* We can't use the cpuidle framework, let's use the default +* idle routine. */ - if (current_clr_polling_and_test()) { - dev->last_residency = 0; - entered_state = next_state; + if (current_clr_polling_and_test()) local_irq_enable(); - } else { - broadcast = !!(drv->states[next_state].flags & - CPUIDLE_FLAG_TIMER_STOP); - - if (broadcast) - /* -* Tell the time framework to switch -* to a broadcast timer because our -* local timer will be shutdown. If a -* local timer is used from another -* cpu as a broadcast timer, this call -* may fail if it is not available -*/ - ret = clockevents_notify( - CLOCK_EVT_NOTIFY_BROADCAST_ENTER, - >cpu); - - if (ret >= 0) { - trace_cpu_idle_rcuidle(next_state, dev->cpu); - - /* -* Enter the idle state previously -* returned by the governor -* decision. This function will block -* until an interrupt occurs and will -* take care of re-enabling the local -* interrupts -*/ - entered_state = cpuidle_enter(drv, dev, - next_state); - - trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, - dev->cpu); - - if (broadcast) - clockevents_notify( - CLOCK_EVT_NOTIFY_BROADCAST_EXIT, - >cpu); - - /* -* Give the governor an opportunity to reflect on the -* outcome -*/ - cpuidle_reflect(dev, entered_state); - } - } + else + arch_cpu_idle(); + + goto exit_idle; + } + + /* - * Ask the governor to choose an idle state it thinks - * it is convenient to go to. There is *always* a - * convenient idle state - */ - next_state = cpuidle_select(drv, dev); - - /* +* The idle task must be scheduled, it is pointless to +* go to idle, just update no idle residency and get +* out of this function +*/ + if (current_clr_polling_and_test()) { + dev->last_residency = 0; + entered_state = next_state; + local_irq_enable(); + goto exit_idle; } + broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP); + /* -* We can't use the cpuidle framework, let's use the default -* idle routine +* Tell the time framework to switch to a broadcast
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in kernel/sched/idle.c between commit 52c324f8a87b (cpuidle: Combine cpuidle_enabled() with cpuidle_select()) from the pm tree and commit 37352273ad48 (sched/idle: Reflow cpuidle_idle_call()) from the tip tree. I fixed it up (I hope - see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc kernel/sched/idle.c index a8f12247ce7c,34083c9ac976.. --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@@ -101,77 -98,74 +98,69 @@@ static void cpuidle_idle_call(void rcu_idle_enter(); /* - * Check if the cpuidle framework is ready, otherwise fallback - * to the default arch specific idle method + * Ask the cpuidle framework to choose a convenient idle state. + * Fall back to the default arch specific idle method on errors. */ - if (cpuidle_enabled(drv, dev)) { + next_state = cpuidle_select(drv, dev); + - ret = next_state; - if (ret = 0) { ++ if (next_state 0) { + use_default: /* -* The idle task must be scheduled, it is pointless to -* go to idle, just update no idle residency and get -* out of this function +* We can't use the cpuidle framework, let's use the default +* idle routine. */ - if (current_clr_polling_and_test()) { - dev-last_residency = 0; - entered_state = next_state; + if (current_clr_polling_and_test()) local_irq_enable(); - } else { - broadcast = !!(drv-states[next_state].flags - CPUIDLE_FLAG_TIMER_STOP); - - if (broadcast) - /* -* Tell the time framework to switch -* to a broadcast timer because our -* local timer will be shutdown. If a -* local timer is used from another -* cpu as a broadcast timer, this call -* may fail if it is not available -*/ - ret = clockevents_notify( - CLOCK_EVT_NOTIFY_BROADCAST_ENTER, - dev-cpu); - - if (ret = 0) { - trace_cpu_idle_rcuidle(next_state, dev-cpu); - - /* -* Enter the idle state previously -* returned by the governor -* decision. This function will block -* until an interrupt occurs and will -* take care of re-enabling the local -* interrupts -*/ - entered_state = cpuidle_enter(drv, dev, - next_state); - - trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, - dev-cpu); - - if (broadcast) - clockevents_notify( - CLOCK_EVT_NOTIFY_BROADCAST_EXIT, - dev-cpu); - - /* -* Give the governor an opportunity to reflect on the -* outcome -*/ - cpuidle_reflect(dev, entered_state); - } - } + else + arch_cpu_idle(); + + goto exit_idle; + } + + /* - * Ask the governor to choose an idle state it thinks - * it is convenient to go to. There is *always* a - * convenient idle state - */ - next_state = cpuidle_select(drv, dev); - - /* +* The idle task must be scheduled, it is pointless to +* go to idle, just update no idle residency and get +* out of this function +*/ + if (current_clr_polling_and_test()) { + dev-last_residency = 0; + entered_state = next_state; + local_irq_enable(); + goto exit_idle; } + broadcast = !!(drv-states[next_state].flags CPUIDLE_FLAG_TIMER_STOP); + /* -* We can't use the cpuidle framework, let's use the default -* idle routine +* Tell the time framework to switch to a broadcast timer +
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/apei/einj.c between commit 8b48463f8942 ("ACPI: Clean up inclusions of ACPI header files") from the pm tree and commit d3ab3edc029b ("ACPI, APEI: Cleanup alignment-aware accesses") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/apei/einj.c index ca0c6d7ec0d4,7dcc8a824aae.. --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@@ -33,6 -33,8 +33,7 @@@ #include #include #include -#include + #include #include "apei-internal.h" pgpKNEr9RZMYF.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/apei/einj.c between commit 8b48463f8942 (ACPI: Clean up inclusions of ACPI header files) from the pm tree and commit d3ab3edc029b (ACPI, APEI: Cleanup alignment-aware accesses) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/apei/einj.c index ca0c6d7ec0d4,7dcc8a824aae.. --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@@ -33,6 -33,8 +33,7 @@@ #include linux/nmi.h #include linux/delay.h #include linux/mm.h -#include acpi/acpi.h + #include asm/unaligned.h #include apei-internal.h pgpKNEr9RZMYF.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/processor_idle.c between commit 6cb85b2b9df9 ("ACPI / cpuidle: fix max idle state handling with hotplug CPU support") from the pm tree and commit 16824255394f ("x86, acpi, idle: Restructure the mwait idle routines") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/processor_idle.c index 1fc455b8ce17,f90c56c8379e.. --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@@ -783,18 -780,6 +778,13 @@@ static int acpi_idle_enter_simple(struc if (unlikely(!pr)) return -EINVAL; +#ifdef CONFIG_HOTPLUG_CPU + if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) && + !pr->flags.has_cst && + !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED)) + return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START); +#endif + - if (cx->entry_method == ACPI_CSTATE_FFH) { - if (current_set_polling_and_test()) - return -EINVAL; - } - /* * Must be done before busmaster disable as we might need to * access HPET ! pgpgyDHqKAKcA.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/processor_idle.c between commit 6cb85b2b9df9 (ACPI / cpuidle: fix max idle state handling with hotplug CPU support) from the pm tree and commit 16824255394f (x86, acpi, idle: Restructure the mwait idle routines) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/processor_idle.c index 1fc455b8ce17,f90c56c8379e.. --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@@ -783,18 -780,6 +778,13 @@@ static int acpi_idle_enter_simple(struc if (unlikely(!pr)) return -EINVAL; +#ifdef CONFIG_HOTPLUG_CPU + if ((cx-type != ACPI_STATE_C1) (num_online_cpus() 1) + !pr-flags.has_cst + !(acpi_gbl_FADT.flags ACPI_FADT_C2_MP_SUPPORTED)) + return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START); +#endif + - if (cx-entry_method == ACPI_CSTATE_FFH) { - if (current_set_polling_and_test()) - return -EINVAL; - } - /* * Must be done before busmaster disable as we might need to * access HPET ! pgpgyDHqKAKcA.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/acpi_extlog.c between commit 7ede9f8a1805 ("ACPI / extlog: replace open-coded _DSM code with helper functions") from the pm tree and commit 42139eb356e3 ("ACPI, eMCA: Combine eMCA/EDAC event reporting priority") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/acpi_extlog.c index 94166680b3a3,5d33c5415405.. --- a/drivers/acpi/acpi_extlog.c +++ b/drivers/acpi/acpi_extlog.c @@@ -9,8 -9,10 +9,9 @@@ #include #include -#include #include #include + #include #include #include @@@ -40,7 -44,9 +41,9 @@@ struct extlog_l1_head u8 rev1[12]; }; + static int old_edac_report_status; + -static u8 extlog_dsm_uuid[] = "663E35AF-CC10-41A4-88EA-5470AF055295"; +static u8 extlog_dsm_uuid[] __initdata = "663E35AF-CC10-41A4-88EA-5470AF055295"; /* L1 table related physical address */ static u64 elog_base; @@@ -147,16 -153,53 +150,16 @@@ static int extlog_print(struct notifier rc = print_extlog_rcd(NULL, (struct acpi_generic_status *)elog_buf, cpu); - return NOTIFY_DONE; + return NOTIFY_STOP; } -static int extlog_get_dsm(acpi_handle handle, int rev, int func, u64 *ret) +static bool __init extlog_get_l1addr(void) { - struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL}; - struct acpi_object_list input; - union acpi_object params[4], *obj; u8 uuid[16]; - int i; + acpi_handle handle; + union acpi_object *obj; acpi_str_to_uuid(extlog_dsm_uuid, uuid); - input.count = 4; - input.pointer = params; - params[0].type = ACPI_TYPE_BUFFER; - params[0].buffer.length = 16; - params[0].buffer.pointer = uuid; - params[1].type = ACPI_TYPE_INTEGER; - params[1].integer.value = rev; - params[2].type = ACPI_TYPE_INTEGER; - params[2].integer.value = func; - params[3].type = ACPI_TYPE_PACKAGE; - params[3].package.count = 0; - params[3].package.elements = NULL; - - if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DSM", , ))) - return -1; - - *ret = 0; - obj = (union acpi_object *)buf.pointer; - if (obj->type == ACPI_TYPE_INTEGER) { - *ret = obj->integer.value; - } else if (obj->type == ACPI_TYPE_BUFFER) { - if (obj->buffer.length <= 8) { - for (i = 0; i < obj->buffer.length; i++) - *ret |= (obj->buffer.pointer[i] << (i * 8)); - } - } - kfree(buf.pointer); - - return 0; -} - -static bool extlog_get_l1addr(void) -{ - acpi_handle handle; - u64 ret; if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", ))) return false; pgpkStY3kKCBr.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in drivers/acpi/acpi_extlog.c between commit 7ede9f8a1805 (ACPI / extlog: replace open-coded _DSM code with helper functions) from the pm tree and commit 42139eb356e3 (ACPI, eMCA: Combine eMCA/EDAC event reporting priority) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/acpi/acpi_extlog.c index 94166680b3a3,5d33c5415405.. --- a/drivers/acpi/acpi_extlog.c +++ b/drivers/acpi/acpi_extlog.c @@@ -9,8 -9,10 +9,9 @@@ #include linux/module.h #include linux/acpi.h -#include acpi/acpi_bus.h #include linux/cper.h #include linux/ratelimit.h + #include linux/edac.h #include asm/cpu.h #include asm/mce.h @@@ -40,7 -44,9 +41,9 @@@ struct extlog_l1_head u8 rev1[12]; }; + static int old_edac_report_status; + -static u8 extlog_dsm_uuid[] = 663E35AF-CC10-41A4-88EA-5470AF055295; +static u8 extlog_dsm_uuid[] __initdata = 663E35AF-CC10-41A4-88EA-5470AF055295; /* L1 table related physical address */ static u64 elog_base; @@@ -147,16 -153,53 +150,16 @@@ static int extlog_print(struct notifier rc = print_extlog_rcd(NULL, (struct acpi_generic_status *)elog_buf, cpu); - return NOTIFY_DONE; + return NOTIFY_STOP; } -static int extlog_get_dsm(acpi_handle handle, int rev, int func, u64 *ret) +static bool __init extlog_get_l1addr(void) { - struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL}; - struct acpi_object_list input; - union acpi_object params[4], *obj; u8 uuid[16]; - int i; + acpi_handle handle; + union acpi_object *obj; acpi_str_to_uuid(extlog_dsm_uuid, uuid); - input.count = 4; - input.pointer = params; - params[0].type = ACPI_TYPE_BUFFER; - params[0].buffer.length = 16; - params[0].buffer.pointer = uuid; - params[1].type = ACPI_TYPE_INTEGER; - params[1].integer.value = rev; - params[2].type = ACPI_TYPE_INTEGER; - params[2].integer.value = func; - params[3].type = ACPI_TYPE_PACKAGE; - params[3].package.count = 0; - params[3].package.elements = NULL; - - if (ACPI_FAILURE(acpi_evaluate_object(handle, _DSM, input, buf))) - return -1; - - *ret = 0; - obj = (union acpi_object *)buf.pointer; - if (obj-type == ACPI_TYPE_INTEGER) { - *ret = obj-integer.value; - } else if (obj-type == ACPI_TYPE_BUFFER) { - if (obj-buffer.length = 8) { - for (i = 0; i obj-buffer.length; i++) - *ret |= (obj-buffer.pointer[i] (i * 8)); - } - } - kfree(buf.pointer); - - return 0; -} - -static bool extlog_get_l1addr(void) -{ - acpi_handle handle; - u64 ret; if (ACPI_FAILURE(acpi_get_handle(NULL, \\_SB, handle))) return false; pgpkStY3kKCBr.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/x86/include/asm/processor.h between commit 61c63e5ed3b9 ("cpufreq: Remove unused APERF/MPERF support") from the pm tree and commit 96e39ac0e9d1 ("x86: Introduce hypervisor_cpuid_base()") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/x86/include/asm/processor.h index 4f4a3d9,61a5533..000 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@@ -942,6 -942,50 +942,21 @@@ extern int set_tsc_mode(unsigned int va extern u16 amd_get_nb_id(int cpu); -struct aperfmperf { - u64 aperf, mperf; -}; - -static inline void get_aperfmperf(struct aperfmperf *am) -{ - WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_APERFMPERF)); - - rdmsrl(MSR_IA32_APERF, am->aperf); - rdmsrl(MSR_IA32_MPERF, am->mperf); -} - -#define APERFMPERF_SHIFT 10 - -static inline -unsigned long calc_aperfmperf_ratio(struct aperfmperf *old, - struct aperfmperf *new) -{ - u64 aperf = new->aperf - old->aperf; - u64 mperf = new->mperf - old->mperf; - unsigned long ratio = aperf; - - mperf >>= APERFMPERF_SHIFT; - if (mperf) - ratio = div64_u64(aperf, mperf); - - return ratio; -} - + static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) + { + uint32_t base, eax, signature[3]; + + for (base = 0x4000; base < 0x4001; base += 0x100) { + cpuid(base, , [0], [1], [2]); + + if (!memcmp(sig, signature, 12) && + (leaves == 0 || ((eax - base) >= leaves))) + return base; + } + + return 0; + } + extern unsigned long arch_align_stack(unsigned long sp); extern void free_init_pages(char *what, unsigned long begin, unsigned long end); pgp5pFW59kRiO.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in arch/x86/include/asm/processor.h between commit 61c63e5ed3b9 (cpufreq: Remove unused APERF/MPERF support) from the pm tree and commit 96e39ac0e9d1 (x86: Introduce hypervisor_cpuid_base()) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/x86/include/asm/processor.h index 4f4a3d9,61a5533..000 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@@ -942,6 -942,50 +942,21 @@@ extern int set_tsc_mode(unsigned int va extern u16 amd_get_nb_id(int cpu); -struct aperfmperf { - u64 aperf, mperf; -}; - -static inline void get_aperfmperf(struct aperfmperf *am) -{ - WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_APERFMPERF)); - - rdmsrl(MSR_IA32_APERF, am-aperf); - rdmsrl(MSR_IA32_MPERF, am-mperf); -} - -#define APERFMPERF_SHIFT 10 - -static inline -unsigned long calc_aperfmperf_ratio(struct aperfmperf *old, - struct aperfmperf *new) -{ - u64 aperf = new-aperf - old-aperf; - u64 mperf = new-mperf - old-mperf; - unsigned long ratio = aperf; - - mperf = APERFMPERF_SHIFT; - if (mperf) - ratio = div64_u64(aperf, mperf); - - return ratio; -} - + static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) + { + uint32_t base, eax, signature[3]; + + for (base = 0x4000; base 0x4001; base += 0x100) { + cpuid(base, eax, signature[0], signature[1], signature[2]); + + if (!memcmp(sig, signature, 12) + (leaves == 0 || ((eax - base) = leaves))) + return base; + } + + return 0; + } + extern unsigned long arch_align_stack(unsigned long sp); extern void free_init_pages(char *what, unsigned long begin, unsigned long end); pgp5pFW59kRiO.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in include/linux/clockchips.h between commit 4dbad816febb ("timer: move enum definition out of ifdef section") from the pm tree and commit 19919226c3f2 ("clockevents: Add missing tick_check_broadcast_expired() for CLOCKEVENTS=n") from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc include/linux/clockchips.h index f9fd937,464e229..000 --- a/include/linux/clockchips.h +++ b/include/linux/clockchips.h @@@ -181,7 -192,8 +192,8 @@@ static inline void clockevents_notify(u static inline void clockevents_suspend(void) {} static inline void clockevents_resume(void) {} -#define clockevents_notify(reason, arg) do { } while (0) +static inline void clockevents_notify(unsigned long reason, void *arg) {} + static inline int tick_check_broadcast_expired(void) { return 0; } #endif pgpVHVUIxGt1Q.pgp Description: PGP signature
linux-next: manual merge of the tip tree with the pm tree
Hi all, Today's linux-next merge of the tip tree got a conflict in include/linux/clockchips.h between commit 4dbad816febb (timer: move enum definition out of ifdef section) from the pm tree and commit 19919226c3f2 (clockevents: Add missing tick_check_broadcast_expired() for CLOCKEVENTS=n) from the tip tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc include/linux/clockchips.h index f9fd937,464e229..000 --- a/include/linux/clockchips.h +++ b/include/linux/clockchips.h @@@ -181,7 -192,8 +192,8 @@@ static inline void clockevents_notify(u static inline void clockevents_suspend(void) {} static inline void clockevents_resume(void) {} -#define clockevents_notify(reason, arg) do { } while (0) +static inline void clockevents_notify(unsigned long reason, void *arg) {} + static inline int tick_check_broadcast_expired(void) { return 0; } #endif pgpVHVUIxGt1Q.pgp Description: PGP signature