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

\
 
 \ /
  Last update: 2017-04-25 16:11    [W:0.880 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site