Searched +full:sci +full:- +full:reset (Results 1 – 12 of 12) sorted by relevance
| /Documentation/devicetree/bindings/reset/ |
| D | ti,sci-reset.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: TI-SCI reset controller 10 - Nishanth Menon <nm@ti.com> 17 through a protocol called TI System Control Interface (TI-SCI protocol). 19 This reset controller node uses the TI SCI protocol to perform the reset 21 node of the associated TI-SCI system controller node. 25 pattern: "^reset-controller$" [all …]
|
| /Documentation/devicetree/bindings/arm/keystone/ |
| D | ti,sci.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: TI-SCI controller 10 - Nishanth Menon <nm@ti.com> 23 See https://software-dl.ti.com/tisci/esd/latest/index.html for protocol definition. 25 The TI-SCI node describes the Texas Instrument's System Controller entity node. 27 specific functionality such as clocks, power domain, reset or additional 29 relationship between the TI-SCI parent node to the child node. [all …]
|
| D | ti,k3-sci-common.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: Common K3 TI-SCI 10 - Nishanth Menon <nm@ti.com> 14 that is responsible for managing various SoC-level resources like clocks, 16 through the TI-SCI protocol. 18 Each specific device management node like a clock controller node, a reset 19 controller node or an interrupt-controller node should define a common set [all …]
|
| /Documentation/devicetree/bindings/remoteproc/ |
| 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-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 | ti,keystone-rproc.txt | 5 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 …]
|
| /Documentation/devicetree/bindings/mmc/ |
| D | ti-omap-hsmmc.txt | 10 -------------------- 11 - compatible: 12 Should be "ti,omap2-hsmmc", for OMAP2 controllers 13 Should be "ti,omap3-hsmmc", for OMAP3 controllers 14 Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 15 Should be "ti,omap4-hsmmc", for OMAP4 controllers 16 Should be "ti,am33xx-hsmmc", for AM335x controllers 17 Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers. 20 --------------------------------- 22 - ti,hwmods: Must be "mmc<n>", n is controller instance starting 1. [all …]
|
| /Documentation/devicetree/bindings/dma/ |
| D | ti-edma.txt | 8 ------------------------------------------------------------------------------ 12 -------------------- 13 - compatible: Should be: 14 - "ti,edma3-tpcc" for the channel controller(s) on OMAP, 16 - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the 18 - #dma-cells: Should be set to <2>. The first number is the DMA request 20 - reg: Memory map of eDMA CC 21 - reg-names: "edma3_cc" 22 - interrupts: Interrupt lines for CCINT, MPERR and CCERRINT. 23 - interrupt-names: "edma3_ccint", "edma3_mperr" and "edma3_ccerrint" [all …]
|
| /Documentation/arch/x86/x86_64/ |
| D | boot-options.rst | 1 .. SPDX-License-Identifier: GPL-2.0 39 Do not opt-in to Local MCE delivery. Use legacy method 55 Don't overwrite the bios-set CMCI threshold. This boot option 62 Force-enable recoverable machine check code paths 73 Use IO-APIC. Default 76 Don't use the IO-APIC. 85 See Documentation/arch/x86/i386/IO-APIC.rst 91 Don't check the IO-APIC timer. This can work around 124 Use the CPU reboot vector for warm reset 132 Use the keyboard controller. cold reset (default) [all …]
|
| /Documentation/arch/arm64/ |
| D | acpi_object_usage.rst | 16 - Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT 18 - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT 20 - Optional: AGDI, BGRT, CEDT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, 24 - Not supported: AEST, APMT, BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, 39 **Arm Generic diagnostic Dump and Reset Device Interface Table** 41 This table describes a non-maskable event, that is used by the platform 42 firmware, to request the OS to generate a diagnostic dump and reset the device. 68 Optional, not currently supported, with no real use-case for an 83 time as ARM-compatible hardware is available, and the specification 151 UEFI-based; if it is UEFI-based, this table may be supplied. When this [all …]
|
| /Documentation/watchdog/ |
| D | watchdog-parameters.rst | 7 be listed here unless the driver has its own driver-specific information 10 See Documentation/admin-guide/kernel-parameters.rst for information on 14 ------------------------------------------------- 21 timeout. Setting this to a non-zero value can be useful to ensure that 22 either userspace comes up properly, or the board gets reset and allows 25 ------------------------------------------------- 36 ------------------------------------------------- 49 ------------------------------------------------- 58 ------------------------------------------------- 70 ------------------------------------------------- [all …]
|
| /Documentation/power/ |
| D | pci.rst | 13 power management refer to Documentation/driver-api/pm/devices.rst and 27 1.1. Native and Platform-Based Power Management 28 ----------------------------------------------- 31 devices into states in which they draw less power (low-power states) at the 34 Usually, a device is put into a low-power state when it is underutilized or 36 again, it has to be put back into the "fully functional" state (full-power 41 PCI devices may be put into low-power states in two ways, by using the device 53 to put the device that sent it into the full-power state. However, the PCI Bus 68 Thus in many situations both the native and the platform-based power management 72 -------------------------------- [all …]
|