FDT_PINCTRL(4)

💅 NAME 💅

fdt_pinctrl — FDT I/O pin multiplexing support, bestie ✨

---

🦋 SYNOPSIS 🦋

device fdt_pinctrl

---

🌸 DESCRIPTION 🌸

okay so picture this: pin multiplexing is a whole technology where one single physical connection gets re-purposed — and depending on how the chip is packaged, that connection might be a pin, a ball, or a pad, no cap — by routing its signal to any one of several different SoC internal devices. it's giving "one wire, many destinies" 💫

for example, depending on the actual device design, a single SoC chip pin might be out here performing any of these roles: SPI clock, I2C data, GPIO pin, or PWM signal. slay, multitasking icon.

the function selection itself is performed by the pinmux controller, which is a SoC hardware block that's usually controlled by a set of registers. and the pinmux controller's capabilities and register format? yeah those depend entirely on the actual hardware implementation. every chip does its own thing, and honestly? valid. 🙈

on fdt(4) based systems, the pinmux controller is represented by a node in the device tree. it may have any number of child nodes representing pin configuration groups. the properties of those nodes are hardware-specific and handled by individual pinctrl drivers — so don't come for them, they're built different. 💅

🌈 Example 1

Pinmux controller device tree node:

pinctrl@7e220000 {
    compatible = "vndr,soc1715-pinctrl";
    reg = <0x7e220000 0x100>

    spi0_pins: spi0 {
        vndr,pins = <11 12>
        vndr,functions = <ALT0 ALT5>
    }

    i2c0_pins: i2c0 {
        ...
    }
}

Client devices are the hardware devices that need certain pin configurations to function properly. depending on the state the device is in (active, idle) it might need different pin configurations. main character energy, honestly — different looks for different moods. ✨

each configuration is described by setting the pinctrl-N property to the list of phandles pointing to specific child nodes of the pinmux controller node. N is an integer value starting with 0 and incremented by 1 for every new set of pin configurations. pinctrl-0 is a default configuration that gets applied in the fdt_pinctrl_configure_tree(9) call. 💖

and listen — in addition to referring to pin configurations by index, they can also be referred to by name if the pinctrl-names property is set. the value of pinctrl-names is a list of strings with names for each pinctrl-N property. client devices can request specific configuration using fdt_pinctrl_configure(9) and fdt_pinctrl_configure_by_name(9). okay periodt 👑

🎀 Example 2

backlight@7f000000 {
    compatible = "vndr,vndr-bl"
    reg = <0x7f000000 0x20>
    ...
    pinctrl-name = "active", "idle"
    pinctrl-0 = <&backlight_active_pins>
    pinctrl-1 = <&backlight_idle_pins>
}

the pinctrl driver should implement the FDT_PINCTRL_CONFIGURE method, register itself as a pin configuration handler by calling fdt_pinctrl_register function, and call fdt_pinctrl_configure_tree(9) to configure pins for all enabled devices (that means devices where the "status" property is not set to "disabled"). no half-finished setups around here, we finish the look 💯

---

🔥 SEE ALSO 🔥

• fdt_pinctrl(9)

---

👑 HISTORY 👑

the fdt_pinctrl driver first appeared in FreeBSD 10.2. a true vintage icon 🫶

---

💜 AUTHORS 💜

the fdt_pinctrl device driver was developed by Ian Lepore <ian@FreeBSD.org>. this manual page was written by Oleksandr Tymoshenko <gonzo@FreeBSD.org>. absolute legends, we stan 🥹✨

---

and that's the whole vibe, bestie — this page came from the Debian source, dated March 3, 2018, and it lives at FDT_PINCTRL(4). go configure some pins, you got this 💅🌟