From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [2/2] typec: tcpm: Add option to maintain current limit at Vsafe5V From: Jack Pham Message-Id: <20180913170746.GB13306@jackp-linux.qualcomm.com> Date: Thu, 13 Sep 2018 10:07:46 -0700 To: Badhri Jagan Sridharan Cc: Heikki Krogerus , Greg Kroah-Hartman , USB , LKML , Guenter Roeck List-ID: T24gVGh1LCBTZXAgMTMsIDIwMTggYXQgNjo0MyBBTSBCYWRocmkgSmFnYW4gU3JpZGhhcmFuCjxi YWRocmlAZ29vZ2xlLmNvbT4gd3JvdGU6Cj4KPiBPbiBXZWQsIFNlcCAxMiwgMjAxOCBhdCAxMToz OSBQTSBKYWNrIFBoYW0gPGphY2twQGNvZGVhdXJvcmEub3JnPiB3cm90ZToKPiA+Cj4gPiBIZWxs byBCYWRocmksCj4gPgo+ID4gT24gV2VkLCBTZXAgMTIsIDIwMTggYXQgMDc6MTE6MTNQTSAtMDcw MCwgQmFkaHJpIEphZ2FuIFNyaWRoYXJhbiB3cm90ZToKPiA+ID4gRHVyaW5nIGhhcmQgcmVzZXQs IFRDUE0gdHVybnMgb2ZmIHRoZSBjaGFyZ2luZyBwYXRoLgo+ID4gPiBUaGUgc3BlYyBwcm92aWRl cyBhbiBvcHRpb24gZm9yIFNpbmsgdG8gZWl0aGVyIGRyb3AgdG8gdlNhZmU1ViBvciB2U2FmZTBW Lgo+ID4KPiA+IFRoaXMgZG9lc24ndCBtYWtlIHNlbnNlLiBCeSBkZWZpbml0aW9uIHRoZSBzaW5r IGlzbid0IHNvdXJjaW5nIFZCVVMsIHNvCj4gPiBob3cgY2FuIGl0IGNvbnRyb2wgd2hldGhlciB0 byBhbGxvdyB0aGUgdm9sdGFnZSB0byBiZSA1ViBvciAwVj8KPgo+IFRoZSB3YXkgSSB1bmRlcnN0 YW5kIGl0LCB0aGlzIGlzIGZvciB0aGUgY3VycmVudCBsaW1pdHMgdGhhdCBjYW4gYmUKPiBzZXQg b24gdGhlIFNpbmsgc2lkZS4KPiBEdXJpbmcgaGFyZCByZXNldCwgc2luayBoYXMgdG8gZmFsbGJh Y2sgdG8gVlNhZmU1ViBvciBWU2FmZTBWIGlmCj4gaGlnaGVyIHBkIGNvbnRyYWN0IHdhcyBuZWdv dGlhdGVkLgoKT2ssIHlvdSBhcmUgdGFsa2luZyBhYm91dCBzaW5rIGN1cnJlbnQgZHJhdyBsaW1p dHMgYnV0IHZTYWZlezAsNX1WIGFyZQp2b2x0YWdlIGRlZmluaXRpb25zIHNvIHRoZXNlIGFyZSBv cnRob2dvbmFsLiBBZ2FpbiwgdGhlIHNpbmsgY2FuJ3QKZGlyZWN0bHkgZGljdGF0ZSB0aGUgdm9s dGFnZSB0aGF0J3MgYmVpbmcgc291cmNlZCBzbyBJIGRvbid0IHNlZSBob3cgaXQKaGFzIGEgY2hv aWNlIGhlcmUuIElmIGEgUEQgY29udHJhY3Qgd2FzIG5lZ290aWF0ZWQgZm9yIGdyZWF0ZXIgdGhh biA1VgphbmQgYSBoYXJkIHJlc2V0IGhhcHBlbnMgdGhlbiB5ZXMgdGhlIHZvbHRhZ2Ugd291bGQg ZmFsbCB0byAwViBhbmQgdGhlbgpyaXNlIGJhY2sgdG8gNVYgYW5kIGR1cmluZyB0aGlzIHRpbWUg c2luayBuZWVkcyB0byBkcmF3IGFwcHJvcHJpYXRlCmN1cnJlbnQuCgo+ID4gPiBGcm9tIFVTQl9Q RF9SM18wCj4gPiA+IDIuNi4yIFNpbmsgT3BlcmF0aW9uCj4gPiA+IC4uCj4gPiA+IFNlcmlvdXMg ZXJyb3JzIGFyZSBoYW5kbGVkIGJ5IEhhcmQgUmVzZXQgU2lnbmFsaW5nIGlzc3VlZCBieSBlaXRo ZXIgUG9ydAo+ID4gPiBQYXJ0bmVyLiBBIEhhcmQgUmVzZXQ6Cj4gPiA+IHJlc2V0cyBwcm90b2Nv bCBhcyBmb3IgYSBTb2Z0IFJlc2V0IGJ1dCBhbHNvIHJldHVybnMgdGhlIHBvd2VyIHN1cHBseSB0 bwo+ID4gPiBVU0IgRGVmYXVsdCBPcGVyYXRpb24gKHZTYWZlMFYgb3IgdlNhZmU1ViBvdXRwdXQp IGluIG9yZGVyIHRvIHByb3RlY3QgdGhlCj4gPiA+IFNpbmsuCj4gPgo+ID4gSSBjYW4gc2VlIGhv dyB0aGUgd29yZGluZyBoZXJlICJ2U2FmZTBWICpvciogdlNhZmU1ViIgaXMgbWlzbGVhZGluZywg YXMKPiA+IEkgdGhpbmsgaXQgYWN0dWFsbHkgaXMgYm90aC4gSW4gbGF0ZXIgcGFydHMgb2YgdGhl IHNwZWMsIHRoZSBzb3VyY2Uncwo+ID4gVkJVUyBiZWhhdmlvciBpcyB3ZWxsIGRlZmluZWQgaW4g dGhhdCBpdCBtdXN0IGZpcnN0IGRyb3AgdG8gdlNhZmUwVgo+ID4gYW5kIHRoZW4gcmV0dXJuIHRv IHZTYWZlNVYuIFBsZWFzZSByZWZlciB0byBzZWN0aW9uIDcuMS41Lgo+Cj4KPiBZZWFoIHRoYXRz IGZvciB0aGUgc291cmNlLiBCdXQgZm9yIHNpbmssIFNheSBpZiB0aGUgc291cmNlIGlzbnQgUEQs IHRoZW4sCj4gc2luayBpbml0aWF0ZWQgaGFyZCByZXNldHMgaGFwcGVuIGR1cmluZyB0aGUgY29u bmVjdGlvbi4gU2luayB3b3VsZCBoYXJkIHJlc2V0Cj4gY291cGxlIG9mIHRpbWVzIGJlZm9yZSBk ZWVtaW5nIHRoYXQgdGhlIHBhcnRuZXIgaXMgbm9uIFBELiBXaGVuIGNvbm5lY3RlZAo+IHRvIFR5 cGUtQSBwb3J0cy9ub24tcGQgcGFydG5lciwgdmJ1cyBpcyBub3QgZ29pbmcgdG8gbGlrZWx5IGRy b3Agc28gdGhlcmUgaXNudAo+IGEgcmVhc29uIHRvIHNldGNoYXJnZSB0byBmYWxzZSBvciBkcm9w IHRoZSBpbnB1dCBjdXJyZW50IGxpbWl0LiBEbyB5b3UgYWdyZWUgPwoKU3VyZSB0aGF0IG1ha2Vz IHNlbnNlLiBJbiB0aGlzIGNhc2UgSSB3b25kZXIgaWYgVENQTSBldmVuIG5lZWRzIHRvIGNhbGwK c2V0X2NoYXJnZShmYWxzZSkgY29uc2lkZXJpbmcgaXQgZG9lcyBub3QgeWV0IGtub3cgaWYgdGhl IHBhcnRuZXIgaXMgUEQKY2FwYWJsZSBvciBub3QuIEZvciBzdXJlLCBpZiB0aGUgcGFydG5lciBp cyBQRCBjYXBhYmxlIGFuZCBjb250cmFjdCBoYWQKYmVlbiBwcmV2aW91c2x5IGVzdGFibGlzaGVk LCB3ZSdkIGRlZmluaXRlbHkgbmVlZCB0byBzZXRfY3VycmVudF9saW1pdCgpCnRvIGRlZmF1bHQg bGV2ZWxzIGFuZC9vciB0dXJuIG9mZiBjaGFyZ2luZy4KCkJ1dCBpbiB0aGUgY2FzZSBvZiBoYXJk IHJlc2V0IGF0dGVtcHRzIHRvIHRyeSB0byBkZXRlcm1pbmUgaWYgdGhlIHNvdXJjZQp3aWxsIHNl bmQgaXRzIGNhcGFiaWxpdGllcyAodGhlcmVieSBiZWluZyBQRCBjYXBhYmxlKSwgd291bGRuJ3Qg dGhlCmluaXRpYWwgZGVmYXVsdCBjdXJyZW50IGxpbWl0cyBzdGlsbCBiZSBpbiBwbGFjZT8gSSB0 aGluayB0aGlzIGlzIHRoZQpwb2ludCB5b3UncmUgdHJ5aW5nIHRvIG1ha2UsIHRoYXQgdGhlcmUg aXMgbm8gbmVlZCB0byBkaXNydXB0IGNoYXJnaW5nCmlmIGEgaGFyZCByZXNldCBpcyBub3QgZ29p bmcgdG8gY2F1c2UgVkJVUyB0byByZXNldC4KClRvIG1lIGl0IHNvdW5kcyBsaWtlIHdoYXQgeW91 J3JlIHRyeWluZyB0byBkbyBtYWtlcyBzZW5zZSBvbmx5IGlmIHlvdQpjYW4gbWFrZSBhIHJ1bi10 aW1lIGRldGVybWluYXRpb24gb2YgYSBwYXJ0bmVyJ3MgUEQgY2FwYWJpbGl0eSwgYW5kIG5vdApi YXNlZCBvbiBhIGNvbmZpZyBvcHRpb24uCgpUaGFua3MsCkphY2sK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E412FC6183 for ; Thu, 13 Sep 2018 17:35:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0AB7C21797 for ; Thu, 13 Sep 2018 17:07:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="XLlCTUXj"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="XLlCTUXj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AB7C21797 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728622AbeIMWSM (ORCPT ); Thu, 13 Sep 2018 18:18:12 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:51500 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727384AbeIMWSM (ORCPT ); Thu, 13 Sep 2018 18:18:12 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 9362B6053B; Thu, 13 Sep 2018 17:07:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536858468; bh=d1fj1A3kTlnkZAaqD45rFa5WJWOcBSaqJFnoONkROyA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XLlCTUXjntasxi0uYAKK32pXgvnJLissBVA9muBjqaWC/OiMe2cc/4MQRWGgjnLm1 zcYf7WwcLl1LTvTdnyk7z/aOU1nUjXt4xwcL5U89jyZNvCbJEIyDyaY7fHBGLl6Ali NfvOrbJz5mdBTv5G6+d/TG7v0q3rmaAegHjBUwAI= Received: from jackp-linux.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jackp@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id B7BA2601A8; Thu, 13 Sep 2018 17:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536858468; bh=d1fj1A3kTlnkZAaqD45rFa5WJWOcBSaqJFnoONkROyA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XLlCTUXjntasxi0uYAKK32pXgvnJLissBVA9muBjqaWC/OiMe2cc/4MQRWGgjnLm1 zcYf7WwcLl1LTvTdnyk7z/aOU1nUjXt4xwcL5U89jyZNvCbJEIyDyaY7fHBGLl6Ali NfvOrbJz5mdBTv5G6+d/TG7v0q3rmaAegHjBUwAI= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B7BA2601A8 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=jackp@codeaurora.org Date: Thu, 13 Sep 2018 10:07:46 -0700 From: Jack Pham To: Badhri Jagan Sridharan Cc: Heikki Krogerus , Greg Kroah-Hartman , USB , LKML , Guenter Roeck Subject: Re: [PATCH 2/2] typec: tcpm: Add option to maintain current limit at Vsafe5V Message-ID: <20180913170746.GB13306@jackp-linux.qualcomm.com> References: <20180913021113.18150-1-badhri@google.com> <20180913021113.18150-2-badhri@google.com> <20180913063943.GA13306@jackp-linux.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 13, 2018 at 6:43 AM Badhri Jagan Sridharan wrote: > > On Wed, Sep 12, 2018 at 11:39 PM Jack Pham 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. Ok, you are talking about sink current draw limits but vSafe{0,5}V are voltage definitions so these are orthogonal. Again, the sink can't directly dictate the voltage that's being sourced so I don't see how it has a choice here. If a PD contract was negotiated for greater than 5V and a hard reset happens then yes the voltage would fall to 0V and then rise back to 5V and during this time sink needs to draw appropriate current. > > > 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 ? Sure that makes sense. In this case I wonder if TCPM even needs to call set_charge(false) considering it does not yet know if the partner is PD capable or not. For sure, if the partner is PD capable and contract had been previously established, we'd definitely need to set_current_limit() to default levels and/or turn off charging. But in the case of hard reset attempts to try to determine if the source will send its capabilities (thereby being PD capable), wouldn't the initial default current limits still be in place? I think this is the point you're trying to make, that there is no need to disrupt charging if a hard reset is not going to cause VBUS to reset. To me it sounds like what you're trying to do makes sense only if you can make a run-time determination of a partner's PD capability, and not based on a config option. Thanks, Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project