From: Ang, Chee Hong <chee.hong.ang@intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
Date: Tue, 23 Apr 2019 05:51:50 +0000 [thread overview]
Message-ID: <1555998710.44218.1.camel@intel.com> (raw)
In-Reply-To: <20190313160136.GG8732@bill-the-cat>
On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 08:10:31AM +0000, Ang, Chee Hong wrote:
> >
> > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > >
> > > On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > > >
> > > > >
> > > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel
> > > > > .com
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > >
> > > > > > Currently u-boot only support standard PSCI functions for
> > > > > > power
> > > > > > management
> > > > > > and lack of convenient method to allow the users to extend
> > > > > > the
> > > > > > PSCI
> > > > > > functions
> > > > > > to support platform specific services. Most of the u-boot
> > > > > > users
> > > > > > still rely
> > > > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > > > management and
> > > > > > platform specific PSCI services.
> > > > > > The purpose of this patchsets is to allow u-boot users to
> > > > > > support
> > > > > > their
> > > > > > own platform specific secure SMC/PSCI services without
> > > > > > making
> > > > > > any
> > > > > > SMC calls to ATF. This will benefit the users who need to
> > > > > > use
> > > > > > u-
> > > > > > boot as the
> > > > > > only bootloader and secure service provider without relying
> > > > > > on
> > > > > > ATF.
> > > > > >
> > > > > > Below is a simple code example for adding your own PSCI
> > > > > > functions:
> > > > > >
> > > > > > #include <common.h>
> > > > > > #include <errno.h>
> > > > > > #include <asm/io.h>
> > > > > > #include <asm/psci.h>
> > > > > > #include <asm/secure.h>
> > > > > >
> > > > > > #define PSCI_SMC64_FUNC_ID1 0xC2000001
> > > > > > #define PSCI_SMC64_FUNC_ID2 0xC2000002
> > > > > >
> > > > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > /* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 1 */
> > > > > > }
> > > > > >
> > > > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > /* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 2 */
> > > > > > }
> > > > > >
> > > > > > DECLARE_SECURE_SVC(plat_specific_func1,
> > > > > > PSCI_SMC64_FUNC_ID1,
> > > > > > psci_plat_specific_func1);
> > > > > > DECLARE_SECURE_SVC(plat_specific_func2,
> > > > > > PSCI_SMC64_FUNC_ID2,
> > > > > > psci_plat_specific_func2);
> > > > > >
> > > > > > Ang, Chee Hong (1):
> > > > > > ARMv8: Disable fwcall when PSCI is enabled
> > > > > >
> > > > > > Chee Hong Ang (1):
> > > > > > ARMv8: Allow SiP service extensions on top of PSCI code
> > > > > Conceptually, I suppose this is a logical step. In
> > > > > specifics,
> > > > > would
> > > > > we
> > > > > want to make this functionality opt-in, or no, that doesn't
> > > > > make
> > > > > sense?
> > > > >
> > > > Allowing user to add platform specific service is part of
> > > > SMC/PSCI
> > > > specification as specifed in ARM document (Table 2-1):
> > > > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_D
> > > > EN00
> > > > 28B_
> > > > SMC_Calling_Convention.pdf
> > > >
> > > > So I think this functionality should be part of the standard
> > > > PSCI/SMC
> > > > implementation. Currently u-boot only support standard PSCI
> > > > call
> > > > which
> > > > is:
> > > > ----------------------------------------------
> > > > >
> > > > >
> > > > > 0x84000000-0x8400001F | PSCI 32-bit calls |
> > > > > 0xC4000000-0xC400001F | PSCI 64-bit calls |
> > > > ----------------------------------------------
> > > >
> > > > My implementation do not affect or alter the behavior of any
> > > > existing
> > > > standard PSCI calls.
> > > >
> > > > Users can simply add their own platform specific services by
> > > > using
> > > > the
> > > > service call range as below:
> > > > ----------------------------------------------------
> > > > >
> > > > >
> > > > > 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls |
> > > > > 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
> > > > ----------------------------------------------------
> > > >
> > > > For complete service call ranges please refer to Table 6-2 in
> > > > the
> > > > ARM
> > > > document.
> > > OK, thanks!
> > >
> > Any chance this enhancement get accepted ? Thanks.
> After the current release, if there's no further comments.
>
Hi Tom,
Is this patch being merged into mainline ? Or you have any further
concern or comments ? Thanks.
prev parent reply other threads:[~2019-04-23 5:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 8:27 [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI chee.hong.ang at intel.com
2019-02-12 8:27 ` [U-Boot] [PATCH v1 1/2] ARMv8: Allow SiP service extensions on top of PSCI code chee.hong.ang at intel.com
2019-04-24 13:22 ` [U-Boot] [U-Boot, v1, " Tom Rini
2019-02-12 8:27 ` [U-Boot] [PATCH v1 2/2] ARMv8: Disable fwcall when PSCI is enabled chee.hong.ang at intel.com
2019-04-24 13:22 ` [U-Boot] [U-Boot, v1, " Tom Rini
2019-02-14 8:53 ` [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI Ang, Chee Hong
2019-03-05 7:18 ` Ang, Chee Hong
2019-03-08 18:09 ` Tom Rini
2019-03-11 15:27 ` Ang, Chee Hong
2019-03-11 19:48 ` Tom Rini
2019-03-13 8:10 ` Ang, Chee Hong
2019-03-13 16:01 ` Tom Rini
2019-04-23 5:51 ` Ang, Chee Hong [this message]
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=1555998710.44218.1.camel@intel.com \
--to=chee.hong.ang@intel.com \
--cc=u-boot@lists.denx.de \
/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.