Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591201 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v17 2/3] usb: USB Type-C connector class Mats Karrman <mats.dev.list@gmail.com> - 2017-03-02 16:40 +0100
    Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-03 04:20 +0100
      Re: [PATCH v17 2/3] usb: USB Type-C connector class Mats Karrman <mats.dev.list@gmail.com> - 2017-03-03 08:40 +0100
        Re: [PATCH v17 2/3] usb: USB Type-C connector class Enric Balletbo Serra <eballetbo@gmail.com> - 2017-03-03 11:20 +0100
        Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-03-03 15:50 +0100
          Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-03 20:10 +0100
          Re: [PATCH v17 2/3] usb: USB Type-C connector class Mats Karrman <mats.dev.list@gmail.com> - 2017-03-03 20:30 +0100
            Re: [PATCH v17 2/3] usb: USB Type-C connector class Oliver Neukum <oneukum@suse.com> - 2017-03-06 11:30 +0100
            Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-03-06 14:50 +0100
              Re: [PATCH v17 2/3] usb: USB Type-C connector class Mats Karrman <mats.dev.list@gmail.com> - 2017-03-07 23:40 +0100
                Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-08 06:10 +0100
                Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-03-08 15:10 +0100
                  Re: [PATCH v17 2/3] usb: USB Type-C connector class Mats Karrman <mats.dev.list@gmail.com> - 2017-03-10 23:30 +0100
                    Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-11 00:50 +0100
        Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-03 15:50 +0100

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

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?

BR // Mats

[toc] | [next] | [standalone]

#1591647

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

[toc] | [prev] | [next] | [standalone]

#1591721

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

[toc] | [prev] | [next] | [standalone]

#1591822

2017-03-03 8:29 GMT+01:00 Mats Karrman <mats.dev.list@gmail.com>:
> 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.
>

On a side note, the cros-ec extcon part for DP is currently discussed
here [1]. This driver works together with the cdn-dp driver that just
landed in mainline. So comments and feedback are welcome

[1] https://lkml.org/lkml/2017/3/1/301

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

[toc] | [prev] | [next] | [standalone]

#1592014

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

[toc] | [prev] | [next] | [standalone]

#1592227

On 03/03/2017 04:59 AM, Heikki Krogerus wrote:
> 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.
>

For rk3399 we went back and forth trying other approaches, but using extcon
turned out to be the most straightforward mechanism; everything else would
just have replicated what extcon already provides. Having said that,
I am open to other approaches. The rk3399 implementation may be seen as an
example on what is required, specifically when it comes to the interaction
between cable, DP, and the Type-C phy.

Guenter

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

[toc] | [prev] | [next] | [standalone]

#1592234

On 2017-03-03 13:59, Heikki Krogerus wrote:

> On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> ....

> How would something like that sound to you guys?

Complicated... Need to marinate on that for a while ;)

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

No, the "DP controller" just talks DP and knows nothing about Type-C or USB PD.
It takes a video stream from the SoC and turns it into a DP link, set up and orchestrated
by the corresponding driver. And all the driver needs from Type-C is the plugged in / interrupt /
plugged out events.

The analog switching between USB / safe / DP signal levels in the Type-C connector is, I think,
best handled by the software doing the USB PD negotiation / Altmode handling (using some GPIOs).

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

So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both
attach to the AM bus as well?

BR,
Mats

[toc] | [prev] | [next] | [standalone]

#1593160

Am Freitag, den 03.03.2017, 20:27 +0100 schrieb Mats Karrman:
> On 2017-03-03 13:59, Heikki Krogerus wrote:
> 
> > 
> > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> > ....
> 
> > 
> > How would something like that sound to you guys?
> 
> Complicated... Need to marinate on that for a while ;)

The thing is that a type C plug has operations that affect every
device on it and need to be synchronized. Reset and power
requirements would be the obvious examples.

It seems to me that the natural way to represent this is a bus.
Like SCSI where you have a bus reset operation.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1593338

Hi Mats,

On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote:
> On 2017-03-03 13:59, Heikki Krogerus wrote:
> 
> > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> > ....
> 
> > How would something like that sound to you guys?
> 
> Complicated... Need to marinate on that for a while ;)

Sorry about the bad explanation :-). Let me try again..  I'm simply
looking for a method that is as scalable as possible to handle the
alternate modes, basically how to couple the different components
involved. Bus would feel like the best approach at the moment.

> > > 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?
> 
> No, the "DP controller" just talks DP and knows nothing about Type-C or USB PD.
> It takes a video stream from the SoC and turns it into a DP link, set up and orchestrated
> by the corresponding driver. And all the driver needs from Type-C is the plugged in / interrupt /
> plugged out events.

Got it.

> The analog switching between USB / safe / DP signal levels in the Type-C connector is, I think,
> best handled by the software doing the USB PD negotiation / Altmode handling (using some GPIOs).
> 
> > > 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.
> 
> So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both
> attach to the AM bus as well?

The DP controller would provide the driver and the USB PD phy
(actually, the typec class) the device.

Would it be a problem to register these I2C devices with some other
subsystem, was it extcon or something like AM bus? It really would not
be that uncommon. Or have I misunderstood your question?


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1594708

On 2017-03-06 14:14, Heikki Krogerus wrote:

> Hi Mats,
>
> On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote:
>>>> 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?
>> No, the "DP controller" just talks DP and knows nothing about Type-C or USB PD.
>> It takes a video stream from the SoC and turns it into a DP link, set up and orchestrated
>> by the corresponding driver. And all the driver needs from Type-C is the plugged in / interrupt /
>> plugged out events.
> Got it.
>
>> The analog switching between USB / safe / DP signal levels in the Type-C connector is, I think,
>> best handled by the software doing the USB PD negotiation / Altmode handling (using some GPIOs).
>>
>>>> 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.
>> So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both
>> attach to the AM bus as well?
> The DP controller would provide the driver and the USB PD phy
> (actually, the typec class) the device.
>
> Would it be a problem to register these I2C devices with some other
> subsystem, was it extcon or something like AM bus? It really would not
> be that uncommon. Or have I misunderstood your question?

OK, so a bus could be used for drivers to find each other but it still does not say
anything about how those drivers are supposed to communicate so that must be prescribed
separately, right?

If I read Heikki's original suggestion I understand it like the DP driver would be
responsible for AM specific USB PD/VDM communication. But wouldn't that lead
to a lot of code duplication since the AM protocol is the same for all drivers of
a kind?

I'm still struggling to catch up on what you guys have been up to during the
last year or so :-) and came across some patches of Guenter from last October:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html

What happened to them? Has there been any progress since then?

BR // Mats

[toc] | [prev] | [next] | [standalone]

#1594858

On 03/07/2017 02:30 PM, Mats Karrman wrote:
[ ... ]

>
> I'm still struggling to catch up on what you guys have been up to during the
> last year or so :-) and came across some patches of Guenter from last October:
>
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html
>
> What happened to them? Has there been any progress since then?
>

Updates to keep in sync with API changes, bug fixes, and minor improvements,
for the most part. I can post a current version if there is interest.
The latest version is also available from
https://chromium-review.googlesource.com/#/c/389917/

Guenter

[toc] | [prev] | [next] | [standalone]

#1595205

On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote:
> > > So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both
> > > attach to the AM bus as well?
> > The DP controller would provide the driver and the USB PD phy
> > (actually, the typec class) the device.
> > 
> > Would it be a problem to register these I2C devices with some other
> > subsystem, was it extcon or something like AM bus? It really would not
> > be that uncommon. Or have I misunderstood your question?
> 
> OK, so a bus could be used for drivers to find each other but it still does not say
> anything about how those drivers are supposed to communicate so that must be prescribed
> separately, right?

Yes.

> If I read Heikki's original suggestion I understand it like the DP driver would be
> responsible for AM specific USB PD/VDM communication. But wouldn't that lead
> to a lot of code duplication since the AM protocol is the same for all drivers of
> a kind?

No that's not what I mean. I'm still mixing your PD controller with
something else above, sorry about that. Your PD controller driver
should not ideally even need to be aware of Type-C connector, right?
It definitely does not need to do any USB PD communication.

I would imagine you have on top of the DP controller, a mux (which
could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like
Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB
PD controller. The bus would be tying the mux to the Type-C port (PHY
or PD controller) and its partner (note that it does not tie the mux
to the DP controller). Please correct me if I'm wrong about your
hardware.

Assuming that is how your board roughly looks like, the driver for the
mux would be the driver for the DP altmode devices. That driver would
be the one converting things like the Attention messages notifying
about HPD into toggling of GPIOs, or what ever is needed on your
board, etc.

The actual PD communication with VDMs should be considered as just the
protocol, so we probable should have "protocol drivers". For example
DP alternate mode VDMs and communication will always be the same
despite of the hardware. The DP alternate mode "protocol driver" would
then be tied to the alternate mode device for the partner, and that
driver could have its own hooks for what ever is needed, like HPD
signal handling, configuration changes, whatever. In any case,
hopefully making things easy and straightforward for the "mux driver",
_so that it does not need to care about the actual PD communication_.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1598146

On 2017-03-08 14:58, Heikki Krogerus wrote:

> On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote:
>> If I read Heikki's original suggestion I understand it like the DP driver would be
>> responsible for AM specific USB PD/VDM communication. But wouldn't that lead
>> to a lot of code duplication since the AM protocol is the same for all drivers of
>> a kind?
> No that's not what I mean. I'm still mixing your PD controller with
> something else above, sorry about that. Your PD controller driver
> should not ideally even need to be aware of Type-C connector, right?
> It definitely does not need to do any USB PD communication.

Right.

> I would imagine you have on top of the DP controller, a mux (which
> could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like
> Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB
> PD controller. The bus would be tying the mux to the Type-C port (PHY
> or PD controller) and its partner (note that it does not tie the mux
> to the DP controller). Please correct me if I'm wrong about your
> hardware.

No, you're correct, a discrete mux and a fusb302.

> Assuming that is how your board roughly looks like, the driver for the
> mux would be the driver for the DP altmode devices. That driver would
> be the one converting things like the Attention messages notifying
> about HPD into toggling of GPIOs, or what ever is needed on your
> board, etc.

OK.

> The actual PD communication with VDMs should be considered as just the
> protocol, so we probable should have "protocol drivers". For example
> DP alternate mode VDMs and communication will always be the same
> despite of the hardware. The DP alternate mode "protocol driver" would
> then be tied to the alternate mode device for the partner, and that
> driver could have its own hooks for what ever is needed, like HPD
> signal handling, configuration changes, whatever. In any case,
> hopefully making things easy and straightforward for the "mux driver",
> _so that it does not need to care about the actual PD communication_.

I'm digesting your and Guenter's replies and patches.
I will try getting something up and running too soon and hopefully the foggy parts will
dissolve. As for now I find it a lot easier to grok Guenter's drivers than to see the
advantages and/or disadvantages of an altmode bus :-)

@Guenter: There _is_ interest for your fusb302 driver, thank you

BR // Mats

[toc] | [prev] | [next] | [standalone]

#1598183

On 03/10/2017 02:22 PM, Mats Karrman wrote:
> On 2017-03-08 14:58, Heikki Krogerus wrote:
>
>> On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote:
>>> If I read Heikki's original suggestion I understand it like the DP driver would be
>>> responsible for AM specific USB PD/VDM communication. But wouldn't that lead
>>> to a lot of code duplication since the AM protocol is the same for all drivers of
>>> a kind?
>> No that's not what I mean. I'm still mixing your PD controller with
>> something else above, sorry about that. Your PD controller driver
>> should not ideally even need to be aware of Type-C connector, right?
>> It definitely does not need to do any USB PD communication.
>
> Right.
>
>> I would imagine you have on top of the DP controller, a mux (which
>> could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like
>> Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB
>> PD controller. The bus would be tying the mux to the Type-C port (PHY
>> or PD controller) and its partner (note that it does not tie the mux
>> to the DP controller). Please correct me if I'm wrong about your
>> hardware.
>
> No, you're correct, a discrete mux and a fusb302.
>
>> Assuming that is how your board roughly looks like, the driver for the
>> mux would be the driver for the DP altmode devices. That driver would
>> be the one converting things like the Attention messages notifying
>> about HPD into toggling of GPIOs, or what ever is needed on your
>> board, etc.
>
> OK.
>
>> The actual PD communication with VDMs should be considered as just the
>> protocol, so we probable should have "protocol drivers". For example
>> DP alternate mode VDMs and communication will always be the same
>> despite of the hardware. The DP alternate mode "protocol driver" would
>> then be tied to the alternate mode device for the partner, and that
>> driver could have its own hooks for what ever is needed, like HPD
>> signal handling, configuration changes, whatever. In any case,
>> hopefully making things easy and straightforward for the "mux driver",
>> _so that it does not need to care about the actual PD communication_.
>
> I'm digesting your and Guenter's replies and patches.
> I will try getting something up and running too soon and hopefully the foggy parts will
> dissolve. As for now I find it a lot easier to grok Guenter's drivers than to see the
> advantages and/or disadvantages of an altmode bus :-)
>
> @Guenter: There _is_ interest for your fusb302 driver, thank you
>

Ok, I'll see what I need to do to publish it.

Guenter

[toc] | [prev] | [next] | [standalone]

#1592016

On 03/02/2017 11:29 PM, 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?
>> 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.
>

Sounds quite similar to rk3399 (Samsung Chromebook Plus). I have not ported the Type-C class code
to that system yet, but it does use the extcon cros_ec driver, and DP connectivity is signaled
to the DP code through extcon events.

> 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?
>
See above. The code is available in the repository mentioned above.

Guenter

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web