Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp958944imm; Wed, 26 Sep 2018 09:21:56 -0700 (PDT) X-Google-Smtp-Source: ACcGV63RReH7oVjGUkT9HSKDUmSFmME/LNbIfxGrdLOJHgKs6S6Dc8wJLAOal+KeN1WKFBXXPt+W X-Received: by 2002:a17:902:bd97:: with SMTP id q23-v6mr3410357pls.266.1537978916024; Wed, 26 Sep 2018 09:21:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537978915; cv=none; d=google.com; s=arc-20160816; b=V027OUUtIxYIpP/EDXcoHHK1Q2vX8uy0zyGM0ENqfZ1L0/nGYw1iAQHpDFhGukO3mM Yv4JtOtZHDo0BgckVOcf9oXS3ef53zKEJ/Xg3rGfQQMheoLpTmEZ6p5BWA+BehVZ6qTv SJzrQuKnA+iJ0pvP8cqcXpF9yPJ+67AnXEjww9EDK59olhv1DcT9VTBnj5OWDZIbBsF2 /SWmwzjG1pY/z8NIQx/0J2Gl+RQagoFpoIEydlMg/fQzEVo5ulldMMFlaqGrd/nTWFUY iMeL6CtG2mkz2GQFWb4zC/7yM/lbT/50yByx/up+cU1w5ZvBAXDZ2w2/7cMaWx9HoDmM Lebw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=JQ+aVX2jub1miqHm4LoUcaUHdMNXN8oYX0/UX6v/mqg=; b=RJVyRzkTiFbjX74oE6AkA/g+6/vk2e7BoHIg0AIikYEoZNLGBwzLX1tMRsEumMYDXx bf2MOYl5xgI2CUdRGPSwjUfzRTJu/uLscdUJI2oB0Wu++MssQL+zJ8lbX1Lt9j761tjS YcwQgEyxXpUFxR9hr785/dpE/zuA8uBW4lS52du3X73o15BUeNkVJdp+hlzHRL9y6O6W nu5TgHdTStdcznFGCEEoy1pvIEL0bieZOl6LxPLVV30/Qz7LAM9D+0VdCrCkqkXD1gwY zmaimfhWXC8GfqFVUJIbcfc4AQRGusXKzo9SpAjmQM81h+UOuctv/d9ouJNKHowiL7w+ Kkag== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y5-v6si2151098plt.438.2018.09.26.09.21.40; Wed, 26 Sep 2018 09:21:55 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728612AbeIZWfK (ORCPT + 99 others); Wed, 26 Sep 2018 18:35:10 -0400 Received: from mga12.intel.com ([192.55.52.136]:64913 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728184AbeIZWfK (ORCPT ); Wed, 26 Sep 2018 18:35:10 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 09:21:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,306,1534834800"; d="scan'208";a="76395624" Received: from yoojae-mobl1.amr.corp.intel.com (HELO [10.7.153.151]) ([10.7.153.151]) by orsmga008.jf.intel.com with ESMTP; 26 Sep 2018 09:20:47 -0700 Subject: Re: [RFC PATCH i2c-next 1/2] dt-bindings: i2c: aspeed: Add 'idle-wait-timeout-ms' setting To: Wolfram Sang Cc: linux-aspeed@lists.ozlabs.org, James Feist , Andrew Jeffery , openbmc@lists.ozlabs.org, Brendan Higgins , linux-kernel@vger.kernel.org, Jarkko Nikula , Vernon Mauery , linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org References: <20180910214519.14126-1-jae.hyun.yoo@linux.intel.com> <20180910214519.14126-2-jae.hyun.yoo@linux.intel.com> <20180924215850.GD18592@kunai> <2c8563fd-0641-5237-0026-f559c480ad91@linux.intel.com> <20180925082717.GB2270@kunai> <7b4e5715-3a87-8f77-8d0d-4647f02c87a8@linux.intel.com> From: Jae Hyun Yoo Message-ID: Date: Wed, 26 Sep 2018 09:20:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7b4e5715-3a87-8f77-8d0d-4647f02c87a8@linux.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/25/2018 9:20 AM, Jae Hyun Yoo wrote: > On 9/25/2018 1:27 AM, Wolfram Sang wrote: >> On Mon, Sep 24, 2018 at 03:15:46PM -0700, Jae Hyun Yoo wrote: >>> Hi Wolfram, >>> >>> On 9/24/2018 2:58 PM, Wolfram Sang wrote: >>>> On Tue, Sep 18, 2018 at 11:02:54AM -0700, Jae Hyun Yoo wrote: >>>>> On 9/10/2018 2:45 PM, Jae Hyun Yoo wrote: >>>>>> +- idle-wait-timeout-ms??? : bus idle waiting timeout in >>>>>> milliseconds when >>>>>> +????????????? multi-master is set, defaults to 100 ms when not >>>>>> +????????????? specified. >>>>> >>>>> Will change it to 'aspeed,idle-wait-timeout-ms' as it's a non standard >>>>> property. >>>> >>>> No need. This binding is not a HW description, so not a DT property in >>>> my book. I still don't understand: Your IP core in master mode does not >>>> have a BUSY bit or similar which detects when a START was detected and >>>> clears after a STOP? >>>> >>> >>> Okay, I'll keep this property as it is then. >> >> Sorry for the misunderstanding. I don't think this a property, at all. >> It doesn't describe the hardware, it is more of a configuration thing, >> or? >> > > You are right. It doesn't describe the hardware but it needs to be > configurable because it very depends on the peer master's behavior. > If peer master sends a long packet usually, it should have a long > timeout value since a slave receiving operation takes long time, > and it should be adjusted with an optimal value with taking some > experiments to make it not too long. Any suggestion? > Should I use timeout in struct i2c_adapter instead just like i2c-mpc does?