Searched +full:sub +full:- +full:mailbox (Results 1 – 12 of 12) sorted by relevance
| /Documentation/devicetree/bindings/mailbox/ |
| D | ti,omap-mailbox.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: TI OMAP2+ and K3 Mailbox devices 10 - Suman Anna <s-anna@ti.com> 13 The OMAP Mailbox hardware facilitates communication between different 14 processors using a queued mailbox interrupt mechanism. The IP block is 19 Each mailbox IP block/cluster has a certain number of h/w fifo queues and 35 lines can also be routed to different processor sub-systems on DRA7xx as they [all …]
|
| /Documentation/devicetree/bindings/remoteproc/ |
| D | ti,omap-remoteproc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Suman Anna <s-anna@ti.com> 13 The OMAP family of SoCs usually have one or more slave processor sub-systems 14 that are used to offload some of the processor-intensive tasks, or to manage 17 The processor cores in the sub-system are usually behind an IOMMU, and may 18 contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2 21 The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor [all …]
|
| D | ti,k3-dsp-rproc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Suman Anna <s-anna@ti.com> 13 The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems 14 that are used to offload some of the processor-intensive tasks or algorithms, 17 These processor sub-systems usually contain additional sub-modules like 23 Each DSP Core sub-system is represented as a single DT node. Each node has a 31 - ti,am62a-c7xv-dsp [all …]
|
| D | ti,k3-m4f-rproc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Hari Nagalla <hnagalla@ti.com> 11 - Mathieu Poirier <mathieu.poirier@linaro.org> 20 $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# 25 - ti,am64-m4fss 27 power-domains: 30 "#address-cells": [all …]
|
| D | ti,k3-r5f-rproc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/ti,k3-r5f-rproc.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Suman Anna <s-anna@ti.com> 13 The TI K3 family of SoCs usually have one or more dual-core Arm Cortex R5F 20 AM64x SoCs do not support LockStep mode, but rather a new non-safety mode 21 called "Single-CPU" mode, where only Core0 is used, but with ability to use 27 Each Dual-Core R5F sub-system is represented as a single DTS node 40 - ti,am62-r5fss [all …]
|
| D | qcom,sc7280-mss-pil.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-mss-pil.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Sibi Sankar <quic_sibis@quicinc.com> 19 - qcom,sc7280-mss-pil 23 - description: MSS QDSP6 registers 24 - description: RMB registers 26 reg-names: 28 - const: qdsp6 [all …]
|
| D | qcom,sc7180-mss-pil.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/qcom,sc7180-mss-pil.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Sibi Sankar <quic_sibis@quicinc.com> 19 - qcom,sc7180-mss-pil 23 - description: MSS QDSP6 registers 24 - description: RMB registers 26 reg-names: 28 - const: qdsp6 [all …]
|
| /Documentation/devicetree/bindings/power/reset/ |
| D | xlnx,zynqmp-power.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/power/reset/xlnx,zynqmp-power.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Michal Simek <michal.simek@amd.com> 13 The zynqmp-power node describes the power management configurations. 18 const: xlnx,zynqmp-power 25 Standard property to specify a Mailbox. Each value of 27 mailbox controller device node and an args specifier 28 that will be the phandle to the intended sub-mailbox [all …]
|
| /Documentation/devicetree/bindings/firmware/ |
| D | arm,scpi.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 4 --- 6 $schema: http://devicetree.org/meta-schemas/core.yaml# 11 - Sudeep Holla <sudeep.holla@arm.com> 33 - const: arm,scpi # SCPI v1.0 and above 34 - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0 35 - items: 36 - enum: 37 - amlogic,meson-gxbb-scpi 38 - const: arm,scpi-pre-1.0 [all …]
|
| D | arm,scmi.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 4 --- 6 $schema: http://devicetree.org/meta-schemas/core.yaml# 11 - Sudeep Holla <sudeep.holla@arm.com> 26 - $ref: /schemas/firmware/nxp,imx95-scmi.yaml 34 - description: SCMI compliant firmware with mailbox transport 36 - const: arm,scmi 37 - description: SCMI compliant firmware with ARM SMC/HVC transport 39 - const: arm,scmi-smc 40 - description: SCMI compliant firmware with ARM SMC/HVC transport [all …]
|
| /Documentation/devicetree/bindings/usb/ |
| D | omap-usb.txt | 4 - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb" 5 - ti,hwmods : must be "usb_otg_hs" 6 - multipoint : Should be "1" indicating the musb controller supports 7 multipoint. This is a MUSB configuration-specific setting. 8 - num-eps : Specifies the number of endpoints. This is also a 9 MUSB configuration-specific setting. Should be set to "16" 10 - ram-bits : Specifies the ram address size. Should be set to "12" 11 - interface-type : This is a board specific setting to describe the type of 14 - mode : Should be "3" to represent OTG. "1" signifies HOST and "2" 16 - power : Should be "50". This signifies the controller can supply up to [all …]
|
| /Documentation/process/ |
| D | 2.Process.rst | 14 --------------- 16 The kernel developers use a loosely time-based release process, with a new 53 be called 5.6-rc1. The -rc1 release is the signal that the time to 63 exception is made for drivers for previously-unsupported hardware; if they 64 touch no in-tree code, they cannot cause regressions and should be safe to 68 time. Linus releases new -rc kernels about once a week; a normal series 69 will get up to somewhere between -rc6 and -rc9 before the kernel is 78 September 30 5.4-rc1, merge window closes 79 October 6 5.4-rc2 80 October 13 5.4-rc3 [all …]
|