RE: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux