On 03/02/2017 07:22 AM, Mats Karrman wrote:
Hi Heikki,
Good to see things are happening with Type-C!
On 2017-02-21 15:24, Heikki Krogerus wrote:
...
+When connected, the partner will be presented also as its own device under
+/sys/class/typec/. The parent of the partner device will always be the port it
+is attached to. The partner attached to port "port0" will be named
+"port0-partner". Full path to the device would be
+/sys/class/typec/port0/port0-partner/.
A "/port0" too much?
+
+The cable and the two plugs on it may also be optionally presented as their own
+devices under /sys/class/typec/. The cable attached to the port "port0" port
+will be named port0-cable and the plug on the SOP Prime end (see USB Power
+Delivery Specification ch. 2.4) will be named "port0-plug0" and on the SOP
+Double Prime end "port0-plug1". The parent of a cable will always be the port,
+and the parent of the cable plugs will always be the cable.
+
+If the port, partner or cable plug support Alternate Modes, every supported
+Alternate Mode SVID will have their own device describing them. The Alternate
+Modes will not be attached to the typec class. The parent of an alternate mode
+will be the device that supports it, so for example an alternate mode of
+port0-partner will bees presented under /sys/class/typec/port0-partner/. Every
bees?
+mode that is supported will have its own group under the Alternate Mode device
+named "mode<index>", for example /sys/class/typec/port0/<alternate
mode>/mode1/.
+The requests for entering/exiting a mode can be done with "active" attribute
+file in that group.
+
...
I'm hoping to find time to upgrade the kernel and try these patches in my
system.
Looking forward, one thing I have run into is how to connect the typec driver
with a
driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification
includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in
the
Attention message. These signals are needed by the DisplayPort driver to know
when to
start negotiation etc.
Have you got any thoughts on how to standardize such interfaces?
That really depends on the lower level driver. For Chromebooks, where the Type-C
Protocol Manager runs on the EC, we have an extcon driver which reports the pin
states
to the graphics drivers and connects to the Type-C class code using the Type-C
class
API. I still need to update, re-test, and publish that code. The published code
in
https://chromium.googlesource.com/chromiumos/third_party/kernel/, branch
chromeos-4.4,
shows how it can be done, though that code currently still uses the Android
Type-C
infrastructure.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
