samsung_sm8750/android_kernel_samsung_sm8750-devicetrees
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

dt-bindings: Add devicetree bindings

Browse Source 
Add snapshot of device tree bindings from keystone common kernel, branch
"android-mainline-keystone-qcom-release" at c4c12103f9c0 ("Snap for 9228065
from e32903b9a63bb558df8b803b076619c53c16baad to
android-mainline-keystone-qcom-release").

Change-Id: I7682079615cbd9f29340a5c1f2a1d84ec441a1f1
Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
This commit is contained in:
Melody Olvera
2023-04-03 14:38:11 -07:00
parent c334acf377
commit 6f18ce8026
4878 changed files with 424312 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
bindings/arm/msm/qcom,idle-state.txt Normal file
View File

@@ -0,0 +1,84 @@
QCOM Idle States for cpuidle driver
ARM provides idle-state node to define the cpuidle states, as defined in [1].
cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle
states. Idle states have different enter/exit latency and residency values.
The idle states supported by the QCOM SoC are defined as -
* Standby
* Retention
* Standalone Power Collapse (Standalone PC or SPC)
* Power Collapse (PC)
Standby: Standby does a little more in addition to architectural clock gating.
When the WFI instruction is executed the ARM core would gate its internal
clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
trigger to execute the SPM state machine. The SPM state machine waits for the
interrupt to trigger the core back in to active. This triggers the cache
hierarchy to enter standby states, when all cpus are idle. An interrupt brings
the SPM state machine out of its wait, the next step is to ensure that the
cache hierarchy is also out of standby, and then the cpu is allowed to resume
execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
driver and is not defined in the DT. The SPM state machine should be
configured to execute this state by default and after executing every other
state below.
Retention: Retention is a low power state where the core is clock gated and
the memory and the registers associated with the core are retained. The
voltage may be reduced to the minimum value needed to keep the processor
registers active. The SPM should be configured to execute the retention
sequence and would wait for interrupt, before restoring the cpu to execution
state. Retention may have a slightly higher latency than Standby.
Standalone PC: A cpu can power down and warmboot if there is a sufficient time
between the time it enters idle and the next known wake up. SPC mode is used
to indicate a core entering a power down state without consulting any other
cpu or the system resources. This helps save power only on that core. The SPM
sequence for this idle state is programmed to power down the supply to the
core, wait for the interrupt, restore power to the core, and ensure the
system state including cache hierarchy is ready before allowing core to
resume. Applying power and resetting the core causes the core to warmboot
back into Elevation Level (EL) which trampolines the control back to the
kernel. Entering a power down state for the cpu, needs to be done by trapping
into a EL. Failing to do so, would result in a crash enforced by the warm boot
code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
be flushed in s/w, before powering down the core.
Power Collapse: This state is similar to the SPC mode, but distinguishes
itself in that the cpu acknowledges and permits the SoC to enter deeper sleep
modes. In a hierarchical power domain SoC, this means L2 and other caches can
be flushed, system bus, clocks - lowered, and SoC main XO clock gated and
voltages reduced, provided all cpus enter this state. Since the span of low
power modes possible at this state is vast, the exit latency and the residency
of this low power mode would be considered high even though at a cpu level,
this essentially is cpu power down. The SPM in this state also may handshake
with the Resource power manager (RPM) processor in the SoC to indicate a
complete application processor subsystem shut down.
The idle-state for QCOM SoCs are distinguished by the compatible property of
the idle-states device node.
The devicetree representation of the idle state should be -
Required properties:
- compatible: Must be one of -
"qcom,idle-state-ret",
"qcom,idle-state-spc",
"qcom,idle-state-pc",
and "arm,idle-state".
Other required and optional properties are specified in [1].
Example:
idle-states {
CPU_SPC: spc {
compatible = "qcom,idle-state-spc", "arm,idle-state";
entry-latency-us = <150>;
exit-latency-us = <200>;
min-residency-us = <2000>;
};
};
[1]. Documentation/devicetree/bindings/cpu/idle-states.yaml

49
bindings/arm/msm/qcom,kpss-acc.txt Normal file
View File

@@ -0,0 +1,49 @@
Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
There is one ACC register region per CPU within the KPSS remapped region as
well as an alias register region that remaps accesses to the ACC associated
with the CPU accessing the region.
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: should be one of:
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: the first element specifies the base address and size of
the register region. An optional second element specifies
the base address and size of the alias register region.
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to the pll parents.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: must be "pll8_vote", "pxo".
- clock-output-names:
Usage: optional
Value type: <string>
Definition: Name of the output clock. Typically acpuX_aux where X is a
CPU number starting at 0.
Example:
clock-controller@2088000 {
compatible = "qcom,kpss-acc-v2";
reg = <0x02088000 0x1000>,
<0x02008000 0x1000>;
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
clock-names = "pll8_vote", "pxo";
clock-output-names = "acpu0_aux";
};

44
bindings/arm/msm/qcom,kpss-gcc.txt Normal file
View File

@@ -0,0 +1,44 @@
Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: should be one of the following. The generic compatible
"qcom,kpss-gcc" should also be included.
"qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"
"qcom,kpss-gcc-apq8064", "qcom,kpss-gcc"
"qcom,kpss-gcc-msm8974", "qcom,kpss-gcc"
"qcom,kpss-gcc-msm8960", "qcom,kpss-gcc"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: base address and size of the register region
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to the pll parents.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: must be "pll8_vote", "pxo".
- clock-output-names:
Usage: required
Value type: <string>
Definition: Name of the output clock. Typically acpu_l2_aux indicating
an L2 cache auxiliary clock.
Example:
l2cc: clock-controller@2011000 {
compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc";
reg = <0x2011000 0x1000>;
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
clock-names = "pll8_vote", "pxo";
clock-output-names = "acpu_l2_aux";
};

65
bindings/arm/msm/qcom,llcc.yaml Normal file
View File

@@ -0,0 +1,65 @@
# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/msm/qcom,llcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Last Level Cache Controller
maintainers:
- Rishabh Bhatnagar <rishabhb@codeaurora.org>
- Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
description: |
LLCC (Last Level Cache Controller) provides last level of cache memory in SoC,
that can be shared by multiple clients. Clients here are different cores in the
SoC, the idea is to minimize the local caches at the clients and migrate to
common pool of memory. Cache memory is divided into partitions called slices
which are assigned to clients. Clients can query the slice details, activate
and deactivate them.
properties:
compatible:
enum:
- qcom,sc7180-llcc
- qcom,sc7280-llcc
- qcom,sc8180x-llcc
- qcom,sc8280xp-llcc
- qcom,sdm845-llcc
- qcom,sm6350-llcc
- qcom,sm8150-llcc
- qcom,sm8250-llcc
- qcom,sm8350-llcc
- qcom,sm8450-llcc
- qcom,sm8550-llcc
reg:
items:
- description: LLCC base register region
- description: LLCC broadcast base register region
reg-names:
items:
- const: llcc_base
- const: llcc_broadcast_base
interrupts:
maxItems: 1
required:
- compatible
- reg
- reg-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
system-cache-controller@1100000 {
compatible = "qcom,sdm845-llcc";
reg = <0x1100000 0x200000>, <0x1300000 0x50000> ;
reg-names = "llcc_base", "llcc_broadcast_base";
interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
};

58
bindings/arm/msm/qcom,saw2.txt Normal file
View File

@@ -0,0 +1,58 @@
SPM AVS Wrapper 2 (SAW2)
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
power-controller that transitions a piece of hardware (like a processor or
subsystem) into and out of low power modes via a direct connection to
the PMIC. It can also be wired up to interact with other processors in the
system, notifying them when a low power state is entered or exited.
Multiple revisions of the SAW hardware are supported using these Device Nodes.
SAW2 revisions differ in the register offset and configuration data. Also, the
same revision of the SAW in different SoCs may have different configuration
data due the differences in hardware capabilities. Hence the SoC name, the
version of the SAW hardware in that SoC and the distinction between cpu (big
or Little) or cache, may be needed to uniquely identify the SAW register
configuration and initialization data. The compatible string is used to
indicate this parameter.
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: Must have
"qcom,saw2"
A more specific value could be one of:
"qcom,apq8064-saw2-v1.1-cpu"
"qcom,msm8226-saw2-v2.1-cpu"
"qcom,msm8974-saw2-v2.1-cpu"
"qcom,apq8084-saw2-v2.1-cpu"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: the first element specifies the base address and size of
the register region. An optional second element specifies
the base address and size of the alias register region.
- regulator:
Usage: optional
Value type: boolean
Definition: Indicates that this SPM device acts as a regulator device
device for the core (CPU or Cache) the SPM is attached
to.
Example 1:
power-controller@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
regulator;
};
Example 2:
saw0: power-controller@f9089000 {
compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2";
reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
};

18
bindings/arm/msm/ssbi.txt Normal file
View File

@@ -0,0 +1,18 @@
* Qualcomm SSBI
Some Qualcomm MSM devices contain a point-to-point serial bus used to
communicate with a limited range of devices (mostly power management
chips).
These require the following properties:
- compatible: "qcom,ssbi"
- qcom,controller-type
indicates the SSBI bus variant the controller should use to talk
with the slave device. This should be one of "ssbi", "ssbi2", or
"pmic-arbiter". The type chosen is determined by the attached
slave.
The slave device should be the single child node of the ssbi device
with a compatible field.