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

[Guenter Roeck]

On 04/25/2017 01:26 AM, Rajaram R wrote:
> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
> <badhri@xxxxxxxxxx> wrote:
> > On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@xxxxxxxxx> wrote:
> > > On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@xxxxxxxxxxxx> 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@xxxxxxxxxx> 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