| Message ID | 1582701171-26842-1-git-send-email-peng.fan@nxp.com |
|---|---|
| Headers | show |
| Series | firmware: arm_scmi: add smc/hvc transports support | expand |
On Wed, Feb 26, 2020 at 03:12:51PM +0800, peng.fan@nxp.com wrote: > From: Peng Fan <peng.fan@nxp.com> > > Take arm,smc-id as the 1st arg, and protocol id as the 2nd arg when > issuing SMC/HVC. Since we need protocol id, so add this parameter And why do we need protocol id here ? I couldn't find it out myself. I would like to know why/what/how is it used in the firmware(smc/hvc handler). I hope you are not mixing the need for multiple channel with protocol id ? One can find out id from the command itself, no need to pass it and hence asking here for more details.
Hi Sudeep, > Subject: Re: [PATCH V3 2/2] firmware: arm_scmi: add smc/hvc transport > > On Wed, Feb 26, 2020 at 03:12:51PM +0800, peng.fan@nxp.com wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > Take arm,smc-id as the 1st arg, and protocol id as the 2nd arg when > > issuing SMC/HVC. Since we need protocol id, so add this parameter > > And why do we need protocol id here ? I couldn't find it out myself. > I would like to know why/what/how is it used in the firmware(smc/hvc > handler). I hope you are not mixing the need for multiple channel with > protocol id ? One can find out id from the command itself, no need to pass it > and hence asking here for more details. When each protocol needs its own shmem area, we need let firmware know which shmem area to parse the message from. Without protocol id, firmware not know which shmem area should use. Hope this is clear. Thanks, Peng. > > -- > Regards, > Sudeep
On Sat, Feb 29, 2020 at 02:07:30AM +0000, Peng Fan wrote: > Hi Sudeep, > > > Subject: Re: [PATCH V3 2/2] firmware: arm_scmi: add smc/hvc transport > > > > On Wed, Feb 26, 2020 at 03:12:51PM +0800, peng.fan@nxp.com wrote: > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > Take arm,smc-id as the 1st arg, and protocol id as the 2nd arg when > > > issuing SMC/HVC. Since we need protocol id, so add this parameter > > > > And why do we need protocol id here ? I couldn't find it out myself. > > I would like to know why/what/how is it used in the firmware(smc/hvc > > handler). I hope you are not mixing the need for multiple channel with > > protocol id ? One can find out id from the command itself, no need to pass it > > and hence asking here for more details. > > When each protocol needs its own shmem area, we need let firmware > know which shmem area to parse the message from. Without protocol > id, firmware not know which shmem area should use. Hope this is clear. > Not all platforms need to have a separate shmem for each protocol. Make it it separate transport. -- Regards, Sudeep
> Subject: Re: [PATCH V3 2/2] firmware: arm_scmi: add smc/hvc transport > > On Sat, Feb 29, 2020 at 02:07:30AM +0000, Peng Fan wrote: > > Hi Sudeep, > > > > > Subject: Re: [PATCH V3 2/2] firmware: arm_scmi: add smc/hvc > > > transport > > > > > > On Wed, Feb 26, 2020 at 03:12:51PM +0800, peng.fan@nxp.com wrote: > > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > > > Take arm,smc-id as the 1st arg, and protocol id as the 2nd arg > > > > when issuing SMC/HVC. Since we need protocol id, so add this > > > > parameter > > > > > > And why do we need protocol id here ? I couldn't find it out myself. > > > I would like to know why/what/how is it used in the firmware(smc/hvc > > > handler). I hope you are not mixing the need for multiple channel > > > with protocol id ? One can find out id from the command itself, no > > > need to pass it and hence asking here for more details. > > > > When each protocol needs its own shmem area, we need let firmware know > > which shmem area to parse the message from. Without protocol id, > > firmware not know which shmem area should use. Hope this is clear. > > > > Not all platforms need to have a separate shmem for each protocol. Make it it > separate transport. I added that in case somebody needs it, but actually my platform not need it. I'll remove the protocol id change in v4. If others need it in future, they could add then. Thanks, Peng. > > -- > Regards, > Sudeep > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%7C01 > %7Cpeng.fan%40nxp.com%7Ca9c9201db90749d46cfd08d7be9be1a2%7C686 > ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637187449022127405&a > mp;sdata=mwxo5a%2F4jW5ram7%2BRyHpjJ6N9ngPn5SoT4L4uq1tJ44%3D&a > mp;reserved=0
From: Peng Fan <peng.fan@nxp.com> V3: Add back arm,scmi-smc compatible string Change smc-id to arm,smc-id Directly use arm_smccc_1_1_invoke Add prot_id in scmi_chan_info for per protocol shmem usage. V2: patch 1/2: only add smc-id property patch 2/2: Parse smc/hvc from psci node Use prot_id as 2nd arg when issue smc/hvc Differentiate tranports using mboxes or smc-id property https://lore.kernel.org/patchwork/cover/1193435/ This is to add smc/hvc transports support, based on Viresh's v6. SCMI firmware could be implemented in EL3, S-EL1, NS-EL2 or other A core exception level. Then smc/hvc could be used. And for vendor specific firmware, a wrapper layer could added in EL3, S-EL1, NS-EL2 and etc to translate SCMI calls to vendor specific firmware calls. A new compatible string arm,scmi-smc is added. arm,scmi is still for mailbox transports. All protocol share same smc/hvc id, the protocol id will be take as 2nd arg when issue smc/hvc. Each protocol could use its own shmem or share the same shmem Per smc/hvc, only Tx supported. Peng Fan (2): dt-bindings: arm: arm,scmi: add smc/hvc transport firmware: arm_scmi: add smc/hvc transport Documentation/devicetree/bindings/arm/arm,scmi.txt | 3 +- drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/common.h | 3 + drivers/firmware/arm_scmi/driver.c | 2 + drivers/firmware/arm_scmi/smc.c | 146 +++++++++++++++++++++ 5 files changed, 154 insertions(+), 2 deletions(-) create mode 100644 drivers/firmware/arm_scmi/smc.c