lkml.org 
[lkml]   [2018]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/2] typec: tcpm: Add option to maintain current limit at Vsafe5V
    + Guenter
    On Thu, Sep 13, 2018 at 6:43 AM Badhri Jagan Sridharan
    <badhri@google.com> wrote:
    >
    > On Wed, Sep 12, 2018 at 11:39 PM Jack Pham <jackp@codeaurora.org> wrote:
    > >
    > > Hello Badhri,
    > >
    > > On Wed, Sep 12, 2018 at 07:11:13PM -0700, Badhri Jagan Sridharan wrote:
    > > > During hard reset, TCPM turns off the charging path.
    > > > The spec provides an option for Sink to either drop to vSafe5V or vSafe0V.
    > >
    > > This doesn't make sense. By definition the sink isn't sourcing VBUS, so
    > > how can it control whether to allow the voltage to be 5V or 0V?
    >
    > The way I understand it, this is for the current limits that can be
    > set on the Sink side.
    > During hard reset, sink has to fallback to VSafe5V or VSafe0V if
    > higher pd contract was negotiated.
    >
    > >
    > >
    > > > From USB_PD_R3_0
    > > > 2.6.2 Sink Operation
    > > > ..
    > > > Serious errors are handled by Hard Reset Signaling issued by either Port
    > > > Partner. A Hard Reset:
    > > > resets protocol as for a Soft Reset but also returns the power supply to
    > > > USB Default Operation (vSafe0V or vSafe5V output) in order to protect the
    > > > Sink.
    > >
    > > I can see how the wording here "vSafe0V *or* vSafe5V" is misleading, as
    > > I think it actually is both. In later parts of the spec, the source's
    > > VBUS behavior is well defined in that it must first drop to vSafe0V
    > > and then return to vSafe5V. Please refer to section 7.1.5.
    >
    >
    > Yeah thats for the source. But for sink, Say if the source isnt PD, then,
    > sink initiated hard resets happen during the connection. Sink would hard reset
    > couple of times before deeming that the partner is non PD. When connected
    > to Type-A ports/non-pd partner, vbus is not going to likely drop so there isnt
    > a reason to setcharge to false or drop the input current limit. Do you agree ?
    >
    > >
    > >
    > > > Add a config option to tcpc_dev and let the device specific driver decide
    > > > what needs to be done.
    > > >
    > > > Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
    > > > ---
    > > > drivers/usb/typec/tcpm.c | 7 ++++++-
    > > > include/linux/usb/tcpm.h | 1 +
    > > > 2 files changed, 7 insertions(+), 1 deletion(-)
    > > >
    > > > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
    > > > index a4e0c027a2a9..350d1a7c4543 100644
    > > > --- a/drivers/usb/typec/tcpm.c
    > > > +++ b/drivers/usb/typec/tcpm.c
    > > > @@ -3269,7 +3269,12 @@ static void run_state_machine(struct tcpm_port *port)
    > > > case SNK_HARD_RESET_SINK_OFF:
    > > > memset(&port->pps_data, 0, sizeof(port->pps_data));
    > > > tcpm_set_vconn(port, false);
    > > > - tcpm_set_charge(port, false);
    > > > + if (port->tcpc->config->vsafe_5v_hard_reset)
    > >
    > > Therefore I think this config option doesn't make sense.
    > >
    > > > + tcpm_set_current_limit(port,
    > > > + tcpm_get_current_limit(port),
    > > > + 5000);
    > >
    > > But I do think this might still be useful at least in ensuring the sink
    > > returns to drawing only default power during the transition before
    > > re-establishing a contract. Given that the sink can't control when
    > > exactly VBUS will go to 0V, is it ok to call set_current_limit() even if
    > > VBUS is momentarily 0V, so at least it is in preparation for when VBUS
    > > turns back on? Or would it be safer to do it during the
    > > SNK_HARD_RESET_SINK_ON state after we know VBUS is back to vSafe5V?
    >
    > IMHO Doing it in SNK_HARD_RESET_SINK_ON makes more sense when
    > vsafe_5v_hard_reset
    > is not set.
    >
    > >
    > >
    > > > + else
    > > > + tcpm_set_charge(port, false);
    > >
    > > Regards,
    > > Jack
    > > --
    > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
    > > a Linux Foundation Collaborative Project

    \
     
     \ /
      Last update: 2018-09-13 16:13    [W:3.869 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site