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

Groups > linux.kernel > #1630286 > 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 Rajaram R <rajaram.officemail@gmail.com> - 2017-04-25 10:30 +0200
    Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-04-25 16:20 +0200
      Re: [PATCH v17 2/3] usb: USB Type-C connector class Rajaram R <rajaram.officemail@gmail.com> - 2017-04-27 08:30 +0200
        Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-04-27 20:20 +0200
          Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-04-28 13:00 +0200

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

On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
<badhri@google.com> wrote:
> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@gmail.com> wrote:
>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
>>>> <badhri@google.com> wrote:
>>>> > Thanks for the responses :)
>>>> >
>>>> > So seems like we have a plan.
>>>> >
>>>> > In Type-C connector class the checks for TYPEC_PWR_MODE_PD
>>>> > and pd_revision for both the port and the partner will be removed in
>>>> > power_role_store and the data_role_store and will be delegated
>>>> > to the low level drivers.
>>>>
>>>> It is important to remember what USB Type-C provide is mechanisms for
>>>> "TRYing" to become a particular role and not guaranteeing.
>>>>
>>>> With what device combination do you fore see we could get the desired
>>>> role with this change ?
>>>>
>>>
>>> If the partner is not PD capable, if a preferred role is specified,
>>> if the current cole does not match the preferred role, and if the request
>>> is to set the role to match the preferred role, I think it is reasonable
>>> to expect that re-establishing the connection would accomplish that if the
>>> partner supports it.
>>>
>> In this context I believe we have two different inputs as follows:
>>
>> /sys/class/typec/<port>/supported_power_roles
>> /sys/class/typec/<port>/preferred_role
>>
>> The need of preferred role is required when DRP is set in
>> supported_power_roles option.
>> Ideally a battery powered device will TRY to be SNK and a a/c plugged
>> device will TRY to be SRC
>>
>> We need to understand which non-PD device will set to DRP? In the
>
> Android Phones (actually it could be any phone which has a type-c port)
> since it can act as usb gadget (when connected to PC) or Usb host
> when connected to peripherals such as thumb drives, keyboard etc.
> Phones with smaller form factors might be thermally limited to charge
> above 15W, therefore supporting PD might be an overkill for them.
>
>> current ecosystem all legacy devices
>> will sit behind adapters which either present an Rp or Rd.
>>
>> If it is a power adapter in 5V range can either present Rp or DRP with
>> TRY.SRC and there is no role swap requirement.
>>
>> If it is a laptop port or similar with non-PD (??) DRP  there is no
>> guaranteed role swap in a non-PD mode.
>
> This is true, but following a Try.SRC or Try.SNK state machine can
> increase the chances of landing in the desired role/preferred role.

Agree and as indicated it increases only chances.

>
>> So we need to understand what non PD device will fit into this scenario ?
> Answered above.
>
>>
>>> Of course, that won't change anything if the partner does not support the
>>> desired role, but it is better than doing nothing. This is also comparable
>>> to requesting a role change from the partner if it does support PD.
>>
>> All I am highlighting is that we can only TRY and there is no
>> guaranteed role swap with Type-C
>>
>>> Do you have a better idea ?
>>>
>> If need a guaranteed role in a non-PD mode we need to set the required
>> role in supported_power_roles.
>> An understanding of scenario will help take better approach.
>
> The current Type-c connector class interface defines the support_*_roles as
> read-only nodes. Leaving that apart, I think what you are trying to say is that
> instead of running through the state machine again by switching to
> Try.SRC or Try.SNK, you are suggesting that switch from DRP to source/host
> (or) sink/device to make sure that CC is either pulled up through Rp or
> grounded through Rd so that it increases the chances of settling in the desired
> role. I do agree this, but, there is a pitfall here. Say when a DRP is
> connected to
> a pure sink/device, when the DRP switches to being a pure sink as well, then
> the port roles would not resolve at all as both would be asserting Rd on CC and

If it is a pure SNK(presenting Rd), there is no conflict and a DRP be
it TRY SRC or TRY SNK
will endup as SRC.


> therefore it might not be possible to detect a disconnect unless we have
> a VCONN powered cable. Following Try.SRC, Try.SNK state machine actually

VConn does not play any role in detection.

> takes care of this for you. When in Try.SRC or Try.SNK state, CC would either
> be pulled up or down for a specific amount of time (tCCDebounce) to check if the
> port partner is capable of switching to another role. If no port
> resolution happens
> within the timer expiry, the state machine forces the port into the
> other role and
> port resolution would eventually happen. IMHO So in short it is more safer to
> switch to between Try.SRC and Try.SNK state machine to land in a preferred role
> rather than switching a DRP to source or sink.

The only scenario i can think of now is  when connecting two mobiles
back to back. In this case if both devices
uses the same logic of switch to between Try.SRC and Try.SNK you will
not get desired result.

I guess the way we choose USB Classes(MTP or PTP or Tethering) could
be an approach where user know what he/she need.

>
>>
>>> Thanks,
>>> Guenter
>>>
>>>>
>>>> >
>>>> > TCPM code will issue hard reset in tcpm_dr_set and tcpm_pr_set if
>>>> > current_role is not same as the preferred_role.
>>>> >
>>>
>>> ... if the partner is not PD capable.
>>>
>>>> > I am going to make changes in my local kernel code base to start
>>>> > making the corresponding changes in userspace.
>>>> > Should I post-back the local kernel changes or Heikki and Geunter
>>>> > you are planning to upload them ?
>>>> >
>>>> > Thanks for the support !!
>>>> > Badhri.
>>>> >
>>>> > On Thu, Apr 20, 2017 at 5:24 AM, Heikki Krogerus
>>>> > <heikki.krogerus@linux.intel.com> wrote:
>>>> >> On Wed, Apr 19, 2017 at 10:22:47AM -0700, Badhri Jagan Sridharan wrote:
>>>> >>> On Wed, Apr 19, 2017 at 8:14 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> >>> > On Wed, Apr 19, 2017 at 07:45:00AM -0700, Badhri Jagan Sridharan wrote:
>>>> >>> >> On Wed, Apr 19, 2017 at 4:23 AM, Heikki Krogerus
>>>> >>> >> <heikki.krogerus@linux.intel.com> wrote:
>>>> >>> >> > Hi,
>>>> >>> >> >
>>>> >>> >> > On Tue, Apr 18, 2017 at 11:52:33AM -0700, Badhri Jagan Sridharan wrote:
>>>> >>> >> >> Hi Heikki,
>>>> >>> >> >>
>>>> >>> >> >> I have a question regarding the preferred_role node.
>>>> >>> >> >>
>>>> >>> >> >> +What:          /sys/class/typec/<port>/preferred_role
>>>> >>> >> >> +Date:          March 2017
>>>> >>> >> >> +Contact:       Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>>> >>> >> >> +Description:
>>>> >>> >> >> +               The user space can notify the driver about the preferred role.
>>>> >>> >> >> +               It should be handled as enabling of Try.SRC or Try.SNK, as
>>>> >>> >> >> +               defined in USB Type-C specification, in the port drivers. By
>>>> >>> >> >> +               default the preferred role should come from the platform.
>>>> >>> >> >> +
>>>> >>> >> >> +               Valid values: source, sink, none (to remove preference)
>>>> >>> >> >>
>>>> >>> >> >> What is the expected behavior when the userspace changes the
>>>> >>> >> >> preferred_role node when the port is in connected state ?
>>>> >>> >> >>
>>>> >>> >> >> 1.  the state machine re-resolves the port roles right away based on
>>>> >>> >> >> the new state machine in place ? (or)
>>>> >>> >> >
>>>> >>> >> > No! There are separate attributes for sending role swap requests.
>>>> >>> >>
>>>> >>> >> Right. But, that might not be helpful in cases when PD is not implemented.
>>>> >>> >> and Implementing PD is not mandatory according the spec :/
>>>> >>> >>
>>>> >>> >> FYI quoting from the Type-C specification release(page 24),
>>>> >>> >> role swaps are not limited to devices that only support PD.
>>>> >>> >>
>>>> >>> >> "Two independent set of mechanisms are defined to allow a USB Type-C
>>>> >>> >> DRP to functionally swap power and data roles. When USB PD is
>>>> >>> >> supported, power and data role swapping is performed as a subsequent
>>>> >>> >> step following the initial connection process. For non-PD implementations,
>>>> >>> >> power/data role swapping can optionally be dealt with as part of the initial
>>>> >>> >> connection process."
>>>> >>> >>
>>>> >>> >> But, the current interface definition actually prevents current/data role
>>>> >>> >> swaps for non-pd devices.
>>>> >>> >>
>>>> >>>
>>>> >>> > This is correct for the attribute definition, but it is not implemented
>>>> >>> > that way. Writing the attribute is only read-only for non-DRP ports.
>>>> >>>
>>>> >>> i.e. tcpm_dr_set/tcpm_pr_set at tcpm.c would return EINVAL when type
>>>> >>> is not TYPEC_PORT_DRP, is that what you are referring to ?
>>>> >>>
>>>> >>>         if (port->typec_caps.type != TYPEC_PORT_DRP) {
>>>> >>>                 ret = -EINVAL;
>>>> >>>                 goto port_unlock;
>>>> >>>         }
>>>> >>>
>>>> >>> I do agree that this is actually correct. I am referring to the case
>>>> >>> where port is
>>>> >>> dual-role-power and dual-role-data but NOT PD capable.
>>>> >>>
>>>> >>> > Given the standard, I would consider that to be intentional; it might
>>>> >>> > make sense to update the description accordingly.
>>>> >>> >
>>>> >>> > How about implementing a mechanism in the dr_set and pr_set code in tcpm
>>>> >>> > which would handle that situation ? Something along the line of
>>>> >>> >
>>>> >>> >         if (!port->pd_capable && connected && current role != desired role) {
>>>> >>> >                 reset_port();
>>>> >>> >                 goto done;
>>>> >>> >         }
>>>> >>>
>>>> >>> By "desired role" you are referring to preferred_role right ?
>>>> >>>
>>>> >>> If so yes, That's a good idea as well and it might work as long as
>>>> >>> type-c connector
>>>> >>> class allows the call to reach tcpm code :) But the current connector
>>>> >>> class code does
>>>> >>> not allow that because the power_role and data_role nodes are defined that way.
>>>> >>
>>>> >> Well, the data_role does not limit the requests from reaching the low
>>>> >> level drivers, but..
>>>> >>
>>>> >>> port->cap->pd_revision and the port->pwr_opmode check in the below code
>>>> >>> stub have to removed/refactored to make current_role/data_role writes to
>>>> >>> reach the tcpm code.
>>>> >>>
>>>> >>> +static ssize_t power_role_store(struct device *dev,
>>>> >>> + struct device_attribute *attr,
>>>> >>> + const char *buf, size_t size)
>>>> >>> +{
>>>> >>> + struct typec_port *port = to_typec_port(dev);
>>>> >>> + int ret = size;
>>>> >>> +
>>>> >>> + if (!port->cap->pd_revision) {
>>>> >>> + dev_dbg(dev, "USB Power Delivery not supported\n");
>>>> >>> + return -EOPNOTSUPP;
>>>> >>> + }
>>>> >>> +
>>>> >>> + if (!port->cap->pr_set) {
>>>> >>> + dev_dbg(dev, "power role swapping not supported\n");
>>>> >>> + return -EOPNOTSUPP;
>>>> >>> + }
>>>> >>> +
>>>> >>> + if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
>>>> >>> + dev_dbg(dev, "partner unable to swap power role\n");
>>>> >>> + return -EIO;
>>>> >>> + }
>>>> >>> +
>>>> >>> + ret = sysfs_match_string(typec_roles, buf);
>>>> >>> + if (ret < 0)
>>>> >>> + return ret;
>>>> >>> +
>>>> >>> + ret = port->cap->pr_set(port->cap, ret);
>>>> >>> + if (ret)
>>>> >>> + return ret;
>>>> >>> +
>>>> >>> + return size;
>>>> >>> +}
>>>> >>
>>>> >> .. yes. The power_role_store() does indeed need to be refactored. The
>>>> >> PD requirement should only be applied to Type-C spec versions < 1.2,
>>>> >> or removed completely. I would be happy to leave the checks to the low
>>>> >> level drivers.
>>>> >>
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> --
>>>> >> heikki
>>>> > --
>>>> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>>> > the body of a message to majordomo@vger.kernel.org
>>>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [next] | [standalone]

#1630546

On 04/25/2017 01:26 AM, Rajaram R wrote:
> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
> <badhri@google.com> wrote:
>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@gmail.com> wrote:
>>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
>>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
>>>>> <badhri@google.com> wrote:
>>>>>> Thanks for the responses :)
>>>>>>
>>>>>> So seems like we have a plan.
>>>>>>
>>>>>> In Type-C connector class the checks for TYPEC_PWR_MODE_PD
>>>>>> and pd_revision for both the port and the partner will be removed in
>>>>>> power_role_store and the data_role_store and will be delegated
>>>>>> to the low level drivers.
>>>>>
>>>>> It is important to remember what USB Type-C provide is mechanisms for
>>>>> "TRYing" to become a particular role and not guaranteeing.
>>>>>
>>>>> With what device combination do you fore see we could get the desired
>>>>> role with this change ?
>>>>>
>>>>
>>>> If the partner is not PD capable, if a preferred role is specified,
>>>> if the current cole does not match the preferred role, and if the request
>>>> is to set the role to match the preferred role, I think it is reasonable
>>>> to expect that re-establishing the connection would accomplish that if the
>>>> partner supports it.
>>>>
>>> In this context I believe we have two different inputs as follows:
>>>
>>> /sys/class/typec/<port>/supported_power_roles
>>> /sys/class/typec/<port>/preferred_role
>>>
>>> The need of preferred role is required when DRP is set in
>>> supported_power_roles option.
>>> Ideally a battery powered device will TRY to be SNK and a a/c plugged
>>> device will TRY to be SRC
>>>
>>> We need to understand which non-PD device will set to DRP? In the
>>
>> Android Phones (actually it could be any phone which has a type-c port)
>> since it can act as usb gadget (when connected to PC) or Usb host
>> when connected to peripherals such as thumb drives, keyboard etc.
>> Phones with smaller form factors might be thermally limited to charge
>> above 15W, therefore supporting PD might be an overkill for them.
>>
>>> current ecosystem all legacy devices
>>> will sit behind adapters which either present an Rp or Rd.
>>>
>>> If it is a power adapter in 5V range can either present Rp or DRP with
>>> TRY.SRC and there is no role swap requirement.
>>>
>>> If it is a laptop port or similar with non-PD (??) DRP  there is no
>>> guaranteed role swap in a non-PD mode.
>>
>> This is true, but following a Try.SRC or Try.SNK state machine can
>> increase the chances of landing in the desired role/preferred role.
>
> Agree and as indicated it increases only chances.
>

FWIW, this is pretty much the same as requesting a role change using PD.
Based on my experience with various devices, the chance for that to succeed
isn't really that high either.

I am not really sure I understand your problem with using Try.{SRC,SNK}
to trigger (or attempt to trigger) a role change. Can we take a step back,
and can you explain ?

Thanks,
Guenter

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

#1631890

On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 04/25/2017 01:26 AM, Rajaram R wrote:
>>
>> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
>> <badhri@google.com> wrote:
>>>
>>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@gmail.com>
>>> wrote:
>>>>
>>>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@roeck-us.net>
>>>> wrote:
>>>>>
>>>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
>>>>>>
>>>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
>>>>>> <badhri@google.com> wrote:
>>>>>>>
>>>>>>> Thanks for the responses :)
>>>>>>>
>>>>>>> So seems like we have a plan.
>>>>>>>
>>>>>>> In Type-C connector class the checks for TYPEC_PWR_MODE_PD
>>>>>>> and pd_revision for both the port and the partner will be removed in
>>>>>>> power_role_store and the data_role_store and will be delegated
>>>>>>> to the low level drivers.
>>>>>>
>>>>>>
>>>>>> It is important to remember what USB Type-C provide is mechanisms for
>>>>>> "TRYing" to become a particular role and not guaranteeing.
>>>>>>
>>>>>> With what device combination do you fore see we could get the desired
>>>>>> role with this change ?
>>>>>>
>>>>>
>>>>> If the partner is not PD capable, if a preferred role is specified,
>>>>> if the current cole does not match the preferred role, and if the
>>>>> request
>>>>> is to set the role to match the preferred role, I think it is
>>>>> reasonable
>>>>> to expect that re-establishing the connection would accomplish that if
>>>>> the
>>>>> partner supports it.
>>>>>
>>>> In this context I believe we have two different inputs as follows:
>>>>
>>>> /sys/class/typec/<port>/supported_power_roles
>>>> /sys/class/typec/<port>/preferred_role
>>>>
>>>> The need of preferred role is required when DRP is set in
>>>> supported_power_roles option.
>>>> Ideally a battery powered device will TRY to be SNK and a a/c plugged
>>>> device will TRY to be SRC
>>>>
>>>> We need to understand which non-PD device will set to DRP? In the
>>>
>>>
>>> Android Phones (actually it could be any phone which has a type-c port)
>>> since it can act as usb gadget (when connected to PC) or Usb host
>>> when connected to peripherals such as thumb drives, keyboard etc.
>>> Phones with smaller form factors might be thermally limited to charge
>>> above 15W, therefore supporting PD might be an overkill for them.
>>>
>>>> current ecosystem all legacy devices
>>>> will sit behind adapters which either present an Rp or Rd.
>>>>
>>>> If it is a power adapter in 5V range can either present Rp or DRP with
>>>> TRY.SRC and there is no role swap requirement.
>>>>
>>>> If it is a laptop port or similar with non-PD (??) DRP  there is no
>>>> guaranteed role swap in a non-PD mode.
>>>
>>>
>>> This is true, but following a Try.SRC or Try.SNK state machine can
>>> increase the chances of landing in the desired role/preferred role.
>>
>>
>> Agree and as indicated it increases only chances.
>>
>
> FWIW, this is pretty much the same as requesting a role change using PD.
> Based on my experience with various devices, the chance for that to succeed
> isn't really that high either.
>
> I am not really sure I understand your problem with using Try.{SRC,SNK}
> to trigger (or attempt to trigger) a role change. Can we take a step back,
> and can you explain ?

The parameters required for a type-c connection is defined as follows
and will have a default value.

/sys/class/typec/<port>/supported_power_roles
/sys/class/typec/<port>/preferred_role

When two DRP devices are connected and for which we have
preferred_role which provides input on the preference, In a DRP mode
we have randomness in the mode of connection and hence we require role
swap mechanisms. A Type-C only device cannot role swap as this is
valid only in PD operation.

#  Question was how to choose a particular role in non-PD mode. Only
way to have a deterministic role in a non-PD mode is to set expected
supported_role of choice rather than DRP.

# As part of the solution suggested, checking of roles and triggering
role swaps has to be done by the policy manager(PM) and delinked from
Policy Engine. I guess the policy manager is at user space?.

I do not have the complete git repo and may be i could be missing
something. If this is in any public git please let me know

>
> Thanks,
> Guenter
>

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

#1632302

On Thu, Apr 27, 2017 at 11:50:12AM +0530, Rajaram R wrote:
> On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On 04/25/2017 01:26 AM, Rajaram R wrote:
> >>
> >> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
> >> <badhri@google.com> wrote:
> >>>
> >>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@gmail.com>
> >>> wrote:
> >>>>
> >>>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@roeck-us.net>
> >>>> wrote:
> >>>>>
> >>>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
> >>>>>>
> >>>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
> >>>>>> <badhri@google.com> wrote:
> >>>>>>>
> >>>>>>> Thanks for the responses :)
> >>>>>>>
> >>>>>>> So seems like we have a plan.
> >>>>>>>
> >>>>>>> In Type-C connector class the checks for TYPEC_PWR_MODE_PD
> >>>>>>> and pd_revision for both the port and the partner will be removed in
> >>>>>>> power_role_store and the data_role_store and will be delegated
> >>>>>>> to the low level drivers.
> >>>>>>
> >>>>>>
> >>>>>> It is important to remember what USB Type-C provide is mechanisms for
> >>>>>> "TRYing" to become a particular role and not guaranteeing.
> >>>>>>
> >>>>>> With what device combination do you fore see we could get the desired
> >>>>>> role with this change ?
> >>>>>>
> >>>>>
> >>>>> If the partner is not PD capable, if a preferred role is specified,
> >>>>> if the current cole does not match the preferred role, and if the
> >>>>> request
> >>>>> is to set the role to match the preferred role, I think it is
> >>>>> reasonable
> >>>>> to expect that re-establishing the connection would accomplish that if
> >>>>> the
> >>>>> partner supports it.
> >>>>>
> >>>> In this context I believe we have two different inputs as follows:
> >>>>
> >>>> /sys/class/typec/<port>/supported_power_roles
> >>>> /sys/class/typec/<port>/preferred_role
> >>>>
> >>>> The need of preferred role is required when DRP is set in
> >>>> supported_power_roles option.
> >>>> Ideally a battery powered device will TRY to be SNK and a a/c plugged
> >>>> device will TRY to be SRC
> >>>>
> >>>> We need to understand which non-PD device will set to DRP? In the
> >>>
> >>>
> >>> Android Phones (actually it could be any phone which has a type-c port)
> >>> since it can act as usb gadget (when connected to PC) or Usb host
> >>> when connected to peripherals such as thumb drives, keyboard etc.
> >>> Phones with smaller form factors might be thermally limited to charge
> >>> above 15W, therefore supporting PD might be an overkill for them.
> >>>
> >>>> current ecosystem all legacy devices
> >>>> will sit behind adapters which either present an Rp or Rd.
> >>>>
> >>>> If it is a power adapter in 5V range can either present Rp or DRP with
> >>>> TRY.SRC and there is no role swap requirement.
> >>>>
> >>>> If it is a laptop port or similar with non-PD (??) DRP  there is no
> >>>> guaranteed role swap in a non-PD mode.
> >>>
> >>>
> >>> This is true, but following a Try.SRC or Try.SNK state machine can
> >>> increase the chances of landing in the desired role/preferred role.
> >>
> >>
> >> Agree and as indicated it increases only chances.
> >>
> >
> > FWIW, this is pretty much the same as requesting a role change using PD.
> > Based on my experience with various devices, the chance for that to succeed
> > isn't really that high either.
> >
> > I am not really sure I understand your problem with using Try.{SRC,SNK}
> > to trigger (or attempt to trigger) a role change. Can we take a step back,
> > and can you explain ?
> 
> The parameters required for a type-c connection is defined as follows
> and will have a default value.
> 
> /sys/class/typec/<port>/supported_power_roles

I don't see that attribute (it is implied in the power_role attribute).
It only existed in an earlier version of the driver.

Also, the attribute (when it existed) listed the roles supported
by the port, not an administrative restriction of supported roles.

> /sys/class/typec/<port>/preferred_role
> 
> When two DRP devices are connected and for which we have
> preferred_role which provides input on the preference, In a DRP mode
> we have randomness in the mode of connection and hence we require role
> swap mechanisms. A Type-C only device cannot role swap as this is
> valid only in PD operation.
> 

The same is true for non-PD connections. Also, PD doesn't solve the problem
if both ends have the same source/sink preference. The result is still
randomness. To resolve that randomness, one of the connection partners
would have to give up its preference. That is quite independent of PD
support.

> #  Question was how to choose a particular role in non-PD mode. Only
> way to have a deterministic role in a non-PD mode is to set expected
> supported_role of choice rather than DRP.
> 
> # As part of the solution suggested, checking of roles and triggering
> role swaps has to be done by the policy manager(PM) and delinked from
> Policy Engine. I guess the policy manager is at user space?.
> 
> I do not have the complete git repo and may be i could be missing
> something. If this is in any public git please let me know
> 

Even if a device does support PD, there is no guarantee that a power role
swap is successful. That depends on the policy set by the partner, and
for all practical purposes it also depends on the quality and stability
of the PD protocol implementation on both ends. As mentioned above, if
both ends have the same preferred role, the result is still randomness
and requires manual intervention by the user if the "other" role is
desired.

It seems to me that we are discussing if we should do as good as we can
or if we should only implement what can be guaranteed. I strongly favor
the first approach. I also think we should not preclude that approach in
the kernel implementation. It should be left to a specific policy manager
implementation to decide if a given device should be a DRP or source-only
or sink-only, independent of the question if PD is supported on either
end of a connection.

If a given implementation wants to restrict available port modes, it
can do so by providing acceptable port capabilities (ie DRP or source
or sink) when registering the port with the infrastructure.

I think you are suggesting that there should be a means to override port
capabilities (more specifically, permitted roles) after port registration.
That may be a matter for discussion, but it is a separate issue.
Also, I am not sure if it was already discussed. Does anyone remember ?

Thanks,
Guenter

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

#1632800

On Thu, Apr 27, 2017 at 11:10:55AM -0700, Guenter Roeck wrote:
> On Thu, Apr 27, 2017 at 11:50:12AM +0530, Rajaram R wrote:
> > On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > On 04/25/2017 01:26 AM, Rajaram R wrote:
> > >>
> > >> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
> > >> <badhri@google.com> wrote:
> > >>>
> > >>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@roeck-us.net>
> > >>>> wrote:
> > >>>>>
> > >>>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
> > >>>>>>
> > >>>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
> > >>>>>> <badhri@google.com> wrote:
> > >>>>>>>
> > >>>>>>> Thanks for the responses :)
> > >>>>>>>
> > >>>>>>> So seems like we have a plan.
> > >>>>>>>
> > >>>>>>> In Type-C connector class the checks for TYPEC_PWR_MODE_PD
> > >>>>>>> and pd_revision for both the port and the partner will be removed in
> > >>>>>>> power_role_store and the data_role_store and will be delegated
> > >>>>>>> to the low level drivers.
> > >>>>>>
> > >>>>>>
> > >>>>>> It is important to remember what USB Type-C provide is mechanisms for
> > >>>>>> "TRYing" to become a particular role and not guaranteeing.
> > >>>>>>
> > >>>>>> With what device combination do you fore see we could get the desired
> > >>>>>> role with this change ?
> > >>>>>>
> > >>>>>
> > >>>>> If the partner is not PD capable, if a preferred role is specified,
> > >>>>> if the current cole does not match the preferred role, and if the
> > >>>>> request
> > >>>>> is to set the role to match the preferred role, I think it is
> > >>>>> reasonable
> > >>>>> to expect that re-establishing the connection would accomplish that if
> > >>>>> the
> > >>>>> partner supports it.
> > >>>>>
> > >>>> In this context I believe we have two different inputs as follows:
> > >>>>
> > >>>> /sys/class/typec/<port>/supported_power_roles
> > >>>> /sys/class/typec/<port>/preferred_role
> > >>>>
> > >>>> The need of preferred role is required when DRP is set in
> > >>>> supported_power_roles option.
> > >>>> Ideally a battery powered device will TRY to be SNK and a a/c plugged
> > >>>> device will TRY to be SRC
> > >>>>
> > >>>> We need to understand which non-PD device will set to DRP? In the
> > >>>
> > >>>
> > >>> Android Phones (actually it could be any phone which has a type-c port)
> > >>> since it can act as usb gadget (when connected to PC) or Usb host
> > >>> when connected to peripherals such as thumb drives, keyboard etc.
> > >>> Phones with smaller form factors might be thermally limited to charge
> > >>> above 15W, therefore supporting PD might be an overkill for them.
> > >>>
> > >>>> current ecosystem all legacy devices
> > >>>> will sit behind adapters which either present an Rp or Rd.
> > >>>>
> > >>>> If it is a power adapter in 5V range can either present Rp or DRP with
> > >>>> TRY.SRC and there is no role swap requirement.
> > >>>>
> > >>>> If it is a laptop port or similar with non-PD (??) DRP  there is no
> > >>>> guaranteed role swap in a non-PD mode.
> > >>>
> > >>>
> > >>> This is true, but following a Try.SRC or Try.SNK state machine can
> > >>> increase the chances of landing in the desired role/preferred role.
> > >>
> > >>
> > >> Agree and as indicated it increases only chances.
> > >>
> > >
> > > FWIW, this is pretty much the same as requesting a role change using PD.
> > > Based on my experience with various devices, the chance for that to succeed
> > > isn't really that high either.
> > >
> > > I am not really sure I understand your problem with using Try.{SRC,SNK}
> > > to trigger (or attempt to trigger) a role change. Can we take a step back,
> > > and can you explain ?
> > 
> > The parameters required for a type-c connection is defined as follows
> > and will have a default value.
> > 
> > /sys/class/typec/<port>/supported_power_roles
> 
> I don't see that attribute (it is implied in the power_role attribute).
> It only existed in an earlier version of the driver.
> 
> Also, the attribute (when it existed) listed the roles supported
> by the port, not an administrative restriction of supported roles.
> 
> > /sys/class/typec/<port>/preferred_role
> > 
> > When two DRP devices are connected and for which we have
> > preferred_role which provides input on the preference, In a DRP mode
> > we have randomness in the mode of connection and hence we require role
> > swap mechanisms. A Type-C only device cannot role swap as this is
> > valid only in PD operation.
> > 
> 
> The same is true for non-PD connections. Also, PD doesn't solve the problem
> if both ends have the same source/sink preference. The result is still
> randomness. To resolve that randomness, one of the connection partners
> would have to give up its preference. That is quite independent of PD
> support.
> 
> > #  Question was how to choose a particular role in non-PD mode. Only
> > way to have a deterministic role in a non-PD mode is to set expected
> > supported_role of choice rather than DRP.
> > 
> > # As part of the solution suggested, checking of roles and triggering
> > role swaps has to be done by the policy manager(PM) and delinked from
> > Policy Engine. I guess the policy manager is at user space?.
> > 
> > I do not have the complete git repo and may be i could be missing
> > something. If this is in any public git please let me know
> > 
> 
> Even if a device does support PD, there is no guarantee that a power role
> swap is successful. That depends on the policy set by the partner, and
> for all practical purposes it also depends on the quality and stability
> of the PD protocol implementation on both ends. As mentioned above, if
> both ends have the same preferred role, the result is still randomness
> and requires manual intervention by the user if the "other" role is
> desired.
> 
> It seems to me that we are discussing if we should do as good as we can
> or if we should only implement what can be guaranteed. I strongly favor
> the first approach. I also think we should not preclude that approach in
> the kernel implementation. It should be left to a specific policy manager
> implementation to decide if a given device should be a DRP or source-only
> or sink-only, independent of the question if PD is supported on either
> end of a connection.
> 
> If a given implementation wants to restrict available port modes, it
> can do so by providing acceptable port capabilities (ie DRP or source
> or sink) when registering the port with the infrastructure.
> 
> I think you are suggesting that there should be a means to override port
> capabilities (more specifically, permitted roles) after port registration.
> That may be a matter for discussion, but it is a separate issue.

That is how also I see it.

> Also, I am not sure if it was already discussed. Does anyone remember ?

Yes, I did propose an attribute that would allow fixing the role of a
port to either sink or source at one point. I don't remember what was
the reason I ended up dropping that proposal - I need to go through my
archives - but I think it was seen as a feature that, if needed, can be
added later by adding a new attribute file for it.

So if that is the functionality you want, please start a new thread
and propose the new attribute. At least don't try to modify the
behaviour of the existing ones because of it.


Thank you,

-- 
heikki

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web