Messages in this thread | | | Subject | Re: [PATCH v17 2/3] usb: USB Type-C connector class | From | Guenter Roeck <> | Date | Tue, 25 Apr 2017 07:10:48 -0700 |
| |
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
| |