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

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Hi,

On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> 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?

My idea was to have something like the altmode "bus" at one point.
We create a device for every alternate mode registered in typec class,
so the alternate modes registered for the ports and partners would
simply be attached to the altmode bus. There would be a bus per port
of course.

The drivers for the port alternate modes would take care of things
like muxing and other platform specific stuff as needed, and they
would be tied to the underlying subsystems and drivers, graphics in
case of DisplayPort. The drivers for the partner alternate modes would
take care of the actual communication with the alternate mode with
VDMs if needed (but not necessarily), and they would need to be tied
to the port alternate modes. In practice the driver for both the port
and the partner alternate modes will be the same (in the same
location) obviously, at least in most cases.

I think a bus would allow us to support several ways of handling the
alternate modes on different platforms. It would work fine also on
platforms that had no use for it of course, like platforms where
firmware or EC takes care of most things related to Type-C.

But please note that since this is just a high level idea still, we
wouldn't for example need to create an actual bus if there is no use
for it, but since we have the SVIDs that can be used for matching,
then why not try take advantage of them, right.

How would something like that sound to you guys?

> > 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.

In this case I think you would only need to register a driver with the
bus in case you want the handle to the device for the alternate mode.

> 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.

Is this "DP controller" a controller that is capable of taking care of
the USB Power Delivery communication with the partner regarding
DisplayPort alternate mode?

> 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.

What alternate modes systems with WhiskeyCove supports depends on
the platform. WhiskeyCove PMIC (as in Power Management IC) is
available on a few Intel Atom platforms. The USB Type-C PHY in it
provides a simple USB PD transceiver that does not touch the actual
communication with the partners. The communication needs to be done in
software, including dealing with alternate modes.

I'm not planning on using extcon for anything with WhiskeyCove. I
don't have any use for it. It looks to me that extcon is used just as
a tool to create software couplings in many cases, and I'm not
completely comfortable with that.

In my case with DP altmode, if we had for example muxes to take care
of, I don't think it would be a problem to tie the driver for the mux
to the graphics directly, so basically make it part of the graphics
stack. That driver would be the port (and partner) altmode driver.

> Do we need to further standardize attributes under (each) specific alternate mode to
> include things such as HPD for the DP mode?

I'm not completely sure what kind of system you have, but I would
imagine that if we had the bus, your DP controller driver would be the
port (and partner) alternate mode driver. The bus would bind you to
the typec phy.


Thanks,

-- 
heikki