All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 13 Mar 2019 08:10:31 +0000	[thread overview]
Message-ID: <1552464631.25816.0.camel@intel.com> (raw)
In-Reply-To: <20190311194811.GB4690@bill-the-cat>

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_DEN00
> > 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.

  reply	other threads:[~2019-03-13  8:10 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 [this message]
2019-03-13 16:01         ` Tom Rini
2019-04-23  5:51           ` Ang, Chee Hong

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=1552464631.25816.0.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.