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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 022ECC43381 for ; Wed, 10 Mar 2021 15:56:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB34A64FC7 for ; Wed, 10 Mar 2021 15:56:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233255AbhCJPzu (ORCPT ); Wed, 10 Mar 2021 10:55:50 -0500 Received: from mga14.intel.com ([192.55.52.115]:62102 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229851AbhCJPzj (ORCPT ); Wed, 10 Mar 2021 10:55:39 -0500 IronPort-SDR: rv/eOZ4QcnR4UnCQX7F/mKIJxgqCi6X+zttPqqhk0hxEtGK6A6LomQDP1GPILZn81W36yY2oCA DFpg1mPjdJxw== X-IronPort-AV: E=McAfee;i="6000,8403,9919"; a="187858185" X-IronPort-AV: E=Sophos;i="5.81,237,1610438400"; d="scan'208";a="187858185" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 07:55:39 -0800 IronPort-SDR: /6eKFr8ry0VtVGJOb9d9xQK0rmfnthDtnNFQFohYpPLs8T52s8cLX5JG5QSF0oavx6e+jiVGji c5CtbcZkhVEg== X-IronPort-AV: E=Sophos;i="5.81,237,1610438400"; d="scan'208";a="447943096" Received: from yoojae-mobl.amr.corp.intel.com (HELO [10.212.177.249]) ([10.212.177.249]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 07:55:38 -0800 Subject: Re: [PATCH v4 1/4] dt-bindings: i2c: aspeed: add transfer mode support To: Rob Herring Cc: Mark Rutland , devicetree@vger.kernel.org, linux-aspeed , Wolfram Sang , Andrew Jeffery , OpenBMC Maillist , Brendan Higgins , Linux I2C , Tao Ren , Cedric Le Goater References: <20210224191720.7724-1-jae.hyun.yoo@linux.intel.com> <20210224191720.7724-2-jae.hyun.yoo@linux.intel.com> <20210306203011.GA1152769@robh.at.kernel.org> From: Jae Hyun Yoo Message-ID: Date: Wed, 10 Mar 2021 07:55:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org On 3/9/2021 6:15 PM, Rob Herring wrote: > On Tue, Mar 9, 2021 at 10:02 AM Jae Hyun Yoo > wrote: >> >> Hi Rob, >> >> On 3/6/2021 12:30 PM, Rob Herring wrote: >>> On Wed, Feb 24, 2021 at 11:17:17AM -0800, Jae Hyun Yoo wrote: >>>> Append bindings to support transfer mode. >>>> >>>> Signed-off-by: Jae Hyun Yoo >>>> Reviewed-by: Brendan Higgins >>>> --- >>>> Changes since v3: >>>> - None >>>> >>>> Changes since v2: >>>> - Moved SRAM resources back to default dtsi and added mode selection >>>> property. >>>> >>>> Changes since v1: >>>> - Removed buffer reg settings from default device tree and added the settings >>>> into here to show the predefined buffer range per each bus. >>>> >>>> .../devicetree/bindings/i2c/i2c-aspeed.txt | 37 +++++++++++++++---- >>>> 1 file changed, 30 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt >>>> index b47f6ccb196a..242343177324 100644 >>>> --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt >>>> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt >>>> @@ -17,6 +17,20 @@ Optional Properties: >>>> - bus-frequency : frequency of the bus clock in Hz defaults to 100 kHz when not >>>> specified >>>> - multi-master : states that there is another master active on this bus. >>>> +- aspeed,i2c-xfer-mode : should be "byte", "buf" or "dma" to select transfer >>>> + mode defaults to "byte" mode when not specified. >>>> + >>>> + I2C DMA mode on AST2500 has these restrictions: >>>> + - If one of these controllers is enabled >>>> + * UHCI host controller >>>> + * MCTP controller >>>> + I2C has to use buffer mode or byte mode instead >>>> + since these controllers run only in DMA mode and >>>> + I2C is sharing the same DMA H/W with them. >>>> + - If one of these controllers uses DMA mode, I2C >>>> + can't use DMA mode >>>> + * SD/eMMC >>>> + * Port80 snoop >>> >>> How does one decide between byte or buf mode? >> >> If a given system makes just one byte r/w transactions most of the time >> then byte mode will be a right setting. Otherwise, buf mode is more >> efficient because it doesn't generate a bunch of interrupts on every >> byte handling. > > Then why doesn't the driver do byte transactions when it gets small > 1-4? byte transactions and buffer transactions when it gets larger > sized transactions. Good question and it could be an option of this implementation. Actually, each mode needs different register handling so we need to add additional conditional branches to make it dynamic mode change depends on the data size which can be a downside. Also, checked that small amount of data transfer efficiency in 'buf' transfer mode is almost same to 'byte' mode so there would be no big benefit from the dynamic mode change. Of course, we can remove the 'byte' transfer mode but we should also provide flexibility of configuration on what this hardware can support, IMO. Thanks, Jae