Hi Jassi, > Subject: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox Are you fine with this patch set? Thanks, Peng. > > From: Peng Fan <peng.fan@xxxxxxx> > > V10: > - Add R-b tag from Andre, Rob and Florian > - Two minor fixes > - Drop "passed from consumers" in patch 1/2 per Andre's comments > - Drop interrupts.h in patch 2/2 per Andre's comments > > V9: > - Add Florian's R-b tag in patch 1/2 > - Mark arm,func-id as a required property per Andre's comments in patch > 1/2. > - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's > comments in pach 2/2 > - Include linux/types.h in arm-smccc-mbox.h in patch 2/2 > - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT > in patch 2/2/. > > Andre, > I have marked arm,func-id as a required property and dropped > function-id > from client, please see whether you are happy with the patchset. > Hope we could finalize and get patches land in. > > Thanks, > Peng. > > V8: > Add missed arm-smccc-mbox.h > > V7: > Typo fix > #mbox-cells changed to 0 > Add a new header file arm-smccc-mbox.h > Use ARM_SMCCC_IS_64 > > Andre, > The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id > property is optional, so clients could pass function_id to mbox driver. > > V6: > Switch to per-channel a mbox controller > Drop arm,num-chans, transports, method > Add arm,hvc-mbox compatible > Fix smc/hvc args, drop client id and use correct type. > https://patchwork.kernel.org/cover/11146641/ > > V5: > yaml fix > https://patchwork.kernel.org/cover/11117741/ > > V4: > yaml fix for num-chans in patch 1/2. > https://patchwork.kernel.org/cover/11116521/ > > V3: > Drop interrupt > Introduce transports for mem/reg usage > Add chan-id for mem usage > Convert to yaml format > https://patchwork.kernel.org/cover/11043541/ > > V2: > This is a modified version from Andre Przywara's patch series > https://lore.kernel.org/patchwork/cover/812997/. > The modification are mostly: > Introduce arm,num-chans > Introduce arm_smccc_mbox_cmd > txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as > an optional property. > Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. > Introduce interrupts notification. > > [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. > > 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, It > could support synchronous TX/RX, or synchronous TX with asynchronous RX. > 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://github.com/MrVan/arm-trusted-firmware/tree/scmi > > > > Peng Fan (2): > dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox > mailbox: introduce ARM SMC based mailbox > > .../devicetree/bindings/mailbox/arm-smc.yaml | 96 > ++++++++++++ > drivers/mailbox/Kconfig | 7 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/arm-smc-mailbox.c | 166 > +++++++++++++++++++++ > include/linux/mailbox/arm-smccc-mbox.h | 20 +++ > 5 files changed, 291 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode > 100644 include/linux/mailbox/arm-smccc-mbox.h > > -- > 2.16.4
