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
112
113
|
<table class="head">
<tr>
<td class="head-ltitle">IICMUX(4)</td>
<td class="head-vol">Device Drivers Manual</td>
<td class="head-rtitle">IICMUX(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">iicmux</code> — <span class="Nd">I2C bus
mulitiplexer framework</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp">To compile this driver into the kernel, place the following line
in your kernel configuration file:</p>
<div class="Bd Pp Bd-indent"><code class="Cd">device iicmux</code></div>
<p class="Pp">Alternatively, to load the driver as a module at boot time, place
the following line in <a class="Xr">loader.conf(5)</a>:</p>
<div class="Bd Pp Bd-indent Li">
<pre>iicmux_load="YES"</pre>
</div>
<p class="Pp">Note that it is usually not necessary to explicitly load the
driver module, as it will be loaded automatically along with the driver for
the specific mux hardware in use.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">The <code class="Nm">iicmux</code> framework provides support code
to help implement drivers for various I2C bus multiplexer (mux) hardware.
<code class="Nm">iicmux</code> is not a standalone driver, it is a
collection of support functions and driver methods which are used by
individual mux hardware drivers. It will be loaded automatically when needed
by a mux hardware driver. This manual page provides an overview of the I2C
mux framework and its behavior.</p>
<p class="Pp">Generally speaking, an I2C mux is connected to an upstream I2C
bus, and to one or more downstream I2C buses, and it can be commanded to
connect any one of the downstream buses to the upstream bus. Some hardware
may be able to connect multiple downstream buses at the same time, but that
concept is not supported by <code class="Nm">iicmux</code>.</p>
<p class="Pp">The <code class="Nm">iicmux</code> framework operates
automatically when I2C slave devices initiate I/O. It does not require (or
even allow for) any external control to select the active downstream
bus.</p>
<p class="Pp">When there is no I/O in progress, the mux is said to be in the
“idle” state. Some mux hardware has the ability to disconnect
all downstream buses when in an idle state. Other hardware must always have
one of the downstream buses connected. Individual mux hardware drivers
typically provide a way to select which downstream bus (if any) should be
connected while in the idle state. In the absence of such configuration,
whichever downstream bus was last used remains connected to the upstream
bus.</p>
<p class="Pp" id="iicbus_request_bus">When an I2C slave device on a bus
downstream of a mux initiates I/O, it first requests exclusive use of the
bus by calling
<a class="permalink" href="#iicbus_request_bus"><code class="Fn">iicbus_request_bus</code></a>().
This request is communicated to the bus's parent, which is the
<code class="Nm">iicmux</code> framework mux driver. Once exclusive bus
ownership is obtained, the mux driver connects the upstream I2C bus to the
downstream bus which hosts the slave device that requested bus ownership.
The mux hardware maintains that upstream-to-downstream connection until the
slave device calls
<a class="permalink" href="#iicbus_release_bus"><code class="Fn" id="iicbus_release_bus">iicbus_release_bus</code></a>().
Before releasing ownership, the mux driver returns the mux hardware to the
idle state.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="FDT_CONFIGURATION"><a class="permalink" href="#FDT_CONFIGURATION">FDT
CONFIGURATION</a></h1>
<p class="Pp">On an <a class="Xr">fdt(4)</a> based system, an I2C mux device
node is defined as a child node of its upstream I2C bus when the mux device
is an I2C slave itself. It may be defined as a child node of any other bus
or device in the system when it is not an I2C slave, in which case the
<var class="Va">i2c-parent</var> property indicates which upstream bus the
mux is attached to. In either case, the children of the mux node are
additional I2C buses, which will have one or more I2C slave devices
described in their child nodes.</p>
<p class="Pp">Drivers using the <code class="Nm">iicmux</code> framework conform
to the standard <code class="Li">i2c/i2c-mux.txt</code> bindings
document.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="HINTS_CONFIGURATION"><a class="permalink" href="#HINTS_CONFIGURATION">HINTS
CONFIGURATION</a></h1>
<p class="Pp">On a <a class="Xr">device.hints(5)</a> based system, these values
are configurable for <code class="Nm">iicmux</code> framework drivers :</p>
<dl class="Bl-tag">
<dt id="hint._driver_._unit_.at"><var class="Va">hint.<driver>.<unit>.at</var></dt>
<dd>The upstream <a class="Xr">iicbus(4)</a> the
<code class="Nm">iicmux</code> instance is attached to.</dd>
</dl>
<p class="Pp">When configured via hints, the driver automatically adds an iicbus
instance for every downstream bus supported by the chip. There is currently
no way to indicate used versus unused downstream buses.</p>
</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">iicbus(4)</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">iicmux</code> framework first appeared in
<span class="Ux">FreeBSD 13.0</span>.</p>
</section>
</div>
<table class="foot">
<tr>
<td class="foot-date">January 1, 2020</td>
<td class="foot-os">FreeBSD 15.0</td>
</tr>
</table>
|
