All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon at arm.com>
To: devel@acpica.org
Subject: Re: [Devel] [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing
Date: Fri, 15 Feb 2019 15:00:15 +0000	[thread overview]
Message-ID: <20190215150015.GA6803@fuggles.cambridge.arm.com> (raw)
In-Reply-To: c740a06e-d5d3-3e42-d19b-fbfea02ac0e7@arm.com

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Thu, Feb 14, 2019 at 12:03:57PM -0600, Jeremy Linton wrote:
> On 2/14/19 11:11 AM, Will Deacon wrote:
> > On Fri, Feb 08, 2019 at 06:47:17PM -0600, Jeremy Linton wrote:
> > > +/*
> > > + * For lack of a better place, hook the normal PMU MADT walk
> > > + * and create a SPE device if we detect a recent MADT with
> > > + * a homogeneous PPI mapping.
> > > + */
> > > +static int arm_spe_acpi_parse_irqs(void)
> > > +{
> > > +	int cpu, ret, irq;
> > > +	u16 gsi = 0;
> > > +	bool first = true;
> > > +
> > > +	struct acpi_madt_generic_interrupt *gicc;
> > > +
> > > +	/*
> > > +	 * sanity check all the GICC tables for the same interrupt number
> > > +	 * for now we only support homogeneous ACPI/SPE machines.
> > > +	 */
> > > +	for_each_possible_cpu(cpu) {
> > > +		gicc = acpi_cpu_get_madt_gicc(cpu);
> > > +
> > > +		if (gicc->header.length < ACPI_MADT_GICC_SPE)
> > > +			return -ENODEV;
> > > +
> > > +		if (first) {
> > > +			gsi = gicc->spe_overflow_interrupt;
> > > +			if (!gsi)
> > > +				return -ENODEV;
> > > +			first = false;
> > > +		} else if (gsi != gicc->spe_overflow_interrupt) {
> > > +			pr_warn("ACPI: SPE must have homogeneous interrupts\n");
> > > +			return -EINVAL;
> > > +		}
> > 
> > Unfortunately, I don't think this is sufficient to detect a homogeneous
> > system: we'll have to check the MIDRs instead, which is nasty. I would
> > personally be in favour of enforcing homogeneity for ACPI systems when we
> > bring up secondary CPUs, but I suspect others would disagree.
> 
> Given that all the SPE capable machines i'm aware of at the moment are
> homogeneous, are we ok with just doing an online CPU MIDR check for now, and
> cleaning that up if/when someone builds a machine and complains?

Yeah, I think we added a new bit to the PPTT to tell you that the machine is
homogenous, so just check that first and bail if it's not set.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	devel@acpica.org, catalin.marinas@arm.com, mark.rutland@arm.com,
	robert.moore@intel.com, erik.schmauss@intel.com,
	rafael.j.wysocki@intel.com, lenb@kernel.org
Subject: Re: [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing
Date: Fri, 15 Feb 2019 15:00:15 +0000	[thread overview]
Message-ID: <20190215150015.GA6803@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <c740a06e-d5d3-3e42-d19b-fbfea02ac0e7@arm.com>

On Thu, Feb 14, 2019 at 12:03:57PM -0600, Jeremy Linton wrote:
> On 2/14/19 11:11 AM, Will Deacon wrote:
> > On Fri, Feb 08, 2019 at 06:47:17PM -0600, Jeremy Linton wrote:
> > > +/*
> > > + * For lack of a better place, hook the normal PMU MADT walk
> > > + * and create a SPE device if we detect a recent MADT with
> > > + * a homogeneous PPI mapping.
> > > + */
> > > +static int arm_spe_acpi_parse_irqs(void)
> > > +{
> > > +	int cpu, ret, irq;
> > > +	u16 gsi = 0;
> > > +	bool first = true;
> > > +
> > > +	struct acpi_madt_generic_interrupt *gicc;
> > > +
> > > +	/*
> > > +	 * sanity check all the GICC tables for the same interrupt number
> > > +	 * for now we only support homogeneous ACPI/SPE machines.
> > > +	 */
> > > +	for_each_possible_cpu(cpu) {
> > > +		gicc = acpi_cpu_get_madt_gicc(cpu);
> > > +
> > > +		if (gicc->header.length < ACPI_MADT_GICC_SPE)
> > > +			return -ENODEV;
> > > +
> > > +		if (first) {
> > > +			gsi = gicc->spe_overflow_interrupt;
> > > +			if (!gsi)
> > > +				return -ENODEV;
> > > +			first = false;
> > > +		} else if (gsi != gicc->spe_overflow_interrupt) {
> > > +			pr_warn("ACPI: SPE must have homogeneous interrupts\n");
> > > +			return -EINVAL;
> > > +		}
> > 
> > Unfortunately, I don't think this is sufficient to detect a homogeneous
> > system: we'll have to check the MIDRs instead, which is nasty. I would
> > personally be in favour of enforcing homogeneity for ACPI systems when we
> > bring up secondary CPUs, but I suspect others would disagree.
> 
> Given that all the SPE capable machines i'm aware of at the moment are
> homogeneous, are we ok with just doing an online CPU MIDR check for now, and
> cleaning that up if/when someone builds a machine and complains?

Yeah, I think we added a new bit to the PPTT to tell you that the machine is
homogenous, so just check that first and bail if it's not set.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: mark.rutland@arm.com, catalin.marinas@arm.com,
	rafael.j.wysocki@intel.com, linux-kernel@vger.kernel.org,
	robert.moore@intel.com, linux-acpi@vger.kernel.org,
	lenb@kernel.org, erik.schmauss@intel.com,
	linux-arm-kernel@lists.infradead.org, devel@acpica.org
Subject: Re: [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing
Date: Fri, 15 Feb 2019 15:00:15 +0000	[thread overview]
Message-ID: <20190215150015.GA6803@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <c740a06e-d5d3-3e42-d19b-fbfea02ac0e7@arm.com>

On Thu, Feb 14, 2019 at 12:03:57PM -0600, Jeremy Linton wrote:
> On 2/14/19 11:11 AM, Will Deacon wrote:
> > On Fri, Feb 08, 2019 at 06:47:17PM -0600, Jeremy Linton wrote:
> > > +/*
> > > + * For lack of a better place, hook the normal PMU MADT walk
> > > + * and create a SPE device if we detect a recent MADT with
> > > + * a homogeneous PPI mapping.
> > > + */
> > > +static int arm_spe_acpi_parse_irqs(void)
> > > +{
> > > +	int cpu, ret, irq;
> > > +	u16 gsi = 0;
> > > +	bool first = true;
> > > +
> > > +	struct acpi_madt_generic_interrupt *gicc;
> > > +
> > > +	/*
> > > +	 * sanity check all the GICC tables for the same interrupt number
> > > +	 * for now we only support homogeneous ACPI/SPE machines.
> > > +	 */
> > > +	for_each_possible_cpu(cpu) {
> > > +		gicc = acpi_cpu_get_madt_gicc(cpu);
> > > +
> > > +		if (gicc->header.length < ACPI_MADT_GICC_SPE)
> > > +			return -ENODEV;
> > > +
> > > +		if (first) {
> > > +			gsi = gicc->spe_overflow_interrupt;
> > > +			if (!gsi)
> > > +				return -ENODEV;
> > > +			first = false;
> > > +		} else if (gsi != gicc->spe_overflow_interrupt) {
> > > +			pr_warn("ACPI: SPE must have homogeneous interrupts\n");
> > > +			return -EINVAL;
> > > +		}
> > 
> > Unfortunately, I don't think this is sufficient to detect a homogeneous
> > system: we'll have to check the MIDRs instead, which is nasty. I would
> > personally be in favour of enforcing homogeneity for ACPI systems when we
> > bring up secondary CPUs, but I suspect others would disagree.
> 
> Given that all the SPE capable machines i'm aware of at the moment are
> homogeneous, are we ok with just doing an online CPU MIDR check for now, and
> cleaning that up if/when someone builds a machine and complains?

Yeah, I think we added a new bit to the PPTT to tell you that the machine is
homogenous, so just check that first and bail if it's not set.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-02-15 15:00 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 15:00 Will Deacon [this message]
2019-02-15 15:00 ` [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing Will Deacon
2019-02-15 15:00 ` Will Deacon
  -- strict thread matches above, loose matches on Subject: below --
2019-02-15 16:04 [Devel] " Jeremy Linton
2019-02-15 16:04 ` Jeremy Linton
2019-02-15 16:04 ` Jeremy Linton
2019-02-14 18:03 [Devel] " Jeremy Linton
2019-02-14 18:03 ` Jeremy Linton
2019-02-14 18:03 ` Jeremy Linton
2019-02-14 17:11 [Devel] " Will Deacon
2019-02-14 17:11 ` Will Deacon
2019-02-14 17:11 ` Will Deacon
2019-02-11 18:27 [Devel] [RFC 1/3] ACPICA: ACPI 6.3: Add MADT/GICC/SPE extension Schmauss, Erik
2019-02-11 18:27 ` Schmauss, Erik
2019-02-11 18:27 ` Schmauss, Erik
2019-02-11 15:35 [Devel] [RFC 3/3] perf: arm_spe: Enable ACPI/Platform automatic module loading Sudeep Holla
2019-02-11 15:35 ` Sudeep Holla
2019-02-11 15:35 ` Sudeep Holla
2019-02-11 15:34 [Devel] [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing Sudeep Holla
2019-02-11 15:34 ` Sudeep Holla
2019-02-11 15:34 ` Sudeep Holla
2019-02-09  0:47 [Devel] [RFC 3/3] perf: arm_spe: Enable ACPI/Platform automatic module loading Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 [Devel] [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 [Devel] [RFC 1/3] ACPICA: ACPI 6.3: Add MADT/GICC/SPE extension Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 [Devel] [RFC 0/3] arm64: SPE ACPI enablement Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton
2019-02-09  0:47 ` Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190215150015.GA6803@fuggles.cambridge.arm.com \
    --to=devel@acpica.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.