summaryrefslogtreecommitdiff
path: root/static/freebsd/man4/fdt_pinctrl.4 3.html
blob: 97f4264c951968985f281f5a85120505436fada1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
<table class="head">
  <tr>
    <td class="head-ltitle">FDT_PINCTRL(4)</td>
    <td class="head-vol">Device Drivers Manual</td>
    <td class="head-rtitle">FDT_PINCTRL(4)</td>
  </tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">fdt_pinctrl</code> &#x2014; <span class="Nd">FDT
    I/O pin multiplexing support</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp"><code class="Cd">device fdt_pinctrl</code></p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">Pin multiplexing is a technology used to re-purpose a single
    physical connection (depending on chip packaging it may be pin, ball, or
    pad) by routing its signal to any one of several different SoC internal
    devices. For example, based on the actual device design, a single SoC chip
    pin might perform any of these roles: SPI clock, I2C data, GPIO pin, or PWM
    signal. Function selection is performed by the pinmux controller, a SoC
    hardware block which is usually controlled by a set of registers. Pinmux
    controller capabilities and register format depend on the actual hardware
    implementation.</p>
<p class="Pp">On <a class="Xr">fdt(4)</a> 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. Properties of such nodes are
    hardware-specific and handled by individual pinctrl drivers.</p>
<section class="Ss">
<h2 class="Ss" id="Example_1"><a class="permalink" href="#Example_1">Example
  1</a></h2>
<p class="Pp">Pinmux controller device tree node</p>
<div class="Bd Pp Li">
<pre>pinctrl@7e220000 {
    compatible = &quot;vndr,soc1715-pinctrl&quot;;
    reg = &lt;0x7e220000 0x100&gt;

    spi0_pins: spi0 {
        vndr,pins = &lt;11 12&gt;
        vndr,functions = &lt;ALT0 ALT5&gt;
    }

    i2c0_pins: i2c0 {
        ...
    }
}</pre>
</div>
<p class="Pp">Client devices are hardware devices that require certain pin
    configurations to function properly. Depending on the state the device is in
    (active, idle) it might require different pin configurations. 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 is applied
    in the <a class="Xr">fdt_pinctrl_configure_tree(9)</a> call. In addition to
    referring to pin configurations by index, they can 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 <a class="Xr">fdt_pinctrl_configure(9)</a> and
    <a class="Xr">fdt_pinctrl_configure_by_name(9)</a>.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Example_2"><a class="permalink" href="#Example_2">Example
  2</a></h2>
<div class="Bd Li">
<pre>backlight@7f000000 {
    compatible = &quot;vndr,vndr-bl&quot;
    reg = &lt;0x7f000000 0x20&gt;
    ...
    pinctrl-name = &quot;active&quot;, &quot;idle&quot;
    pinctrl-0 = &lt;&amp;backlight_active_pins&gt;
    pinctrl-1 = &lt;&amp;backlight_idle_pins&gt;
}</pre>
</div>
<p class="Pp">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
    <a class="Xr">fdt_pinctrl_configure_tree(9)</a> to configure pins for all
    enabled devices (devices where the &quot;status&quot; property is not set to
    &quot;disabled&quot;).</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
  ALSO</a></h1>
<p class="Pp"><a class="Xr">fdt_pinctrl(9)</a></p>
</section>
<section class="Sh">
<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1>
<p class="Pp">The <code class="Nm">fdt_pinctrl</code> driver first appeared in
    <span class="Ux">FreeBSD 10.2</span>.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1>
<p class="Pp">The <code class="Nm">fdt_pinctrl</code> device driver was
    developed by <span class="An">Ian Lepore</span>
    &lt;<a class="Mt" href="mailto:ian@FreeBSD.org">ian@FreeBSD.org</a>&gt;.
    This manual page was written by <span class="An">Oleksandr Tymoshenko</span>
    &lt;<a class="Mt" href="mailto:gonzo@FreeBSD.org">gonzo@FreeBSD.org</a>&gt;.</p>
</section>
</div>
<table class="foot">
  <tr>
    <td class="foot-date">March 3, 2018</td>
    <td class="foot-os">FreeBSD 15.0</td>
  </tr>
</table>