lkml.org 
[lkml]   [2017]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v17 2/3] usb: USB Type-C connector class
    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
    >

    \
     
     \ /
      Last update: 2017-04-27 08:21    [W:2.263 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site