LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "André Przywara" <andre.przywara@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: Peng Fan <peng.fan@nxp.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"jassisinghbrar@gmail.com" <jassisinghbrar@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"van.freenix@gmail.com" <van.freenix@gmail.com>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
Date: Mon, 27 May 2019 00:59:23 +0100	[thread overview]
Message-ID: <d0800650-b79b-4698-3a3e-60e83c85f2d1@arm.com> (raw)
In-Reply-To: <20190524175658.GA5045@e107155-lin>

On 24/05/2019 18:56, Sudeep Holla wrote:
> On Thu, May 23, 2019 at 10:30:50AM -0700, Florian Fainelli wrote:

Hi,

>> On 5/22/19 10:50 PM, Peng Fan wrote:
>>> This is a modified version from Andre Przywara's patch series
>>> https://lore.kernel.org/patchwork/cover/812997/.
>>> [1] is a draft implementation of i.MX8MM SCMI ATF implementation that
>>> use smc as mailbox, power/clk is included, but only part of clk has been
>>> implemented to work with hardware, power domain only supports get name
>>> for now.
>>>
>>> The traditional Linux mailbox mechanism uses some kind of dedicated hardware
>>> IP to signal a condition to some other processing unit, typically a dedicated
>>> management processor.
>>> This mailbox feature is used for instance by the SCMI protocol to signal a
>>> request for some action to be taken by the management processor.
>>> However some SoCs does not have a dedicated management core to provide
>>> those services. In order to service TEE and to avoid linux shutdown
>>> power and clock that used by TEE, need let firmware to handle power
>>> and clock, the firmware here is ARM Trusted Firmware that could also
>>> run SCMI service.
>>>
>>> The existing SCMI implementation uses a rather flexible shared memory
>>> region to communicate commands and their parameters, it still requires a
>>> mailbox to actually trigger the action.
>>
>> We have had something similar done internally with a couple of minor
>> differences:
>>
>> - a SGI is used to send SCMI notifications/delayed replies to support
>> asynchronism (patches are in the works to actually add that to the Linux
>> SCMI framework). There is no good support for SGI in the kernel right
>> now so we hacked up something from the existing SMP code and adding the
>> ability to register our own IPI handlers (SHAME!). Using a PPI should
>> work and should allow for using request_irq() AFAICT.
>>
> 
> We have been thinking this since we were asked if SMC can be transport.
> Generally out of 16 SGIs, 8 are reserved for secure side and non-secure
> has 8. Of these 8, IIUC 7 is already being used by kernel. So unless we
> manage to get the last one reserved exclusive to SCMI, it makes it
> difficult to add SGI support in SCMI.
> 
> We have been telling partners/vendors about this limitation if they
> use SMC as transport and need to have dedicated h/w interrupt for the
> notifications.
> 
> Another issue could be with virtualisation(using HVC) and EL handling
> so called SCMI SGI. We need to think about those too. I will try to get
> more info on this and come back on this.

I think regardless of the *current* feasibility of using SGIs in *Linux*
we should at least specify an "interrupts" property in the binding, to
allow for future usage. We might copy the pmuv3 way [1] of allowing to
specify multiple SPI interrupts as well, to give more flexibility.
After all an implementation could offload the asynchronous notification
to a separate core, and that could use SPIs, for instance.

Cheers,
Andre.

[1] Documentation/devicetree/bindings/arm/pmu.yaml:45

  reply	other threads:[~2019-05-26 23:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23  5:50 Peng Fan
2019-05-23  5:50 ` [PATCH 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox Peng Fan
2019-05-23  5:51 ` [PATCH 2/2] mailbox: introduce ARM SMC based mailbox Peng Fan
2019-05-23 17:30 ` [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox Florian Fainelli
2019-05-24 17:56   ` Sudeep Holla
2019-05-26 23:59     ` André Przywara [this message]
2019-05-27  6:29       ` Peng Fan
2019-05-27  6:18     ` Peng Fan
2019-05-27  5:19   ` Peng Fan
2019-05-27 19:11     ` Florian Fainelli
2019-05-30 11:23     ` Andre Przywara
2019-05-31  1:39       ` Peng Fan
2019-06-03 17:24         ` Andre Przywara
2019-05-27  1:55 ` Jassi Brar
2019-05-27  2:06   ` Peng Fan

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=d0800650-b79b-4698-3a3e-60e83c85f2d1@arm.com \
    --to=andre.przywara@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=festevam@gmail.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peng.fan@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=van.freenix@gmail.com \
    --subject='Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).