Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162100AbdD0GUe (ORCPT ); Thu, 27 Apr 2017 02:20:34 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35877 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162063AbdD0GUU (ORCPT ); Thu, 27 Apr 2017 02:20:20 -0400 MIME-Version: 1.0 In-Reply-To: <9485c5e8-6b79-0b93-d0e9-e7880aea9741@roeck-us.net> References: <68817c44-d880-581a-e9f5-12845b9215eb@gmail.com>

<20170419112323.GD24062@kuha.fi.intel.com> <20170419151401.GA14036@roeck-us.net> <20170420122417.GB4769@kuha.fi.intel.com>

<20170421164323.GA31344@roeck-us.net> <9485c5e8-6b79-0b93-d0e9-e7880aea9741@roeck-us.net> From: Rajaram R Date: Thu, 27 Apr 2017 11:50:12 +0530 Message-ID: Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class To: Guenter Roeck Cc: Badhri Jagan Sridharan , Heikki Krogerus , Oliver Neukum , Mats Karrman , Greg KH , Felipe Balbi , LKML , USB Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4349 Lines: 114 On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck wrote: > On 04/25/2017 01:26 AM, Rajaram R wrote: >> >> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan >> wrote: >>> >>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R >>> wrote: >>>> >>>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck >>>> 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 >>>>>> 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//supported_power_roles >>>> /sys/class/typec//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//supported_power_roles /sys/class/typec//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 >