Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt- Extension
.txt- Size
- 8801 bytes
- Lines
- 199
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- 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
MPC5200 Device Tree Bindings
----------------------------
(c) 2006-2009 Secret Lab Technologies Ltd
Grant Likely <grant.likely@secretlab.ca>
Naming conventions
------------------
For mpc5200 on-chip devices, the format for each compatible value is
<chip>-<device>[-<mode>]. The OS should be able to match a device driver
to the device based solely on the compatible value. If two drivers
match on the compatible list; the 'most compatible' driver should be
selected.
The split between the MPC5200 and the MPC5200B leaves a bit of a
conundrum. How should the compatible property be set up to provide
maximum compatibility information; but still accurately describe the
chip? For the MPC5200; the answer is easy. Most of the SoC devices
originally appeared on the MPC5200. Since they didn't exist anywhere
else; the 5200 compatible properties will contain only one item;
"fsl,mpc5200-<device>".
The 5200B is almost the same as the 5200, but not quite. It fixes
silicon bugs and it adds a small number of enhancements. Most of the
devices either provide exactly the same interface as on the 5200. A few
devices have extra functions but still have a backwards compatible mode.
To express this information as completely as possible, 5200B device trees
should have two items in the compatible list:
compatible = "fsl,mpc5200b-<device>","fsl,mpc5200-<device>";
It is *strongly* recommended that 5200B device trees follow this convention
(instead of only listing the base mpc5200 item).
ie. ethernet on mpc5200: compatible = "fsl,mpc5200-fec";
ethernet on mpc5200b: compatible = "fsl,mpc5200b-fec", "fsl,mpc5200-fec";
Modal devices, like PSCs, also append the configured function to the
end of the compatible field. ie. A PSC in i2s mode would specify
"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s". This convention is chosen to
avoid naming conflicts with non-psc devices providing the same
function. For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe
the mpc5200 simple spi device and a PSC spi mode respectively.
At the time of writing, exact chip may be either 'fsl,mpc5200' or
'fsl,mpc5200b'.
The soc node
------------
This node describes the on chip SOC peripherals. Every mpc5200 based
board will have this node, and as such there is a common naming
convention for SOC devices.
Required properties:
name description
---- -----------
ranges Memory range of the internal memory mapped registers.
Should be <0 [baseaddr] 0xc000>
reg Should be <[baseaddr] 0x100>
compatible mpc5200: "fsl,mpc5200-immr"
mpc5200b: "fsl,mpc5200b-immr"
system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI
clocks are derived from the fsystem clock.
bus-frequency IPB bus frequency in Hz. Clock rate
used by most of the soc devices.
soc child nodes
---------------
Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
Note: The tables below show the value for the mpc5200. A mpc5200b device
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.