Home
last modified time | relevance | path

Searched +full:sub +full:- +full:domains (Results 1 – 25 of 74) sorted by relevance

123

/linux-5.10/Documentation/devicetree/bindings/arm/ !
Darm,scpi.txt2 ----------------------------------------------------------
10 - compatible : should be
12 * "arm,scpi-pre-1.0" : For implementations complying to all
14 - mboxes: List of phandle and mailbox channel specifiers
17 - shmem : List of phandle pointing to the shared memory(SHM) area between the
27 ------------------------------------------------------------
34 - compatible : should be "arm,scpi-clocks"
36 protocol much be listed as sub-nodes under this node.
38 Sub-nodes
41 - compatible : shall include one of the following
[all …]
Darm,scmi.txt2 ----------------------------------------------------------
17 - compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
18 - mboxes: List of phandle and mailbox channel specifiers. It should contain
22 - shmem : List of phandle pointing to the shared memory(SHM) area as per
24 - #address-cells : should be '1' if the device has sub-nodes, maps to
25 protocol identifier for a given sub-node.
26 - #size-cells : should be '0' as 'reg' property doesn't have any size
28 - arm,smc-id : SMC id required when using smc or hvc transports
32 - mbox-names: shall be "tx" or "rx" depending on mboxes entries.
41 Each protocol supported shall have a sub-node with corresponding compatible
[all …]
/linux-5.10/Documentation/devicetree/bindings/power/ !
Dpower-domain.yaml1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/power/power-domain.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: Generic PM domains
10 - Rafael J. Wysocki <rjw@rjwysocki.net>
11 - Kevin Hilman <khilman@kernel.org>
12 - Ulf Hansson <ulf.hansson@linaro.org>
15 System on chip designs are often divided into multiple PM domains that can be
20 their PM domains provided by PM domain providers. A PM domain provider can be
[all …]
Drockchip-io-domain.txt1 Rockchip SRAM for IO Voltage Domains:
2 -------------------------------------
9 - If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
18 - any logic for deciding what voltage we should set regulators to
19 - any logic for deciding whether regulators (or internal SoC blocks)
33 - compatible: should be one of:
34 - "rockchip,px30-io-voltage-domain" for px30
35 - "rockchip,px30-pmu-io-voltage-domain" for px30 pmu-domains
36 - "rockchip,rk3188-io-voltage-domain" for rk3188
37 - "rockchip,rk3228-io-voltage-domain" for rk3228
[all …]
/linux-5.10/Documentation/devicetree/bindings/soc/dove/ !
Dpmu.txt4 - compatible: value should be "marvell,dove-pmu".
5 May also include "simple-bus" if there are child devices, in which
7 - reg: two base addresses and sizes of the PM controller and PMU.
8 - interrupts: single interrupt number for the PMU interrupt
9 - interrupt-controller: must be specified as the PMU itself is an
11 - #interrupt-cells: must be 1.
12 - #reset-cells: must be 1.
13 - domains: sub-node containing domain descriptions
16 - ranges: defines the address mapping for child devices, as per the
18 "simple-bus".
[all …]
/linux-5.10/Documentation/devicetree/bindings/remoteproc/ !
Dqcom,q6v5.txt6 - compatible:
10 "qcom,q6v5-pil",
11 "qcom,ipq8074-wcss-pil"
12 "qcom,msm8916-mss-pil",
13 "qcom,msm8974-mss-pil"
14 "qcom,msm8996-mss-pil"
15 "qcom,msm8998-mss-pil"
16 "qcom,sc7180-mss-pil"
17 "qcom,sdm845-mss-pil"
19 - reg:
[all …]
Dti,k3-r5f-rproc.yaml1 # 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 Each Dual-Core R5F sub-system is represented as a single DTS node
33 - ti,am654-r5fss
34 - ti,j721e-r5fss
36 power-domains:
[all …]
Dti,keystone-rproc.txt5 sub-systems that are used to offload some of the processor-intensive tasks or
8 These processor sub-systems usually contain additional sub-modules like L1
15 Each DSP Core sub-system is represented as a single DT node, and should also
22 --------------------
25 - compatible: Should be one of the following,
26 "ti,k2hk-dsp" for DSPs on Keystone 2 66AK2H/K SoCs
27 "ti,k2l-dsp" for DSPs on Keystone 2 66AK2L SoCs
28 "ti,k2e-dsp" for DSPs on Keystone 2 66AK2E SoCs
29 "ti,k2g-dsp" for DSPs on Keystone 2 66AK2G SoCs
31 - reg: Should contain an entry for each value in 'reg-names'.
[all …]
/linux-5.10/Documentation/devicetree/bindings/usb/ !
Dmediatek,mtu3.txt4 - compatible : should be "mediatek,<soc-model>-mtu3", "mediatek,mtu3",
5 soc-model is the name of SoC, such as mt8173, mt2712 etc,
8 - "mediatek,mt8173-mtu3"
9 - reg : specifies physical base address and size of the registers
10 - reg-names: should be "mac" for device IP and "ippc" for IP port control
11 - interrupts : interrupt used by the device IP
12 - power-domains : a phandle to USB power domain node to control USB's
14 - vusb33-supply : regulator of USB avdd3.3v
15 - clocks : a list of phandle + clock-specifier pairs, one for each
16 entry in clock-names
[all …]
/linux-5.10/Documentation/devicetree/bindings/display/msm/ !
Dhdmi.txt4 - compatible: one of the following
5 * "qcom,hdmi-tx-8996"
6 * "qcom,hdmi-tx-8994"
7 * "qcom,hdmi-tx-8084"
8 * "qcom,hdmi-tx-8974"
9 * "qcom,hdmi-tx-8660"
10 * "qcom,hdmi-tx-8960"
11 - reg: Physical base address and length of the controller's registers
12 - reg-names: "core_physical"
13 - interrupts: The interrupt signal from the hdmi block.
[all …]
Dmdp5.txt6 encapsulates sub-blocks like MDP5, DSI, HDMI, eDP etc, and the MDP5 display
11 - compatible:
12 * "qcom,mdss" - MDSS
13 - reg: Physical base address and length of the controller's registers.
14 - reg-names: The names of register regions. The following regions are required:
17 - interrupts: The interrupt signal from MDSS.
18 - interrupt-controller: identifies the node as an interrupt controller.
19 - #interrupt-cells: specifies the number of cells needed to encode an interrupt
21 - power-domains: a power domain consumer specifier according to
23 - clocks: device clocks. See ../clocks/clock-bindings.txt for details.
[all …]
Ddpu.txt6 sub-blocks like DPU display controller, DSI and DP interfaces etc.
11 - compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss"
12 - reg: physical base address and length of contoller's registers.
13 - reg-names: register region names. The following region is required:
15 - power-domains: a power domain consumer specifier according to
17 - clocks: list of clock specifiers for clocks needed by the device.
18 - clock-names: device clock names, must be in same order as clocks property.
23 - interrupts: interrupt signal from MDSS.
24 - interrupt-controller: identifies the node as an interrupt controller.
25 - #interrupt-cells: specifies the number of cells needed to encode an interrupt
[all …]
/linux-5.10/Documentation/devicetree/bindings/soc/rockchip/ !
Dpower_domain.txt1 * Rockchip Power Domains
3 Rockchip processors include support for multiple power domains which can be
7 - compatible: Should be one of the following.
8 "rockchip,px30-power-controller" - for PX30 SoCs.
9 "rockchip,rk3036-power-controller" - for RK3036 SoCs.
10 "rockchip,rk3066-power-controller" - for RK3066 SoCs.
11 "rockchip,rk3128-power-controller" - for RK3128 SoCs.
12 "rockchip,rk3188-power-controller" - for RK3188 SoCs.
13 "rockchip,rk3228-power-controller" - for RK3228 SoCs.
14 "rockchip,rk3288-power-controller" - for RK3288 SoCs.
[all …]
/linux-5.10/Documentation/devicetree/bindings/display/bridge/ !
Dnwl-dsi.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: Northwest Logic MIPI-DSI controller on i.MX SoCs
10 - Guido Gúnther <agx@sigxcpu.org>
11 - Robert Chiras <robert.chiras@nxp.com>
14 NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge for
15 the SOCs NWL MIPI-DSI host controller.
18 - $ref: ../dsi-controller.yaml#
[all …]
/linux-5.10/drivers/soc/ti/ !
DKconfig1 # SPDX-License-Identifier: GPL-2.0-only
2 # 64-bit ARM SoCs from TI
30 tristate "Keystone Queue Manager Sub System"
36 Packets are queued/de-queued by writing/reading descriptor address
47 Queue Manager Sub System.
58 c-states on AM335x. Also required for rtc and ddr in self-refresh low
62 tristate "TI AMx3 Wkup-M3 IPC Driver"
72 tristate "TI SCI PM Domains Driver"
84 bool "K3 Ring accelerator Sub System"
105 tristate "TI PRU-ICSS Subsystem Platform drivers"
[all …]
/linux-5.10/arch/x86/include/asm/xen/ !
Dcpuid.h2 * arch-x86/cpuid.h
47 * EAX: Largest Xen-information leaf. All leaves up to an including @EAX
49 * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
60 * EBX-EDX: Reserved (currently all zeroes).
67 * EBX: Base address of Xen-specific MSRs.
78 * Sub-leaf 0: EAX: bit 0: emulated tsc
85 * Sub-leaf 1: EAX: tsc offset low part
87 * ECX: multiplicator for tsc->ns conversion
88 * EDX: shift amount for tsc->ns conversion
89 * Sub-leaf 2: EAX: host tsc frequency in kHz
[all …]
/linux-5.10/arch/arm/include/asm/ !
Duaccess-asm.h1 /* SPDX-License-Identifier: GPL-2.0-only */
6 #include <asm/asm-offsets.h>
21 adds \tmp, \addr, #\size - 1
33 sub \tmp, \limit, #1
34 subs \tmp, \tmp, \addr @ tmp = limit - 1 - addr
36 subshs \tmp, \tmp, \size @ tmp = limit - (addr + size) }
45 * Whenever we re-enter userspace, the domains should always be
59 * Whenever we re-enter userspace, the domains should always be
/linux-5.10/Documentation/devicetree/bindings/soc/ti/ !
Dti,pruss.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
8 TI Programmable Real-Time Unit and Industrial Communication Subsystem
11 - Suman Anna <s-anna@ti.com>
15 The Programmable Real-Time Unit and Industrial Communication Subsystem
16 (PRU-ICSS a.k.a. PRUSS) is present on various TI SoCs such as AM335x, AM437x,
17 Keystone 66AK2G, OMAP-L138/DA850 etc. A PRUSS consists of dual 32-bit RISC
18 cores (Programmable Real-Time Units, or PRUs), shared RAM, data and
23 peripheral interfaces, fast real-time responses, or specialized data handling.
[all …]
/linux-5.10/Documentation/power/ !
Dopp.rst5 (C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
20 -------------------------------------------------
22 Complex SoCs of today consists of a multiple sub-modules working in conjunction.
25 facilitate this, sub-modules in a SoC are grouped into domains, allowing some
26 domains to run at lower voltage and frequency while other domains run at
41 - {300000000, 1000000}
42 - {800000000, 1200000}
43 - {1000000000, 1300000}
46 ----------------------------------------
57 (users) -> registers a set of default OPPs -> (library)
[all …]
/linux-5.10/Documentation/devicetree/bindings/iio/adc/ !
Drenesas,gyroadc.txt1 * Renesas R-Car GyroADC device driver
5 are sampled by the GyroADC block in a round-robin fashion and the result
9 - compatible: Should be "<soc-specific>", "renesas,rcar-gyroadc".
10 The <soc-specific> should be one of:
11 renesas,r8a7791-gyroadc - for the GyroADC block present
13 renesas,r8a7792-gyroadc - for the GyroADC with interrupt
15 - reg: Address and length of the register set for the device
16 - clocks: References to all the clocks specified in the clock-names
18 Documentation/devicetree/bindings/clock/clock-bindings.txt.
19 - clock-names: Shall contain "fck". The "fck" is the GyroADC block clock.
[all …]
/linux-5.10/Documentation/devicetree/bindings/clock/ !
Dbaikal,bt1-ccu-pll.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
4 ---
5 $id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-pll.yaml#
6 $schema: http://devicetree.org/meta-schemas/core.yaml#
8 title: Baikal-T1 Clock Control Unit PLL
11 - Serge Semin <fancer.lancer@gmail.com>
14 Clocks Control Unit is the core of Baikal-T1 SoC System Controller
18 IP-blocks or to groups of blocks (clock domains). The transformation is done
19 by means of PLLs and gateable/non-gateable dividers embedded into the CCU.
23 2) PLLs clocks generators (PLLs) - described in this binding file.
[all …]
/linux-5.10/Documentation/devicetree/bindings/pci/ !
Dmediatek-pcie.txt4 - compatible: Should contain one of the following strings:
5 "mediatek,mt2701-pcie"
6 "mediatek,mt2712-pcie"
7 "mediatek,mt7622-pcie"
8 "mediatek,mt7623-pcie"
9 "mediatek,mt7629-pcie"
10 - device_type: Must be "pci"
11 - reg: Base addresses and lengths of the PCIe subsys and root ports.
12 - reg-names: Names of the above areas to use during resource lookup.
13 - #address-cells: Address representation for root ports (must be 3)
[all …]
/linux-5.10/drivers/firmware/imx/ !
Dscu-pd.c1 // SPDX-License-Identifier: GPL-2.0+
4 * Copyright 2017-2018 NXP
7 * Implementation of the SCU based Power Domains
10 * single global power domain and implement the ->attach|detach_dev()
12 * From within the ->attach_dev(), we could get the OF node for
13 * the device that is being attached and then parse the power-domain
18 * Additionally, we need to implement the ->stop() and ->start()
20 * rather than using the above ->power_on|off() callbacks.
23 * 1. The ->attach_dev() of power domain infrastructure still does
24 * not support multi domains case as the struct device *dev passed
[all …]
/linux-5.10/Documentation/devicetree/bindings/opp/ !
Dopp.txt2 ----------------------------------------------------
4 Devices work at voltage-current-frequency combinations and some implementations
13 Binding 1: operating-points
16 This binding only supports voltage-frequency pairs.
19 - operating-points: An array of 2-tuples items, and each item consists
20 of frequency and voltage like <freq-kHz vol-uV>.
27 compatible = "arm,cortex-a9";
29 next-level-cache = <&L2>;
30 operating-points = <
39 Binding 2: operating-points-v2
[all …]
/linux-5.10/Documentation/s390/ !
Dvfio-ap.rst13 The AP adapter cards are exposed via the AP bus. The motivation for vfio-ap
45 sub-directory::
52 An adapter is partitioned into domains. An adapter can hold up to 256 domains
61 * Usage domains are domains that are targeted by an AP instruction to
64 * Control domains are domains that are changed by an AP command sent to a
68 The AP usage and control domains are assigned to a given LPAR via the system's
71 domains assigned to the LPAR. The domain number of each usage domain and
76 significant bit, correspond to domains 0-255.
91 domains 6 and 71 (0x47) are assigned to the LPAR, the AP bus will create the
111 * NQAP: to enqueue an AP command-request message to a queue
[all …]

123