tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
usb: typec: Add firmware documentation for the Intel PMC mux control
Adding documentation that describes how the PMC mux-agent
function is described in the ACPI tables.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200507150900.12102-4-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
authored by
Heikki Krogerus
and committed by
Greg Kroah-Hartman
1f478dc2
ff4a30d5
+153
+153
Documentation/firmware-guide/acpi/intel-pmc-mux.rst
+153
Documentation/firmware-guide/acpi/intel-pmc-mux.rst
···
1
+
.. SPDX-License-Identifier: GPL-2.0
2
+
3
+
=====================
4
+
Intel North Mux-Agent
5
+
=====================
6
+
7
+
Introduction
8
+
============
9
+
10
+
North Mux-Agent is a function of the Intel PMC firmware that is supported on
11
+
most Intel based platforms that have the PMC microcontroller. It's used for
12
+
configuring the various USB Multiplexer/DeMultiplexers on the system. The
13
+
platforms that allow the mux-agent to be configured from the operating system
14
+
have an ACPI device object (node) with HID "INTC105C" that represents it.
15
+
16
+
The North Mux-Agent (aka. Intel PMC Mux Control, or just mux-agent) driver
17
+
communicates with the PMC microcontroller by using the PMC IPC method
18
+
(drivers/platform/x86/intel_scu_ipc.c). The driver registers with the USB Type-C
19
+
Mux Class which allows the USB Type-C Controller and Interface drivers to
20
+
configure the cable plug orientation and mode (with Alternate Modes). The driver
21
+
also registers with the USB Role Class in order to support both USB Host and
22
+
Device modes. The driver is located here: drivers/usb/typec/mux/intel_pmc_mux.c.
23
+
24
+
Port nodes
25
+
==========
26
+
27
+
General
28
+
-------
29
+
30
+
For every USB Type-C connector under the mux-agent control on the system, there
31
+
is a separate child node under the PMC mux-agent device node. Those nodes do not
32
+
represent the actual connectors, but instead the "channels" in the mux-agent
33
+
that are associated with the connectors::
34
+
35
+
Scope (_SB.PCI0.PMC.MUX)
36
+
{
37
+
Device (CH0)
38
+
{
39
+
Name (_ADR, 0)
40
+
}
41
+
42
+
Device (CH1)
43
+
{
44
+
Name (_ADR, 1)
45
+
}
46
+
}
47
+
48
+
_PLD (Physical Location of Device)
49
+
----------------------------------
50
+
51
+
The optional _PLD object can be used with the port (the channel) nodes. If _PLD
52
+
is supplied, it should match the connector node _PLD::
53
+
54
+
Scope (_SB.PCI0.PMC.MUX)
55
+
{
56
+
Device (CH0)
57
+
{
58
+
Name (_ADR, 0)
59
+
Method (_PLD, 0, NotSerialized)
60
+
{
61
+
/* Consider this as pseudocode. */
62
+
Return (\_SB.USBC.CON0._PLD())
63
+
}
64
+
}
65
+
}
66
+
67
+
Mux-agent specific _DSD Device Properties
68
+
-----------------------------------------
69
+
70
+
Port Numbers
71
+
~~~~~~~~~~~~
72
+
73
+
In order to configure the muxes behind a USB Type-C connector, the PMC firmware
74
+
needs to know the USB2 port and the USB3 port that is associated with the
75
+
connector. The driver extracts the correct port numbers by reading specific _DSD
76
+
device properties named "usb2-port-number" and "usb3-port-number". These
77
+
properties have integer value that means the port index. The port index number
78
+
is 1's based, and value 0 is illegal. The driver uses the numbers extracted from
79
+
these device properties as-is when sending the mux-agent specific messages to
80
+
the PMC::
81
+
82
+
Name (_DSD, Package () {
83
+
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
84
+
Package() {
85
+
Package () {"usb2-port-number", 6},
86
+
Package () {"usb3-port-number", 3},
87
+
},
88
+
})
89
+
90
+
Orientation
91
+
~~~~~~~~~~~
92
+
93
+
Depending on the platform, the data and SBU lines coming from the connector may
94
+
be "fixed" from the mux-agent's point of view, which means the mux-agent driver
95
+
should not configure them according to the cable plug orientation. This can
96
+
happen for example if a retimer on the platform handles the cable plug
97
+
orientation. The driver uses a specific device properties "sbu-orientation"
98
+
(SBU) and "hsl-orientation" (data) to know if those lines are "fixed", and to
99
+
which orientation. The value that these properties have is a string value, and
100
+
it can be one that is defined for the USB Type-C connector orientation: "normal"
101
+
or "reversed"::
102
+
103
+
Name (_DSD, Package () {
104
+
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
105
+
Package() {
106
+
Package () {"sbu-orientation", "normal"},
107
+
Package () {"hsl-orientation", "normal"},
108
+
},
109
+
})
110
+
111
+
Example ASL
112
+
===========
113
+
114
+
The following ASL is an example that shows the mux-agent node, and two
115
+
connectors under its control::
116
+
117
+
Scope (_SB.PCI0.PMC)
118
+
{
119
+
Device (MUX)
120
+
{
121
+
Name (_HID, "INTC105C")
122
+
123
+
Device (CH0)
124
+
{
125
+
Name (_ADR, 0)
126
+
127
+
Name (_DSD, Package () {
128
+
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
129
+
Package() {
130
+
Package () {"usb2-port-number", 6},
131
+
Package () {"usb3-port-number", 3},
132
+
Package () {"sbu-orientation", "normal"},
133
+
Package () {"hsl-orientation", "normal"},
134
+
},
135
+
})
136
+
}
137
+
138
+
Device (CH1)
139
+
{
140
+
Name (_ADR, 1)
141
+
142
+
Name (_DSD, Package () {
143
+
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
144
+
Package() {
145
+
Package () {"usb2-port-number", 5},
146
+
Package () {"usb3-port-number", 2},
147
+
Package () {"sbu-orientation", "normal"},
148
+
Package () {"hsl-orientation", "normal"},
149
+
},
150
+
})
151
+
}
152
+
}
153
+
}