Commit 34dcc466 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'mailbox-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox 

Pull mailbox updates from Jassi Brar:

 - redo the omap driver from legacy to mailbox api

 - enable bufferless IPI for zynqmp

 - add mhu-v3 driver

 - convert from tasklet to BH workqueue

 - add qcom MSM8974 APCS compatible IDs

* tag 'mailbox-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: (24 commits)
  dt-bindings: mailbox: qcom-ipcc: Document the SDX75 IPCC
  dt-bindings: mailbox: qcom: Add MSM8974 APCS compatible
  mailbox: Convert from tasklet to BH workqueue
  mailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdown
  mailbox: mtk-cmdq-mailbox: fix module autoloading
  mailbox: zynqmp: handle SGI for shared IPI
  mailbox: arm_mhuv3: Add driver
  dt-bindings: mailbox: arm,mhuv3: Add bindings
  mailbox: omap: Remove kernel FIFO message queuing
  mailbox: omap: Reverse FIFO busy check logic
  mailbox: omap: Remove mbox_chan_to_omap_mbox()
  mailbox: omap: Use mbox_controller channel list directly
  mailbox: omap: Use function local struct mbox_controller
  mailbox: omap: Merge mailbox child node setup loops
  mailbox: omap: Use devm_pm_runtime_enable() helper
  mailbox: omap: Remove device class
  mailbox: omap: Remove unneeded header omap-mailbox.h
  mailbox: omap: Move fifo size check to point of use
  mailbox: omap: Move omap_mbox_irq_t into driver
  mailbox: omap: Remove unused omap_mbox_request_channel() function
  ...
parents ab7b884a 10b98582

Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml

0 → 100644
+224 −0
Original line number Diff line number Diff line 
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

%YAML 1.2

---

$id: http://devicetree.org/schemas/mailbox/arm,mhuv3.yaml#

$schema: http://devicetree.org/meta-schemas/core.yaml#



title: ARM MHUv3 Mailbox Controller



maintainers:

  - Sudeep Holla <sudeep.holla@arm.com>

  - Cristian Marussi <cristian.marussi@arm.com>



description: |

  The Arm Message Handling Unit (MHU) Version 3 is a mailbox controller that

  enables unidirectional communications with remote processors through various

  possible transport protocols.

  The controller can optionally support a varying number of extensions that, in

  turn, enable different kinds of transport to be used for communication.

  Number, type and characteristics of each supported extension can be discovered

  dynamically at runtime.



  Given the unidirectional nature of the controller, an MHUv3 mailbox controller

  is composed of a MHU Sender (MHUS) containing a PostBox (PBX) block and a MHU

  Receiver (MHUR) containing a MailBox (MBX) block, where



   PBX is used to

      - Configure the MHU

      - Send Transfers to the Receiver

      - Optionally receive acknowledgment of a Transfer from the Receiver



   MBX is used to

      - Configure the MHU

      - Receive Transfers from the Sender

      - Optionally acknowledge Transfers sent by the Sender



  Both PBX and MBX need to be present and defined in the DT description if you

  need to establish a bidirectional communication, since you will have to

  acquire two distinct unidirectional channels, one for each block.



  As a consequence both blocks needs to be represented separately and specified

  as distinct DT nodes in order to properly describe their resources.



  Note that, though, thanks to the runtime discoverability, there is no need to

  identify the type of blocks with distinct compatibles.



  Following are the MHUv3 possible extensions.



  - Doorbell Extension (DBE): DBE defines a type of channel called a Doorbell

    Channel (DBCH). DBCH enables a single bit Transfer to be sent from the

    Sender to Receiver. The Transfer indicates that an event has occurred.

    When DBE is implemented, the number of DBCHs that an implementation of the

    MHU can support is between 1 and 128, numbered starting from 0 in ascending

    order and discoverable at run-time.

    Each DBCH contains 32 individual fields, referred to as flags, each of which

    can be used independently. It is possible for the Sender to send multiple

    Transfers at once using a single DBCH, so long as each Transfer uses

    a different flag in the DBCH.

    Optionally, data may be transmitted through an out-of-band shared memory

    region, wherein the MHU Doorbell is used strictly as an interrupt generation

    mechanism, but this is out of the scope of these bindings.



  - FastChannel Extension (FCE): FCE defines a type of channel called a Fast

    Channel (FCH). FCH is intended for lower overhead communication between

    Sender and Receiver at the expense of determinism. An FCH allows the Sender

    to update the channel value at any time, regardless of whether the previous

    value has been seen by the Receiver. When the Receiver reads the channel's

    content it gets the last value written to the channel.

    FCH is considered lossy in nature, and means that the Sender has no way of

    knowing if, or when, the Receiver will act on the Transfer.

    FCHs are expected to behave as RAM which generates interrupts when writes

    occur to the locations within the RAM.

    When FCE is implemented, the number of FCHs that an implementation of the

    MHU can support is between 1-1024, if the FastChannel word-size is 32-bits,

    or between 1-512, when the FastChannel word-size is 64-bits.

    FCHs are numbered from 0 in ascending order.

    Note that the number of FCHs and the word-size are implementation defined,

    not configurable but discoverable at run-time.

    Optionally, data may be transmitted through an out-of-band shared memory

    region, wherein the MHU FastChannel is used as an interrupt generation

    mechanism which carries also a pointer to such out-of-band data, but this

    is out of the scope of these bindings.



  - FIFO Extension (FE): FE defines a Channel type called a FIFO Channel (FFCH).

    FFCH allows a Sender to send

       - Multiple Transfers to the Receiver without having to wait for the

         previous Transfer to be acknowledged by the Receiver, as long as the

         FIFO has room for the Transfer.

       - Transfers which require the Receiver to provide acknowledgment.

       - Transfers which have in-band payload.

    In all cases, the data is guaranteed to be observed by the Receiver in the

    same order which the Sender sent it.

    When FE is implemented, the number of FFCHs that an implementation of the

    MHU can support is between 1 and 64, numbered starting from 0 in ascending

    order. The number of FFCHs, their depth (same for all implemented FFCHs) and

    the access-granularity are implementation defined, not configurable but

    discoverable at run-time.

    Optionally, additional data may be transmitted through an out-of-band shared

    memory region, wherein the MHU FIFO is used to transmit, in order, a small

    part of the payload (like a header) and a reference to the shared memory

    area holding the remaining, bigger, chunk of the payload, but this is out of

    the scope of these bindings.



properties:

  compatible:

    const: arm,mhuv3



  reg:

    maxItems: 1



  interrupts:

    minItems: 1

    maxItems: 74



  interrupt-names:

    description: |

      The MHUv3 controller generates a number of events some of which are used

      to generate interrupts; as a consequence it can expose a varying number of

      optional PBX/MBX interrupts, representing the events generated during the

      operation of the various transport protocols associated with different

      extensions. All interrupts of the MHU are level-sensitive.

      Some of these optional interrupts are defined per-channel, where the

      number of channels effectively available is implementation defined and

      run-time discoverable.

      In the following names are enumerated using patterns, with per-channel

      interrupts implicitly capped at the maximum channels allowed by the

      specification for each extension type.

      For the sake of simplicity maxItems is anyway capped to a most plausible

      number, assuming way less channels would be implemented than actually

      possible.



      The only mandatory interrupts on the MHU are:

        - combined

        - mbx-fch-xfer-<N> but only if mbx-fcgrp-xfer-<N> is not implemented.



    minItems: 1

    maxItems: 74

    items:

      oneOf:

        - const: combined

          description: PBX/MBX Combined interrupt

        - const: combined-ffch

          description: PBX/MBX FIFO Combined interrupt

        - pattern: '^ffch-low-tide-[0-9]+$'

          description: PBX/MBX FIFO Channel <N> Low Tide interrupt

        - pattern: '^ffch-high-tide-[0-9]+$'

          description: PBX/MBX FIFO Channel <N> High Tide interrupt

        - pattern: '^ffch-flush-[0-9]+$'

          description: PBX/MBX FIFO Channel <N> Flush interrupt

        - pattern: '^mbx-dbch-xfer-[0-9]+$'

          description: MBX Doorbell Channel <N> Transfer interrupt

        - pattern: '^mbx-fch-xfer-[0-9]+$'

          description: MBX FastChannel <N> Transfer interrupt

        - pattern: '^mbx-fchgrp-xfer-[0-9]+$'

          description: MBX FastChannel <N> Group Transfer interrupt

        - pattern: '^mbx-ffch-xfer-[0-9]+$'

          description: MBX FIFO Channel <N> Transfer interrupt

        - pattern: '^pbx-dbch-xfer-ack-[0-9]+$'

          description: PBX Doorbell Channel <N> Transfer Ack interrupt

        - pattern: '^pbx-ffch-xfer-ack-[0-9]+$'

          description: PBX FIFO Channel <N> Transfer Ack interrupt



  '#mbox-cells':

    description: |

      The first argument in the consumers 'mboxes' property represents the

      extension type, the second is for the channel number while the third

      depends on extension type.



      Extension types constants are defined in <dt-bindings/arm/mhuv3-dt.h>.



      Extension type for DBE is DBE_EXT and the third parameter represents the

      doorbell flag number to use.

      Extension type for FCE is FCE_EXT, third parameter unused.

      Extension type for FE is FE_EXT, third parameter unused.



      mboxes = <&mhu DBE_EXT 0 5>; // DBE, Doorbell Channel Window 0, doorbell 5.

      mboxes = <&mhu DBE_EXT 7>; // DBE, Doorbell Channel Window 1, doorbell 7.

      mboxes = <&mhu FCE_EXT 0 0>; // FCE, FastChannel Window 0.

      mboxes = <&mhu FCE_EXT 3 0>; // FCE, FastChannel Window 3.

      mboxes = <&mhu FE_EXT 1 0>; // FE, FIFO Channel Window 1.

      mboxes = <&mhu FE_EXT 7 0>; // FE, FIFO Channel Window 7.

    const: 3



  clocks:

    maxItems: 1



required:

  - compatible

  - reg

  - interrupts

  - interrupt-names

  - '#mbox-cells'



additionalProperties: false



examples:

  - |

    #include <dt-bindings/interrupt-controller/arm-gic.h>



    soc {

        #address-cells = <2>;

        #size-cells = <2>;



        mailbox@2aaa0000 {

            compatible = "arm,mhuv3";

            #mbox-cells = <3>;

            reg = <0 0x2aaa0000 0 0x10000>;

            clocks = <&clock 0>;

            interrupt-names = "combined", "pbx-dbch-xfer-ack-1",

                               "ffch-high-tide-0";

            interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,

                         <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;

        };



        mailbox@2ab00000 {

            compatible = "arm,mhuv3";

            #mbox-cells = <3>;

            reg = <0 0x2aab0000 0 0x10000>;

            clocks = <&clock 0>;

            interrupt-names = "combined", "mbx-dbch-xfer-1", "ffch-low-tide-0";

            interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,

                         <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,

                         <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;

        };

    };

Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml

+1 −0
Original line number Diff line number Diff line
@@ -30,6 +30,7 @@ properties: 
          - const: syscon

      - items:

          - enum:

              - qcom,msm8974-apcs-kpss-global

              - qcom,msm8976-apcs-kpss-global

          - const: qcom,msm8994-apcs-kpss-global

          - const: syscon

Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml

+1 −0
Original line number Diff line number Diff line
@@ -28,6 +28,7 @@ properties: 
          - qcom,sa8775p-ipcc

          - qcom,sc7280-ipcc

          - qcom,sc8280xp-ipcc

          - qcom,sdx75-ipcc

          - qcom,sm6350-ipcc

          - qcom,sm6375-ipcc

          - qcom,sm8250-ipcc

MAINTAINERS

+9 −0
Original line number Diff line number Diff line
@@ -13195,6 +13195,15 @@ F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml 
F:	drivers/mailbox/arm_mhuv2.c

F:	include/linux/mailbox/arm_mhuv2_message.h









MAILBOX ARM MHUv3









M:	Sudeep Holla <sudeep.holla@arm.com>









M:	Cristian Marussi <cristian.marussi@arm.com>









L:	linux-kernel@vger.kernel.org









L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)









S:	Maintained









F:	Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml









F:	drivers/mailbox/arm_mhuv3.c

















MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7









M:	Alejandro Colomar <alx@kernel.org>









L:	linux-man@vger.kernel.org
































drivers/mailbox/Kconfig



+12
−9






























Original line number
Diff line number
Diff line







@@ -23,6 +23,18 @@ config ARM_MHU_V2







	  Say Y here if you want to build the ARM MHUv2 controller driver,









	  which provides unidirectional mailboxes between processing elements.



















config ARM_MHU_V3









	tristate "ARM MHUv3 Mailbox"









	depends on HAS_IOMEM || COMPILE_TEST









	depends on OF









	help









	  Say Y here if you want to build the ARM MHUv3 controller driver,









	  which provides unidirectional mailboxes between processing elements.



















	  ARM MHUv3 controllers can implement a varying number of extensions









	  that provides different means of transports: supported extensions









	  will be discovered and possibly managed at probe-time.



















config IMX_MBOX









	tristate "i.MX Mailbox"









	depends on ARCH_MXC || COMPILE_TEST








@@ -68,15 +80,6 @@ config OMAP2PLUS_MBOX







	  OMAP2/3; or IPU, IVA HD and DSP in OMAP4/5. Say Y here if you









	  want to use OMAP2+ Mailbox framework support.



















config OMAP_MBOX_KFIFO_SIZE









	int "Mailbox kfifo default buffer size (bytes)"









	depends on OMAP2PLUS_MBOX









	default 256









	help









	  Specify the default size of mailbox's kfifo buffers (bytes).









	  This can also be changed at runtime (via the mbox_kfifo_size









	  module parameter).



















config ROCKCHIP_MBOX









	bool "Rockchip Soc Integrated Mailbox Support"









	depends on ARCH_ROCKCHIP || COMPILE_TEST