Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1094569yba; Tue, 2 Apr 2019 02:04:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxQhblknj14j0qko4i2rEqKvsaknsgV8sG6TQ2UhQspVB6YBWY4Ubx9PsuVCU28QaSBQDxt X-Received: by 2002:a62:7603:: with SMTP id r3mr67855448pfc.32.1554195891218; Tue, 02 Apr 2019 02:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554195891; cv=none; d=google.com; s=arc-20160816; b=qFrvhqqgHx+NuzbPqOiDJsV4Una/MWUQygFKHbaQb+qm1txuGlQmEUN70RL2n3Ubi9 Ji3yQKnq6f0dVUWECmq1sYIeuV1BR08h5LukxEZ17sJ/uKbkGcUrvkpELI1z0NZPKmlS /lufUbxuq7ABCGBAFBkljZ2Q41jSulMjtomFdtYFpigYhRYvzz+s+UjuEj9pP8GNdpB5 qmmEo0QCmnq5iwpPR6+FkXGsAQl3hnMkIGFf9hgHBIGLURwfKdT2WJxDCTfM5Zwi6Lhk ZEXKkvRnz+aF4Hi/PpO6CeEW2h9H3wPbZc+nRbLP8uA4BpW8UEWChNeGzDaBhm+eeCQt DKcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=kVcUu+8DDTcbNX0l5E3ERH5M6trqqAOlCvPSgjuDFKU=; b=Sj8nKPQ9g96BL+8Qekrct1ms1DdDhI4gcg7Eh8wcDxVs7I3GhL0JbtG52lcqkeLp4r 5liEIl36AO/wcIKzf5rVI7JZWdmjTFT7jxmwVSlzXddZwspyF+2FjJVXhoJ17Z/NGqhs lre+unJAG5qbWKJ6fhwI9Y/gezSsBttI0CZK85StLVt8IwiybVs1rHAHn9J8qHzZ8nci W0xREdNe/+9vBMIyDd162PhKre0BJug8iKAJecrR/gH0xzt6AqXNW5Ch3PoADVW4ePI6 PpolHhnCBHNdayaKahODN+eNmOvc53DRea8PwJR5cuHV6QIcR+po+8Am6FKvJE7Z75jO 4fXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r7si11316879ple.70.2019.04.02.02.04.35; Tue, 02 Apr 2019 02:04:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729754AbfDBJBJ (ORCPT + 99 others); Tue, 2 Apr 2019 05:01:09 -0400 Received: from sauhun.de ([88.99.104.3]:38166 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726337AbfDBJBI (ORCPT ); Tue, 2 Apr 2019 05:01:08 -0400 Received: from localhost (p5486CD10.dip0.t-ipconnect.de [84.134.205.16]) by pokefinder.org (Postfix) with ESMTPSA id B43AC2CF606; Tue, 2 Apr 2019 11:01:05 +0200 (CEST) Date: Tue, 2 Apr 2019 11:01:05 +0200 From: Wolfram Sang To: Rayagonda Kokatanur Cc: Ray Jui , Rob Herring , Mark Rutland , linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Shreesha Rajashekar , Michael Cheng Subject: Re: [PATCH v5 2/8] i2c: iproc: Add slave mode support Message-ID: <20190402090105.GA2960@kunai> References: <20190214175725.60462-1-ray.jui@broadcom.com> <20190214175725.60462-3-ray.jui@broadcom.com> <20190327221452.GA15396@kunai> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > >> + /* RANDOM SLAVE STRETCH time - 20ms*/ > > > > > > What is a "random stretch time"? 20ms sounds like a lot. Also, missing > > > space before comment terminator. > > > > > > > Rayagonda, > > > > Could you please help to comment on the choice of the 20 ms to allow > > clock stretch from the slave? In probably all cases, the slave should > > not need more than 1 ms? 20 ms does seem way too long as Wolfram pointed > > out. >=20 > In fact we are programming max slave stretch time ie 25ms, comment > should be correcting. > Its maximum time for slave to complete read/write operation, if slave > is done with read/write then clock will not be stretched further, it > will be released immediately. Ah, now I see. This is a protection against the slave stretching the clock forever. This makes sense. > Hence I feel no harm in programming max timeout value. I agree. "Random stretch" is just a bit confusing as a name. "Maximum" would have been more clear IMO. --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlyjJM0ACgkQFA3kzBSg KbYwnRAAhyvKGZin7EPbNl42uih8M22BfSs+//ZzA92ckfe99z34MztaQzSbXRym wKO3ncesoIPM81IrYkwTY4lNTCRCLMxsmXMJbd518lumNp/4ZUp9sNSmoD8Z/61R e6YWJ7kysBz/iNjcbw8igaJLTvrZfV9IeSxuNdxQXCq9k9Whaa1yealO9CVVJiNU TpA16pFWbI7it7SuGwY2EEO/3asBqYj0CjjUthtS8kwqZ67MTVVzoK2cxstaoXec 1T9dhvRX++vIDpBoFlTRQH2ZGpSEQJmKosvNuagNIiKs/6Rcw+AbNLUYx9Z1qRwt FxYADEeszSLtFM1QoqTcwwERDap32YnZzhnnC61fpI+SIIKV6twClJWeZ/gPrU5u 0bxeAN8GwJ5OzxTAnoKNECwSUf0CsN2jnjbMv+1kXKmXJgYEhxQotgdxL2ywXeJ1 RL9SI2xApC47SAX6qJX/Z4ZtxT2aF1hdG7doy3rUu82e2VX9FcVyl/Qn1XQdgE6G h9JR5mqtOA5K9e3bDcKFQgeSFFCM+gKWd4LBfkEpsLR6EIzglwqcAtWYgbfp7kuD PSiacbJCZDTcbHMezQt2GI683MaDcIhwIYSPzgqv8KlHK9TXXHqm/+l3D1+RTrCz +aBK7knHXHplb37AOPZKSbjqCe9ksOJoIFIgAwaJu8rmZUs09X8= =MmnH -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh--