Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt- Extension
.txt- Size
- 5766 bytes
- Lines
- 159
- 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
Lantiq XWAY pinmux controller
Required properties:
- compatible: "lantiq,<chip>-pinctrl", where <chip> is:
"ase" (XWAY AMAZON Family)
"danube" (XWAY DANUBE Family)
"xrx100" (XWAY xRX100 Family)
"xrx200" (XWAY xRX200 Family)
"xrx300" (XWAY xRX300 Family)
- reg: Should contain the physical address and length of the gpio/pinmux
register range
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Lantiq's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those group(s), and two pin configuration parameters:
pull-up and open-drain
The name of each subnode is not important as long as it is unique; all subnodes
should be enumerated and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function.
We support 2 types of nodes.
Definition of mux function groups:
Required subnode-properties:
- lantiq,groups : An array of strings. Each string contains the name of a group.
Valid values for these names are listed below.
- lantiq,function: A string containing the name of the function to mux to the
group. Valid values for function names are listed below.
Valid values for group and function names:
AMAZON:
mux groups:
exin0, exin1, exin2, jtag, spi_di, spi_do, spi_clk, spi_cs1, spi_cs2,
spi_cs3, spi_cs4, spi_cs5, spi_cs6, asc, stp, gpt1, gpt2, gpt3, clkout0,
clkout1, clkout2, mdio, dfe led0, dfe led1, ephy led0, ephy led1, ephy led2
functions:
spi, asc, cgu, jtag, exin, stp, gpt, mdio, ephy, dfe
DANUBE:
mux groups:
exin0, exin1, exin2, jtag, ebu a23, ebu a24, ebu a25, ebu clk, ebu cs1,
ebu wait, nand ale, nand cs1, nand cle, spi_di, spi_do, spi_clk, spi_cs1,
spi_cs2, spi_cs3, spi_cs4, spi_cs5, spi_cs6, asc0, asc0 cts rts, stp, nmi,
gpt1, gpt2, gpt3, clkout0, clkout1, clkout2, clkout3, gnt1, gnt2, gnt3,
req1, req2, req3, dfe led0, dfe led1
functions:
spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu, dfe
xRX100:
mux groups:
exin0, exin1, exin2, exin3, exin4, ebu a23, ebu a24, ebu a25, ebu clk,
ebu cs1, ebu wait, nand ale, nand cs1, nand cle, nand rdy, nand rd,
spi_di, spi_do, spi_clk, spi_cs1, spi_cs2, spi_cs3, spi_cs4, spi_cs5,
spi_cs6, asc0, asc0 cts rts, stp, nmi, gpt1, gpt2, gpt3, clkout0, clkout1,
clkout2, clkout3, gnt1, gnt2, gnt3, gnt4, req1, req2, req3, req4, mdio,
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.