arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
Source file repositories/reference/linux-study-clean/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
File Facts
- System
- Linux kernel
- Corpus path
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi- Extension
.dtsi- Size
- 18643 bytes
- Lines
- 870
- Domain
- Architecture Layer
- Bucket
- arch/arm64
- Inferred role
- Architecture Layer: configuration, schema, or hardware description
- Status
- atlas-only
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
Dependency Surface
dt-bindings/input/input.hrk3399-op1.dtsiarm/cros-ec-keyboard.dtsiarm/cros-ec-sbs.dtsi
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Google Gru (and derivatives) board device tree source
*
* Copyright 2016-2017 Google, Inc
*/
#include <dt-bindings/input/input.h>
#include "rk3399-op1.dtsi"
/ {
aliases {
mmc0 = &sdmmc;
mmc1 = &sdhci;
};
chosen {
stdout-path = "serial2:115200n8";
};
firmware {
#address-cells = <2>;
#size-cells = <2>;
};
/*
* Power Tree
*
* In general an attempt is made to include all rails called out by
* the schematic as long as those rails interact in some way with
* the AP. AKA:
* - Rails that only connect to the EC (or devices that the EC talks to)
* are not included.
* - Rails _are_ included if the rails go to the AP even if the AP
* doesn't currently care about them / they are always on. The idea
* here is that it makes it easier to map to the schematic or extend
* later.
*
* If two rails are substantially the same from the AP's point of
* view, though, we won't create a full fixed regulator. We'll just
* put the child rail as an alias of the parent rail. Sometimes rails
* look the same to the AP because one of these is true:
* - The EC controls the enable and the EC always enables a rail as
* long as the AP is running.
* - The rails are actually connected to each other by a jumper and
* the distinction is just there to add clarity/flexibility to the
* schematic.
*/
ppvar_sys: regulator-ppvar-sys {
compatible = "regulator-fixed";
regulator-name = "ppvar_sys";
regulator-always-on;
regulator-boot-on;
};
pp1200_lpddr: regulator-pp1200-lpddr {
compatible = "regulator-fixed";
regulator-name = "pp1200_lpddr";
/* EC turns on w/ lpddr_pwr_en; always on for AP */
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
vin-supply = <&ppvar_sys>;
};
pp1800: regulator-pp1800 {
Annotation
- Immediate include surface: `dt-bindings/input/input.h`, `rk3399-op1.dtsi`, `arm/cros-ec-keyboard.dtsi`, `arm/cros-ec-sbs.dtsi`.
- Atlas domain: Architecture Layer / arch/arm64.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.