From: Catalin Marinas <catalin.marinas@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-acpi@vger.kernel.org, Hanjun Guo <hanjun.guo@linaro.org>,
Mark Salter <msalter@redhat.com>, Al Stone <ahs3@redhat.com>,
linux-arm-kernel@lists.infradead.org, Loc Ho <lho@apm.com>
Subject: Re: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
Date: Wed, 3 Feb 2016 16:18:36 +0000 [thread overview]
Message-ID: <20160203161834.GB26487@MBP.local> (raw)
In-Reply-To: <20160203112112.GA18387@red-moon>
On Wed, Feb 03, 2016 at 11:21:12AM +0000, Lorenzo Pieralisi wrote:
> On Tue, Feb 02, 2016 at 06:26:58PM +0000, Catalin Marinas wrote:
> > On Tue, Jan 26, 2016 at 11:10:38AM +0000, Lorenzo Pieralisi wrote:
> > > The SBBR and ACPI specifications allow ACPI based systems that do not
> > > implement PSCI (eg systems with no EL3) to boot through the ACPI parking
> > > protocol specification[1].
> > >
> > > This patch implements the ACPI parking protocol CPU operations, and adds
> > > code that eases parsing the parking protocol data structures to the
> > > ARM64 SMP initializion carried out at the same time as cpus enumeration.
> > >
> > > To wake-up the CPUs from the parked state, this patch implements a
> > > wakeup IPI for ARM64 (ie arch_send_wakeup_ipi_mask()) that mirrors the
> > > ARM one, so that a specific IPI is sent for wake-up purpose in order
> > > to distinguish it from other IPI sources.
> > >
> > > Given the current ACPI MADT parsing API, the patch implements a glue
> > > layer that helps passing MADT GICC data structure from SMP initialization
> > > code to the parking protocol implementation somewhat overriding the CPU
> > > operations interfaces. This to avoid creating a completely trasparent
> > > DT/ACPI CPU operations layer that would require creating opaque
> > > structure handling for CPUs data (DT represents CPU through DT nodes, ACPI
> > > through static MADT table entries), which seems overkill given that ACPI
> > > on ARM64 mandates only two booting protocols (PSCI and parking protocol),
> > > so there is no need for further protocol additions.
> > >
> > > Based on the original work by Mark Salter <msalter@redhat.com>
> > >
> > > [1] https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.docx
> > >
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > > Cc: Loc Ho <lho@apm.com>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Mark Salter <msalter@redhat.com>
> > > Cc: Al Stone <ahs3@redhat.com>
> >
> > Applied, with a minor addition just to warn people from not using it in
> > other configurations (#ifdef still needed otherwise the
> > acpi_parking_protocol_valid symbol is not available; but I prefer uglier
> > code than people starting to use this IPI in their firmware):
>
> It makes sense, we could include asm/acpi.h in smp.c (which is not
> included by linux/acpi.h if !CONFIG_ACPI) to pull in the symbol and
> remove the ifdef if you think it is cleaner.
I don't think it's worth.
BTW, the acpi_parking_protocol_valid() definition has an __init
annotation while the declaration does not. I removed the __init
altogether since I get a section mismatch warning when being called from
handle_IPI.
--
Catalin
next prev parent reply other threads:[~2016-02-03 16:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 11:10 [PATCH v3] ARM64: kernel: implement ACPI parking protocol Lorenzo Pieralisi
2016-01-26 17:47 ` Lorenzo Pieralisi
2016-01-27 10:23 ` Ard Biesheuvel
2016-01-27 11:46 ` Lorenzo Pieralisi
2016-01-26 23:13 ` Loc Ho
2016-01-27 11:51 ` Lorenzo Pieralisi
2016-01-27 17:41 ` Loc Ho
2016-02-02 18:26 ` Catalin Marinas
2016-02-03 11:21 ` Lorenzo Pieralisi
2016-02-03 16:18 ` Catalin Marinas [this message]
2016-02-24 14:18 ` Lorenzo Pieralisi
2016-02-24 15:03 ` Lorenzo Pieralisi
2016-02-24 23:28 ` Itaru Kitayama
2016-02-25 9:24 ` Lorenzo Pieralisi
2016-02-25 20:58 ` Loc Ho
2016-02-26 0:23 ` Itaru Kitayama
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=20160203161834.GB26487@MBP.local \
--to=catalin.marinas@arm.com \
--cc=ahs3@redhat.com \
--cc=hanjun.guo@linaro.org \
--cc=lho@apm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=msalter@redhat.com \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox