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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D97DC4332F for ; Thu, 3 Mar 2022 14:11:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233942AbiCCOMV (ORCPT ); Thu, 3 Mar 2022 09:12:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229914AbiCCOMU (ORCPT ); Thu, 3 Mar 2022 09:12:20 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2D9418CC0E; Thu, 3 Mar 2022 06:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646316694; x=1677852694; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8UFSNQlM9WPEp6bci8a0Zs4QbDnKrGrES/unqzgEs3s=; b=n/zbmLUPPPtJlk4MARAEK26qvJEK+1svz2xrMZkY4Bmie5DnDsddizvF ArSTBAoUgGa8kVyclCEpAKLNk4XvloDP6RmGgB/zXh1Eszg8JGNPM7eM8 T++iJLofwEOzYAaE8xYJF2lIPq7PgGWf7Mb8XBNGiOrLKAvRPtW1YyBAv /wrGSSZLrvdnAHwe87onlqunDZEAigvkxYIE+i5B8aWoqtV5hjJx5theY LVl3zhT7bmI6bUx8Y2Jtjs5ALEUng5pIrmFUvF9clbQmG0HohkXpmEIuQ bw4cZxwmnHSCYiqRETpcPWPMorc+ljYj3F1ZULfQYJNveEnlQUywgqITh w==; X-IronPort-AV: E=McAfee;i="6200,9189,10274"; a="252509204" X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="252509204" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 06:11:34 -0800 X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="576497839" Received: from smile.fi.intel.com ([10.237.72.59]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 06:11:27 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nPmAC-00ApFi-B4; Thu, 03 Mar 2022 16:10:40 +0200 Date: Thu, 3 Mar 2022 16:10:39 +0200 From: Andy Shevchenko To: Tali Perry Cc: Tyrone Ting , avifishman70@gmail.com, Tomer Maimon , Patrick Venture , Nancy Yuen , Benjamin Fair , Rob Herring , Krzysztof Kozlowski , yangyicong@hisilicon.com, semen.protsenko@linaro.org, Wolfram Sang , jie.deng@intel.com, sven@svenpeter.dev, bence98@sch.bme.hu, lukas.bulwahn@gmail.com, arnd@arndb.de, olof@lixom.net, Tali Perry , Avi Fishman , tomer.maimon@nuvoton.com, KWLIU@nuvoton.com, JJLIU0@nuvoton.com, kfting@nuvoton.com, OpenBMC Maillist , Linux I2C , devicetree , Linux Kernel Mailing List Subject: Re: [PATCH v3 11/11] i2c: npcm: Support NPCM845 Message-ID: References: <20220303083141.8742-1-warp5tw@gmail.com> <20220303083141.8742-12-warp5tw@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 03, 2022 at 02:35:58PM +0200, Tali Perry wrote: > > On Thu, Mar 3, 2022 at 12:45 PM Andy Shevchenko wrote: > > > On Thu, Mar 03, 2022 at 04:31:41PM +0800, Tyrone Ting wrote: ... > > > > - left_in_fifo = FIELD_GET(NPCM_I2CTXF_STS_TX_BYTES, > > > > - ioread8(bus->reg + NPCM_I2CTXF_STS)); > > > > + left_in_fifo = (bus->data->txf_sts_tx_bytes & > > > > + ioread8(bus->reg + NPCM_I2CTXF_STS)); > > > > > > Besides too many parentheses, this is an interesting change. So, in different > > > versions of IP the field is on different bits? Perhaps it means that you need > > > something like internal ops structure for all these, where you will have been > > > using the statically defined masks? > > > > > Those are two very similar modules. The first generation had a 16 bytes HW FIFO > and the second generation has 32 bytes. > In V1 of this patchset the masks were defined under > CONFIG but we were asked to change the approach: > > the entire discussion can be found here: > > https://www.spinics.net/lists/linux-i2c/msg55566.html > > Did we understand the request change right? Not really. If you have not simply "one (MSB) bit more" for FIFO size, then I proposed to create a specific operations structure and use callbacks (see drivers/dma/dw/ case for iDMA 32-bit vs. DesignWare). But hold on and read set of questions below. Previously it was a fixed field with the NPCM_I2CTXF_STS_TX_BYTES mask applied, right? From above I have got that FIFO is growing twice. Is it correct? Does the LSB stay at the same offset? What is the meaning of the MSB in 32 byte case? If it's reserved then why not to always use 32 byte approach? -- With Best Regards, Andy Shevchenko 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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F323DC433EF for ; Thu, 3 Mar 2022 14:13:21 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4K8XyR1gdSz3c3y for ; Fri, 4 Mar 2022 01:13:19 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=PMg0LN2R; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=192.55.52.151; helo=mga17.intel.com; envelope-from=andriy.shevchenko@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=PMg0LN2R; dkim-atps=neutral Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4K8Xxf3vM4z30NW for ; Fri, 4 Mar 2022 01:12:37 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646316759; x=1677852759; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8UFSNQlM9WPEp6bci8a0Zs4QbDnKrGrES/unqzgEs3s=; b=PMg0LN2R8uRqmu3eFVbHx1d8jrpHCRPMmGEaFW0l9Aezp7qogW2UHN7+ jVWaqbD0gqc6OPk6ODLUJvXNdwHIn4rLE6+R/mkT7CepJAamWIgb9kzTN a+bwM3sOD3VAjU6TG2Dxy134EXfIsRRdFGTBNhoxxHTpOrSSKwhHc5cEw 79yO4BbLViFdNw3+Q/z7YLnXUA00xlcKPXxN9gteV4PnLCJDbVZeURWkv tS3pn4gS4nTlpqAeS3pZMUdWYeCP+pi92kuoWyri+whWRKQll+NHUKXzv m0uGnolPu7fHSr9rE+tSC9rEcZ4yzXFzfU0j4TXaZ+EMN24T0Edm2SWtD w==; X-IronPort-AV: E=McAfee;i="6200,9189,10274"; a="234295452" X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="234295452" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 06:11:34 -0800 X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="576497839" Received: from smile.fi.intel.com ([10.237.72.59]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 06:11:27 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nPmAC-00ApFi-B4; Thu, 03 Mar 2022 16:10:40 +0200 Date: Thu, 3 Mar 2022 16:10:39 +0200 From: Andy Shevchenko To: Tali Perry Subject: Re: [PATCH v3 11/11] i2c: npcm: Support NPCM845 Message-ID: References: <20220303083141.8742-1-warp5tw@gmail.com> <20220303083141.8742-12-warp5tw@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomer Maimon , devicetree , yangyicong@hisilicon.com, Linux I2C , Benjamin Fair , Krzysztof Kozlowski , OpenBMC Maillist , JJLIU0@nuvoton.com, lukas.bulwahn@gmail.com, tomer.maimon@nuvoton.com, KWLIU@nuvoton.com, bence98@sch.bme.hu, arnd@arndb.de, sven@svenpeter.dev, Rob Herring , Avi Fishman , Tyrone Ting , semen.protsenko@linaro.org, jie.deng@intel.com, avifishman70@gmail.com, Patrick Venture , Linux Kernel Mailing List , Wolfram Sang , kfting@nuvoton.com, Tali Perry , olof@lixom.net Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Thu, Mar 03, 2022 at 02:35:58PM +0200, Tali Perry wrote: > > On Thu, Mar 3, 2022 at 12:45 PM Andy Shevchenko wrote: > > > On Thu, Mar 03, 2022 at 04:31:41PM +0800, Tyrone Ting wrote: ... > > > > - left_in_fifo = FIELD_GET(NPCM_I2CTXF_STS_TX_BYTES, > > > > - ioread8(bus->reg + NPCM_I2CTXF_STS)); > > > > + left_in_fifo = (bus->data->txf_sts_tx_bytes & > > > > + ioread8(bus->reg + NPCM_I2CTXF_STS)); > > > > > > Besides too many parentheses, this is an interesting change. So, in different > > > versions of IP the field is on different bits? Perhaps it means that you need > > > something like internal ops structure for all these, where you will have been > > > using the statically defined masks? > > > > > Those are two very similar modules. The first generation had a 16 bytes HW FIFO > and the second generation has 32 bytes. > In V1 of this patchset the masks were defined under > CONFIG but we were asked to change the approach: > > the entire discussion can be found here: > > https://www.spinics.net/lists/linux-i2c/msg55566.html > > Did we understand the request change right? Not really. If you have not simply "one (MSB) bit more" for FIFO size, then I proposed to create a specific operations structure and use callbacks (see drivers/dma/dw/ case for iDMA 32-bit vs. DesignWare). But hold on and read set of questions below. Previously it was a fixed field with the NPCM_I2CTXF_STS_TX_BYTES mask applied, right? From above I have got that FIFO is growing twice. Is it correct? Does the LSB stay at the same offset? What is the meaning of the MSB in 32 byte case? If it's reserved then why not to always use 32 byte approach? -- With Best Regards, Andy Shevchenko