Documentation/devicetree/bindings/display/simple-framebuffer.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/display/simple-framebuffer.yaml- Extension
.yaml- Size
- 6862 bytes
- Lines
- 213
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: configuration, schema, or hardware description
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/simple-framebuffer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Simple Framebuffer
maintainers:
- Hans de Goede <hdegoede@redhat.com>
description: |+
A simple frame-buffer describes a frame-buffer setup by firmware or
the bootloader, with the assumption that the display hardware has
already been set up to scan out from the memory pointed to by the
reg property.
Since simplefb nodes represent runtime information they must be
sub-nodes of the chosen node (*). Simplefb nodes must be named
framebuffer@<address>.
If the devicetree contains nodes for the display hardware used by a
simplefb, then the simplefb node must contain a property called
display, which contains a phandle pointing to the primary display
hw node, so that the OS knows which simplefb to disable when handing
over control to a driver for the real hardware. The bindings for the
hw nodes must specify which node is considered the primary node.
If a panel node is given, then the driver uses this to configure the
physical width and height of the display. If no panel node is given,
then the driver uses the width and height properties of the simplefb
node to estimate it.
It is advised to add display# aliases to help the OS determine how
to number things. If display# aliases are used, then if the simplefb
node contains a display property then the /aliases/display# path
must point to the display hw node the display property points to,
otherwise it must point directly to the simplefb node.
If a simplefb node represents the preferred console for user
interaction, then the chosen node stdout-path property should point
to it, or to the primary display hw node, as with display#
aliases. If display aliases are used then it should be set to the
alias instead.
It is advised that devicetree files contain pre-filled, disabled
framebuffer nodes, so that the firmware only needs to update the
mode information and enable them. This way if e.g. later on support
for more display clocks get added, the simplefb nodes will already
contain this info and the firmware does not need to be updated.
If pre-filled framebuffer nodes are used, the firmware may need
extra information to find the right node. In that case an extra
platform specific compatible and platform specific properties should
be used and documented.
properties:
compatible:
oneOf:
- items:
- enum:
- apple,simple-framebuffer
- allwinner,simple-framebuffer
- amlogic,simple-framebuffer
- const: simple-framebuffer
- const: simple-framebuffer
reg:
description: Location and size of the framebuffer memory
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- 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.