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: <20180914184242.GC13306@jackp-linux.qualcomm.com> Date: Fri, 14 Sep 2018 11:42:42 -0700 To: Badhri Jagan Sridharan Cc: Heikki Krogerus , Greg Kroah-Hartman , USB , LKML , Guenter Roeck List-ID: SGkgQmFkaHJpLAoKT24gVGh1LCBTZXAgMTMsIDIwMTggYXQgMDQ6Mzg6MTBQTSAtMDcwMCwgQmFk aHJpIEphZ2FuIFNyaWRoYXJhbiB3cm90ZToKPiBPbiBUaHUsIFNlcCAxMywgMjAxOCBhdCAxMDow NyBBTSBKYWNrIFBoYW0gPGphY2twQGNvZGVhdXJvcmEub3JnPiB3cm90ZToKPiA+IE9uIFRodSwg U2VwIDEzLCAyMDE4IGF0IDY6NDMgQU0gQmFkaHJpIEphZ2FuIFNyaWRoYXJhbgo+ID4gPiBZZWFo IHRoYXRzIGZvciB0aGUgc291cmNlLiBCdXQgZm9yIHNpbmssIFNheSBpZiB0aGUgc291cmNlIGlz bnQgUEQsIHRoZW4sCj4gPiA+IHNpbmsgaW5pdGlhdGVkIGhhcmQgcmVzZXRzIGhhcHBlbiBkdXJp bmcgdGhlIGNvbm5lY3Rpb24uIFNpbmsgd291bGQgaGFyZCByZXNldAo+ID4gPiBjb3VwbGUgb2Yg dGltZXMgYmVmb3JlIGRlZW1pbmcgdGhhdCB0aGUgcGFydG5lciBpcyBub24gUEQuIFdoZW4gY29u bmVjdGVkCj4gPiA+IHRvIFR5cGUtQSBwb3J0cy9ub24tcGQgcGFydG5lciwgdmJ1cyBpcyBub3Qg Z29pbmcgdG8gbGlrZWx5IGRyb3Agc28gdGhlcmUgaXNudAo+ID4gPiBhIHJlYXNvbiB0byBzZXRj aGFyZ2UgdG8gZmFsc2Ugb3IgZHJvcCB0aGUgaW5wdXQgY3VycmVudCBsaW1pdC4gRG8geW91IGFn cmVlID8KPiA+Cj4gPiBTdXJlIHRoYXQgbWFrZXMgc2Vuc2UuIEluIHRoaXMgY2FzZSBJIHdvbmRl ciBpZiBUQ1BNIGV2ZW4gbmVlZHMgdG8gY2FsbAo+ID4gc2V0X2NoYXJnZShmYWxzZSkgY29uc2lk ZXJpbmcgaXQgZG9lcyBub3QgeWV0IGtub3cgaWYgdGhlIHBhcnRuZXIgaXMgUEQKPiA+IGNhcGFi bGUgb3Igbm90LiBGb3Igc3VyZSwgaWYgdGhlIHBhcnRuZXIgaXMgUEQgY2FwYWJsZSBhbmQgY29u dHJhY3QgaGFkCj4gPiBiZWVuIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQsIHdlJ2QgZGVmaW5pdGVs eSBuZWVkIHRvIHNldF9jdXJyZW50X2xpbWl0KCkKPiA+IHRvIGRlZmF1bHQgbGV2ZWxzIGFuZC9v ciB0dXJuIG9mZiBjaGFyZ2luZy4KPiA+Cj4gPiBCdXQgaW4gdGhlIGNhc2Ugb2YgaGFyZCByZXNl dCBhdHRlbXB0cyB0byB0cnkgdG8gZGV0ZXJtaW5lIGlmIHRoZSBzb3VyY2UKPiA+IHdpbGwgc2Vu ZCBpdHMgY2FwYWJpbGl0aWVzICh0aGVyZWJ5IGJlaW5nIFBEIGNhcGFibGUpLCB3b3VsZG4ndCB0 aGUKPiA+IGluaXRpYWwgZGVmYXVsdCBjdXJyZW50IGxpbWl0cyBzdGlsbCBiZSBpbiBwbGFjZT8g SSB0aGluayB0aGlzIGlzIHRoZQo+ID4gcG9pbnQgeW91J3JlIHRyeWluZyB0byBtYWtlLCB0aGF0 IHRoZXJlIGlzIG5vIG5lZWQgdG8gZGlzcnVwdCBjaGFyZ2luZwo+ID4gaWYgYSBoYXJkIHJlc2V0 IGlzIG5vdCBnb2luZyB0byBjYXVzZSBWQlVTIHRvIHJlc2V0Lgo+IAo+IFllcyB0aGF0J3Mgcmln aHQgISBJIHdhc250IHN1cmUgaG93IHRvIHB1dCB0aGF0IGluIHdvcmRzLiBUaGFua3MgZm9yCj4g ZG9pbmcgdGhhdCAhCj4gWW91IGRvIGNvbmN1ciByaWdodCA/CgpZZXMuCgo+ID4gVG8gbWUgaXQg c291bmRzIGxpa2Ugd2hhdCB5b3UncmUgdHJ5aW5nIHRvIGRvIG1ha2VzIHNlbnNlIG9ubHkgaWYg eW91Cj4gPiBjYW4gbWFrZSBhIHJ1bi10aW1lIGRldGVybWluYXRpb24gb2YgYSBwYXJ0bmVyJ3Mg UEQgY2FwYWJpbGl0eSwgYW5kIG5vdAo+ID4gYmFzZWQgb24gYSBjb25maWcgb3B0aW9uLgo+IAo+ IFllcyB0aGlzIHNob3VsZCBiZSBwb3NzaWJsZS4gcG9ydC0+cGRfY2FwYWJsZSBhbHJlYWR5IGhh cyB0aGF0IGluZm8uCj4gCj4gVG8gc3VtIGl0IHVwOgo+IGlmIHRoZSBwYXJ0bmVyIGlzIHBkIGNh cGFibGUsIHNldCBjaGFyZ2UgdG8gZmFsc2UgaW4gU05LX0hBUkRfUkVTRVRfU0lOS19PRkYgYW5k Cj4gcmVhZGp1c3QgY3VycmVudCBsaW1pdHMgdG8gZGVmYXVsdCBpbiBTTktfSEFSRF9SRVNFVF9T SU5LX09OIGFuZCB0dXJuCj4gb24gY2hhcmdpbmcuCj4gCj4gSWYgcGFydG5lciBpcyBub3QgcGQg Y2FwYWJsZSwgZG8gbm90IHR1cm4gb2ZmIGNoYXJnaW5nIG5vciBhZGp1c3QKPiBjdXJyZW50IGxp bWl0IGFzIGhvc3QgcG9ydCBpcwo+IG5vdCBnb2luZyB0byByZXNwb25kIHRvIGhhcmQgcmVzZXQu Cj4gCj4gRG9lcyBpdCBtYWtlIHNlbnNlID8KClJpZ2h0LCBhbHRob3VnaCB0aGUgIm5vdCBwZCBj YXBhYmxlIiBwYXRoIGNvdWxkIGFsc28gbWVhbiB0aGUgcGFydG5lciBpcwpQRCBjYXBhYmxlIGJ1 dCBpdCBpcyBub3QgZGV0ZXJtaW5lZCB5ZXQuIEZvciBleGFtcGxlOiBpZiBhIHNpbmsgaXMKY29u bmVjdGVkIHRvIGEgUEQgc291cmNlLCBlc3RhYmxpc2hlZCBhIGNvbnRyYWN0LCBhbmQgdGhlIHNp bmsgcmVib290cwphbmQgaGFzIHRvIGluaXRpYWxpemUgVENQTSBhZ2Fpbi4gQXNzdW1pbmcgdGhl IHNpbmsgbmV2ZXIgZGlzY29ubmVjdGVkCmZyb20gQ0Mgd2hlbiByZWJvb3RpbmcsIHRoZSBzb3Vy Y2Ugd29uJ3QgYXV0b21hdGljYWxseSByZS1zZW5kIGl0cwpTb3VyY2UgQ2FwYWJpbGl0aWVzIGFz IGl0IHdpbGwgc3RpbGwgYmUgaW4gaXRzIHByZXZpb3VzIHN0YXRlKCopLiBUaGUKc2luayBUQ1BN IGhvd2V2ZXIgd291bGQgc2VuZCBhIGhhcmQgcmVzZXQgaW4gb3JkZXIgdG8gdHJ5IHRvCihyZSll c3RhYmxpc2ggYSBjb250cmFjdCwgc28gaGVyZSBpcyB3aGVyZSB0aGlzIHBhdGggb3ZlcmxhcHMg d2l0aCB0aGUKbm90LXBkLWNhcGFibGUgY2FzZS4gSW4gdGhpcyBjYXNlIEkgdGhpbmsgaXQgbWln aHQgYmUgcHJvcGVyIHRvIHJlYWRqdXN0CmN1cnJlbnQgbGltaXRzIHRvIGRlZmF1bHQgYWxzbyB1 bmxlc3MgaXQgd2FzIGFscmVhZHkgZG9uZSBlYXJsaWVyLS1JIHNlZQppdCBpcyBkb25lIGluIHRj cG1fcmVzZXRfcG9ydCgpIGFuZCBpbiBTTktfRElTQ09WRVJZLCBzbyB5b3UgbWlnaHQgYmUKY292 ZXJlZCBoZXJlLgoKVGhlIHF1ZXN0aW9uIEkgaGF2ZSBpcyB3aGV0aGVyIHlvdSBzdGlsbCBuZWVk IHRvIGNvbnNpZGVyIGNhbGxpbmcKc2V0X2NoYXJnZShmYWxzZSkgZm9yIHRoaXMgZXhhbXBsZS4K CigqKSBKdXN0IHRob3VnaHQgb2Ygb25lIG1vcmUgdGhpbmcsIHdoYXQgaWYgdGhlIHByZXZpb3Vz IGNvbnRyYWN0IHdhcwpuZWdvdGlhdGVkIGF0IGdyZWF0ZXIgdGhhbiA1ViBWQlVTPyBIb3cgZG9l cyB0aGUgc2luayBUQ1BNIGhhbmRsZQpzZXR0aW5nIGNoYXJnaW5nIHBhcmFtZXRlcnMgYWZ0ZXIg YSByZWJvb3QgYnV0IHByaW9yIHRvIGhhcmQgcmVzZXQ/CgpKYWNrCg== 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=-0.6 required=5.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, URIBL_BLOCKED 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 DA9F7ECDFD0 for ; Fri, 14 Sep 2018 18:42:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74FC520882 for ; Fri, 14 Sep 2018 18:42:48 +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="YZyGwjgz"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="kJz7nJaD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74FC520882 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 S1727944AbeINX6a (ORCPT ); Fri, 14 Sep 2018 19:58:30 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:51346 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726748AbeINX63 (ORCPT ); Fri, 14 Sep 2018 19:58:29 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 8D74160BF7; Fri, 14 Sep 2018 18:42:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536950565; bh=+vYJ+BNdbhbGL2E8fwhABXon5Y2/19HIHSTL4804ZAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YZyGwjgzNlF6PBZfdI1c9PBwOwBZvGuscryKoQlQ/FqRf8KNQoIjZ0S+gwUlLXDTs BbgXMdBNxLonNRFr0jq+cu+KgTbomfceI1fF/IvB1XjBuc6hoQPkO4AcwQ42cNfhiM +IoHdsC9PcMRlXrLe2peFcY+2s2lVO06axgMz9Bo= 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 731D7609A1; Fri, 14 Sep 2018 18:42:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536950564; bh=+vYJ+BNdbhbGL2E8fwhABXon5Y2/19HIHSTL4804ZAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kJz7nJaDo2NaFeq3siakmzuj2ppa23WZUL6zGc2SfZpMPIU+ogeJkn4U10FOisXgB hEmsPaFwFk6MUgxPViPZx4IyAzmKOshxONPPxb2WAn0jNkgZGedW0JaNtd1qxFIwVz x5jRQAH1txN6jUhzd06ZttWyCWsLziMEV9TBCirI= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 731D7609A1 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: Fri, 14 Sep 2018 11:42:42 -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: <20180914184242.GC13306@jackp-linux.qualcomm.com> References: <20180913021113.18150-1-badhri@google.com> <20180913021113.18150-2-badhri@google.com> <20180913063943.GA13306@jackp-linux.qualcomm.com> <20180913170746.GB13306@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 Hi Badhri, On Thu, Sep 13, 2018 at 04:38:10PM -0700, Badhri Jagan Sridharan wrote: > On Thu, Sep 13, 2018 at 10:07 AM Jack Pham wrote: > > On Thu, Sep 13, 2018 at 6:43 AM Badhri Jagan Sridharan > > > 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. > > Yes that's right ! I wasnt sure how to put that in words. Thanks for > doing that ! > You do concur right ? Yes. > > 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. > > Yes this should be possible. port->pd_capable already has that info. > > To sum it up: > if the partner is pd capable, set charge to false in SNK_HARD_RESET_SINK_OFF and > readjust current limits to default in SNK_HARD_RESET_SINK_ON and turn > on charging. > > If partner is not pd capable, do not turn off charging nor adjust > current limit as host port is > not going to respond to hard reset. > > Does it make sense ? Right, although the "not pd capable" path could also mean the partner is PD capable but it is not determined yet. For example: if a sink is connected to a PD source, established a contract, and the sink reboots and has to initialize TCPM again. Assuming the sink never disconnected from CC when rebooting, the source won't automatically re-send its Source Capabilities as it will still be in its previous state(*). The sink TCPM however would send a hard reset in order to try to (re)establish a contract, so here is where this path overlaps with the not-pd-capable case. In this case I think it might be proper to readjust current limits to default also unless it was already done earlier--I see it is done in tcpm_reset_port() and in SNK_DISCOVERY, so you might be covered here. The question I have is whether you still need to consider calling set_charge(false) for this example. (*) Just thought of one more thing, what if the previous contract was negotiated at greater than 5V VBUS? How does the sink TCPM handle setting charging parameters after a reboot but prior to hard reset? Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project