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

[Mats Karrman]

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