From: Florian Fainelli <f.fainelli@gmail.com>
To: Peng Fan <peng.fan@nxp.com>, Jassi Brar <jassisinghbrar@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>, ",
Sascha Hauer" <kernel@pengutronix.de>,
dl-linux-imx <linux-imx@nxp.com>, Shawn Guo <shawnguo@kernel.org>,
"festevam@gmail.com" <festevam@gmail.com>,
Devicetree List <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Andre Przywara <andre.przywara@arm.com>,
"van.freenix@gmail.com" <van.freenix@gmail.com>
Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Date: Wed, 26 Jun 2019 09:44:06 -0700 [thread overview]
Message-ID: <e49278ba-f734-e019-ab44-53afe558bd85@gmail.com> (raw)
In-Reply-To: <AM0PR04MB44814D3BD59033ECDDE3094C88E20@AM0PR04MB4481.eurprd04.prod.outlook.com>
On 6/26/19 6:31 AM, Peng Fan wrote:
>>> The firmware driver might not have func-id, such as SCMI/SCPI.
>>> So add an optional func-id to let smc mailbox driver could
>>> use smc SiP func id.
>>>
>> There is no end to conforming to protocols. Controller drivers should
>> be written having no particular client in mind.
>
> If the func-id needs be passed from user, then the chan_id suggested
> by Sudeep should also be passed from user, not in mailbox driver.
>
> Jassi, so from your point, arm_smc_send_data just send a0 - a6
> to firmware, right?
>
> Sudeep, Andre, Florian,
>
> What's your suggestion? SCMI not support, do you have
> plan to add smc transport in SCMI?
On the platforms that I work with, we have taken the liberty of
implementing SCMI in our monitor firmware because the other MCU we use
for dynamic voltage and frequency scaling did not have enough memory to
support that and we still had the ability to make that firmware be
trusted enough we could give it power management responsibilities. I
would certainly feel more comfortable if the SCMI specification was
amended to indicate that the Agent could be such a software entity,
still residing on the same host CPU as the Platform(s), but if not,
that's fine.
This has lead us to implement a mailbox driver that uses a proprietary
SMC call for the P2A path ("tx" channel) and the return being done via
either that same SMC or through SGI. You can take a look at it in our
downstream tree here actually:
https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/mailbox/brcmstb-mailbox.c
If we can get rid of our own driver and uses a standard SMC based
mailbox driver that supports our use case that involves interrupts (we
can always change their kind without our firmware/boot loader since FDT
is generated from that component), that would be great.
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Peng Fan <peng.fan@nxp.com>, Jassi Brar <jassisinghbrar@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Devicetree List <devicetree@vger.kernel.org>,
"festevam@gmail.com" <festevam@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andre Przywara <andre.przywara@arm.com>,
Rob Herring <robh+dt@kernel.org>,
dl-linux-imx <linux-imx@nxp.com>, ",
Sascha Hauer" <kernel@pengutronix.de>,
Sudeep Holla <sudeep.holla@arm.com>,
"van.freenix@gmail.com" <van.freenix@gmail.com>,
Shawn Guo <shawnguo@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Date: Wed, 26 Jun 2019 09:44:06 -0700 [thread overview]
Message-ID: <e49278ba-f734-e019-ab44-53afe558bd85@gmail.com> (raw)
In-Reply-To: <AM0PR04MB44814D3BD59033ECDDE3094C88E20@AM0PR04MB4481.eurprd04.prod.outlook.com>
On 6/26/19 6:31 AM, Peng Fan wrote:
>>> The firmware driver might not have func-id, such as SCMI/SCPI.
>>> So add an optional func-id to let smc mailbox driver could
>>> use smc SiP func id.
>>>
>> There is no end to conforming to protocols. Controller drivers should
>> be written having no particular client in mind.
>
> If the func-id needs be passed from user, then the chan_id suggested
> by Sudeep should also be passed from user, not in mailbox driver.
>
> Jassi, so from your point, arm_smc_send_data just send a0 - a6
> to firmware, right?
>
> Sudeep, Andre, Florian,
>
> What's your suggestion? SCMI not support, do you have
> plan to add smc transport in SCMI?
On the platforms that I work with, we have taken the liberty of
implementing SCMI in our monitor firmware because the other MCU we use
for dynamic voltage and frequency scaling did not have enough memory to
support that and we still had the ability to make that firmware be
trusted enough we could give it power management responsibilities. I
would certainly feel more comfortable if the SCMI specification was
amended to indicate that the Agent could be such a software entity,
still residing on the same host CPU as the Platform(s), but if not,
that's fine.
This has lead us to implement a mailbox driver that uses a proprietary
SMC call for the P2A path ("tx" channel) and the return being done via
either that same SMC or through SGI. You can take a look at it in our
downstream tree here actually:
https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/mailbox/brcmstb-mailbox.c
If we can get rid of our own driver and uses a standard SMC based
mailbox driver that supports our use case that involves interrupts (we
can always change their kind without our firmware/boot loader since FDT
is generated from that component), that would be great.
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Peng Fan <peng.fan@nxp.com>, Jassi Brar <jassisinghbrar@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Devicetree List <devicetree@vger.kernel.org>,
"festevam@gmail.com" <festevam@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andre Przywara <andre.przywara@arm.com>,
Rob Herring <robh+dt@kernel.org>,
dl-linux-imx <linux-imx@nxp.com>, ",
Sascha Hauer" <kernel@pengutronix.de>,
Sudeep Holla <sudeep.holla@arm.com>,
"van.freenix@gmail.com" <van.freenix@gmail.com>,
Shawn Guo <shawnguo@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Date: Wed, 26 Jun 2019 09:44:06 -0700 [thread overview]
Message-ID: <e49278ba-f734-e019-ab44-53afe558bd85@gmail.com> (raw)
In-Reply-To: <AM0PR04MB44814D3BD59033ECDDE3094C88E20@AM0PR04MB4481.eurprd04.prod.outlook.com>
On 6/26/19 6:31 AM, Peng Fan wrote:
>>> The firmware driver might not have func-id, such as SCMI/SCPI.
>>> So add an optional func-id to let smc mailbox driver could
>>> use smc SiP func id.
>>>
>> There is no end to conforming to protocols. Controller drivers should
>> be written having no particular client in mind.
>
> If the func-id needs be passed from user, then the chan_id suggested
> by Sudeep should also be passed from user, not in mailbox driver.
>
> Jassi, so from your point, arm_smc_send_data just send a0 - a6
> to firmware, right?
>
> Sudeep, Andre, Florian,
>
> What's your suggestion? SCMI not support, do you have
> plan to add smc transport in SCMI?
On the platforms that I work with, we have taken the liberty of
implementing SCMI in our monitor firmware because the other MCU we use
for dynamic voltage and frequency scaling did not have enough memory to
support that and we still had the ability to make that firmware be
trusted enough we could give it power management responsibilities. I
would certainly feel more comfortable if the SCMI specification was
amended to indicate that the Agent could be such a software entity,
still residing on the same host CPU as the Platform(s), but if not,
that's fine.
This has lead us to implement a mailbox driver that uses a proprietary
SMC call for the P2A path ("tx" channel) and the return being done via
either that same SMC or through SGI. You can take a look at it in our
downstream tree here actually:
https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/mailbox/brcmstb-mailbox.c
If we can get rid of our own driver and uses a standard SMC based
mailbox driver that supports our use case that involves interrupts (we
can always change their kind without our firmware/boot loader since FDT
is generated from that component), that would be great.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-26 16:44 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 8:30 [PATCH V2 0/2] mailbox: arm: introduce smc triggered mailbox peng.fan
2019-06-03 8:30 ` peng.fan
2019-06-03 8:30 ` [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox peng.fan
2019-06-03 8:30 ` peng.fan
2019-06-03 16:22 ` Florian Fainelli
2019-06-03 16:22 ` Florian Fainelli
2019-06-03 16:56 ` Sudeep Holla
2019-06-03 16:56 ` Sudeep Holla
2019-06-03 17:18 ` Andre Przywara
2019-06-03 17:18 ` Andre Przywara
2019-06-03 17:18 ` Andre Przywara
2019-06-06 2:51 ` Florian Fainelli
2019-06-06 2:51 ` Florian Fainelli
2019-06-06 3:24 ` Peng Fan
2019-06-06 3:24 ` Peng Fan
2019-06-06 3:24 ` Peng Fan
2019-06-20 9:22 ` Sudeep Holla
2019-06-20 9:22 ` Sudeep Holla
2019-06-20 16:13 ` Andre Przywara
2019-06-20 16:13 ` Andre Przywara
2019-06-20 16:13 ` Andre Przywara
2019-06-20 16:27 ` Jassi Brar
2019-06-20 16:27 ` Jassi Brar
2019-07-08 22:19 ` Rob Herring
2019-07-08 22:19 ` Rob Herring
2019-07-09 1:40 ` Peng Fan
2019-07-09 1:40 ` Peng Fan
2019-07-09 1:40 ` Peng Fan
2019-07-09 13:31 ` Rob Herring
2019-07-09 13:31 ` Rob Herring
2019-07-09 13:31 ` Rob Herring
2019-06-03 8:30 ` [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox peng.fan
2019-06-03 8:30 ` peng.fan
2019-06-03 16:32 ` Florian Fainelli
2019-06-03 16:32 ` Florian Fainelli
2019-06-06 3:35 ` Peng Fan
2019-06-06 3:35 ` Peng Fan
2019-06-06 3:35 ` Peng Fan
2019-06-06 13:20 ` Andre Przywara
2019-06-06 13:20 ` Andre Przywara
2019-06-10 1:32 ` Peng Fan
2019-06-10 1:32 ` Peng Fan
2019-06-10 1:32 ` Peng Fan
2019-06-10 10:00 ` Andre Przywara
2019-06-10 10:00 ` Andre Przywara
2019-06-10 10:00 ` Andre Przywara
2019-06-12 12:59 ` Peng Fan
2019-06-12 12:59 ` Peng Fan
2019-06-12 12:59 ` Peng Fan
2019-06-12 17:18 ` Andre Przywara
2019-06-12 17:18 ` Andre Przywara
2019-06-12 17:18 ` Andre Przywara
2019-06-20 9:23 ` Sudeep Holla
2019-06-20 9:23 ` Sudeep Holla
2019-06-20 10:21 ` Peng Fan
2019-06-20 10:21 ` Peng Fan
2019-06-20 10:21 ` Peng Fan
2019-06-20 11:15 ` Sudeep Holla
2019-06-20 11:15 ` Sudeep Holla
2019-06-20 11:15 ` Sudeep Holla
2019-06-25 7:28 ` Peng Fan
2019-06-25 7:28 ` Peng Fan
2019-06-25 7:28 ` Peng Fan
2019-06-20 16:50 ` Jassi Brar
2019-06-20 16:50 ` Jassi Brar
2019-06-25 7:20 ` Peng Fan
2019-06-25 7:20 ` Peng Fan
2019-06-26 17:05 ` André Przywara
2019-06-26 17:05 ` André Przywara
2019-06-26 17:05 ` André Przywara
2019-06-26 17:07 ` Florian Fainelli
2019-06-26 17:07 ` Florian Fainelli
2019-06-26 17:07 ` Florian Fainelli
2019-06-25 7:30 ` Peng Fan
2019-06-25 7:30 ` Peng Fan
2019-06-25 7:30 ` Peng Fan
2019-06-25 14:36 ` Jassi Brar
2019-06-25 14:36 ` Jassi Brar
2019-06-25 14:36 ` Jassi Brar
2019-06-26 13:31 ` Peng Fan
2019-06-26 13:31 ` Peng Fan
2019-06-26 13:31 ` Peng Fan
2019-06-26 16:31 ` Jassi Brar
2019-06-26 16:31 ` Jassi Brar
2019-06-26 16:31 ` Jassi Brar
2019-06-26 16:44 ` Florian Fainelli [this message]
2019-06-26 16:44 ` Florian Fainelli
2019-06-26 16:44 ` Florian Fainelli
2019-06-26 17:09 ` Sudeep Holla
2019-06-26 17:09 ` Sudeep Holla
2019-06-26 17:09 ` Sudeep Holla
2019-06-27 18:10 ` Florian Fainelli
2019-06-27 18:10 ` Florian Fainelli
2019-06-27 18:10 ` Florian Fainelli
2019-06-26 18:27 ` Jassi Brar
2019-06-26 18:27 ` Jassi Brar
2019-06-26 18:27 ` Jassi Brar
2019-06-27 9:09 ` Sudeep Holla
2019-06-27 9:09 ` Sudeep Holla
2019-06-27 9:09 ` Sudeep Holla
2019-06-27 15:32 ` Jassi Brar
2019-06-27 15:32 ` Jassi Brar
2019-06-27 15:32 ` Jassi Brar
2019-06-27 17:07 ` Sudeep Holla
2019-06-27 17:07 ` Sudeep Holla
2019-06-27 17:07 ` Sudeep Holla
2019-06-26 17:02 ` Sudeep Holla
2019-06-26 17:02 ` Sudeep Holla
2019-06-26 17:02 ` Sudeep Holla
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=e49278ba-f734-e019-ab44-53afe558bd85@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andre.przywara@arm.com \
--cc=devicetree@vger.kernel.org \
--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 \
/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.