LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peng Fan <peng.fan@nxp.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"jassisinghbrar@gmail.com" <jassisinghbrar@gmail.com>,
	"sudeep.holla@arm.com" <sudeep.holla@arm.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: Fri, 31 May 2019 01:39:45 +0000	[thread overview]
Message-ID: <AM0PR04MB4481C97696C68ECF5E6D4A7988190@AM0PR04MB4481.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20190530122329.235d13c7@donnerap.cambridge.arm.com>


> 
> > > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered
> > > mailbox
> > >
> > > Hi,
> > >
> > > On 5/22/19 10:50 PM, Peng Fan wrote:
> > > > This is a modified version from Andre Przywara's patch series
> > > >
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > > re.ke
> rnel.org%2Fpatchwork%2Fcover%2F812997%2F&amp;data=02%7C01%7Cpe
> > >
> ng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1d3b
> > >
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&amp;sdat
> > >
> a=BbS5ZQtzMANSwaKRDJ62NKrPrAyaED1%2BvymQaT6Qr8E%3D&amp;rese
> > > rved=0.
> > > > [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.
> >
> > So you are also implementing a firmware inside ATF for SCMI usecase, right?
> >
> > Introducing SGI in ATF to notify Linux will introduce complexity,
> > there is no good framework inside ATF for SCMI, and I use
> > synchronization call for simplicity for now.
> 
> I think we don't disagree, but just to clarify on one thing:
> 
> I think we should avoid tying this driver to specific protocol or software on the
> other end, be it ATF or SCMI. After all it's just a mailbox driver, meant to signal
> some event (and parameters) to some external entity. Yes, SCMI (or SCPI back
> then) was the reason to push for this, but it should be independent from that.

Thanks, I agree.

> I am not even sure we should mention it too much in the documentation.

I think we need a usecase here, so it should be fine.

> 
> So whether the receiving end is ATF or something else it irrelevant, I think. For
> instance we have had discussions in Xen to provide guests some virtualised
> device management support, and using an HVC mailbox seems like a neat
> solution. This could be using the SCMI (or SCPI) protocol, but that's not a
> requirement. In this case the Xen hypervisor would be the one to pick up the
> mailbox trigger, probably forwarding the request to something else (Dom0 in
> this case).

I do not get the point "forwarding the request", DomU HVC will trap to Xen,
so how to forward to Dom0?

Thanks,
Peng.

> Also having a generic SMC mailbox could avoid having the actual hardware
> mailbox drivers in the kernel, so EL3 firmware could forward the request to an
> external management processor, and Linux would just work, without the need
> to describe the actual hardware mailbox device in some firmware tables. This
> might help ACPI on those devices.
> 
> Cheers,
> Andre.
> 
> > >
> > > - the mailbox identifier is indicated as part of the SMC call such
> > > that we can have multiple SCMI mailboxes serving both standard
> > > protocols and non-standard (in the 0x80 and above) range, also they
> > > may have different throughput (in hindsight, these could simply be
> > > different channels)
> > >
> > > Your patch series looks both good and useful to me, I would just put
> > > a provision in the binding to support an optional interrupt such
> > > that asynchronism gets reasonably easy to plug in when it is
> > > available (and desirable).
> >
> > Ok. Let me think about and add that in new version patch.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > >
> > > > This patch series provides a Linux mailbox compatible service
> > > > which uses smc calls to invoke firmware code, for instance taking
> > > > care of SCMI
> > > requests.
> > > > The actual requests are still communicated using the standard SCMI
> > > > way of shared memory regions, but a dedicated mailbox hardware IP
> > > > can be replaced via this new driver.
> > > >
> > > > This simple driver uses the architected SMC calling convention to
> > > > trigger firmware services, also allows for using "HVC" calls to
> > > > call into hypervisors or firmware layers running in the EL2 exception
> level.
> > > >
> > > > Patch 1 contains the device tree binding documentation, patch 2
> > > > introduces the actual mailbox driver.
> > > >
> > > > Please note that this driver just provides a generic mailbox
> > > > mechanism, though this is synchronous and one-way only (triggered
> > > > by the OS only, without providing an asynchronous way of
> > > > triggering request from the firmware).
> > > > And while providing SCMI services was the reason for this
> > > > exercise, this driver is in no way bound to this use case, but can
> > > > be used generically where the OS wants to signal a mailbox
> > > > condition to firmware or a hypervisor.
> > > > Also the driver is in no way meant to replace any existing
> > > > firmware interface, but actually to complement existing interfaces.
> > > >
> > > > [1]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > gith
> > > >
> > >
> ub.com%2FMrVan%2Farm-trusted-firmware%2Ftree%2Fscmi&amp;data=02
> > > %7C01%7
> > > >
> > >
> Cpeng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1
> > > d3bc2b4
> > > >
> > >
> c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&amp;sdata=kN
> > > 9bEFFcsZA
> > > > 1ePeNLLfHmONpVaG6O5ajVQvKMuaBXyk%3D&amp;reserved=0
> > > >
> > > > Peng Fan (2):
> > > >   DT: mailbox: add binding doc for the ARM SMC mailbox
> > > >   mailbox: introduce ARM SMC based mailbox
> > > >
> > > >  .../devicetree/bindings/mailbox/arm-smc.txt        |  96
> > > +++++++++++++
> > > >  drivers/mailbox/Kconfig                            |   7 +
> > > >  drivers/mailbox/Makefile                           |   2 +
> > > >  drivers/mailbox/arm-smc-mailbox.c                  | 154
> > > +++++++++++++++++++++
> > > >  include/linux/mailbox/arm-smc-mailbox.h            |  10 ++
> > > >  5 files changed, 269 insertions(+)  create mode 100644
> > > > Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > > >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create
> mode
> > > > 100644 include/linux/mailbox/arm-smc-mailbox.h
> > > >
> > >
> > >
> > > --
> > > Florian


  reply	other threads:[~2019-05-31  1:39 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
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 [this message]
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=AM0PR04MB4481C97696C68ECF5E6D4A7988190@AM0PR04MB4481.eurprd04.prod.outlook.com \
    --to=peng.fan@nxp.com \
    --cc=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=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).