Re: [PATCH v17 2/3] usb: USB Type-C connector class

From: Mats Karrman
Date: Fri Mar 03 2017 - 02:29:59 EST


On 2017-03-03 04:13, Guenter Roeck wrote:

On 03/02/2017 07:22 AM, Mats Karrman wrote:
....
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.

OK, thanks!

My system is a bit different. It's an i.MX6 SoC with the typec phy and DP controller connected

directly to the SoC and it's using DTB/OF.

Using extcon I would have a driver that is both typec class and extcon driver at the same time

since I can't share the access to the typec phy. Is this done elsewhere in the kernel?

I don't know much about the wcove PMIC and what alternate modes it might support but I

guess that driver would end up in the same place.

Do we need to further standardize attributes under (each) specific alternate mode to

include things such as HPD for the DP mode?

BR // Mats