Hi Jass, > Subject: RE: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox Sorry to ping again. Would you queue this patch set into your next tree for 5.5? Thanks, Peng. > > 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
