From patchwork Tue Jan 12 00:37:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jae Hyun Yoo X-Patchwork-Id: 1424894 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DFBHq63Jfz9sf9 for ; Tue, 12 Jan 2021 11:28:07 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4DFBHq30fTzDqPF for ; Tue, 12 Jan 2021 11:28:07 +1100 (AEDT) X-Original-To: openbmc@lists.ozlabs.org Delivered-To: openbmc@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=jae.hyun.yoo@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 4DFBGR0FpjzDqYW; Tue, 12 Jan 2021 11:26:53 +1100 (AEDT) IronPort-SDR: 8ZVblLiX0CvASgw0IVR0ZXSgBSRMivYMcWsYjXrVhqeZt6WwqgBlpQY6PawQQlBdQ6iTq2F7Ma pPR9UPG29g3g== X-IronPort-AV: E=McAfee;i="6000,8403,9861"; a="239500145" X-IronPort-AV: E=Sophos;i="5.79,339,1602572400"; d="scan'208";a="239500145" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2021 16:26:50 -0800 IronPort-SDR: EJU6EsyN0GHXXDNCtpRUB5+w6QCkymJDvspVoFoGCcejFiK+Picwn2jeNT8pbmd0uAqO/YyYNp 2EwLuPDqlxVA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,339,1602572400"; d="scan'208";a="348273482" Received: from maru.jf.intel.com ([10.54.51.77]) by orsmga003.jf.intel.com with ESMTP; 11 Jan 2021 16:26:50 -0800 From: Jae Hyun Yoo To: Brendan Higgins , Wolfram Sang , Benjamin Herrenschmidt , Joel Stanley , Rob Herring , Mark Rutland , Andrew Jeffery , Tao Ren , Cedric Le Goater Subject: [PATCH v2 0/4] i2c: aspeed: Add buffer and DMA modes support Date: Mon, 11 Jan 2021 16:37:45 -0800 Message-Id: <20210112003749.10565-1-jae.hyun.yoo@linux.intel.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 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: devicetree@vger.kernel.org, openbmc@lists.ozlabs.org, Jae Hyun Yoo , linux-i2c@vger.kernel.org, linux-aspeed@lists.ozlabs.org Errors-To: openbmc-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "openbmc" This patch series adds buffer mode and DMA mode transfer support for the Aspeed I2C driver. With this change, default transfer mode will be set to buffer mode for better performance, and DMA mode can be selectively used depends on platform configuration. * Buffer mode AST2400: It has 2 KBytes (256 Bytes x 8 pages) of I2C SRAM buffer pool from 0x1e78a800 to 0x1e78afff that can be used for all busses with buffer pool manipulation. To simplify implementation for supporting both AST2400 and AST2500, it assigns each 128 Bytes per bus without using buffer pool manipulation so total 1792 Bytes of I2C SRAM buffer will be used. AST2500: It has 16 Bytes of individual I2C SRAM buffer per each bus and its range is from 0x1e78a200 to 0x1e78a2df, so it doesn't have 'buffer page selection' bit field in the Function control register, and neither 'base address pointer' bit field in the Pool buffer control register it has. To simplify implementation for supporting both AST2400 and AST2500, it writes zeros on those register bit fields but it's okay because it does nothing in AST2500. AST2600: It has 32 Bytes of individual I2C SRAM buffer per each bus and its range is from 0x1e78ac00 to 0x1e78adff. Works just like AST2500 does. * DMA mode Only AST2500 and later versions support DMA mode under some limitations in case of AST2500: I2C is sharing the DMA H/W with UHCI host controller and MCTP controller. Since those controllers operate with DMA mode only, I2C has to use buffer mode or byte mode instead if one of those controllers is enabled. Also make sure that if SD/eMMC or Port80 snoop uses DMA mode instead of PIO or FIFO respectively, I2C can't use DMA mode. Please review it. Changes since v1: V1: https://lore.kernel.org/linux-arm-kernel/20191007231313.4700-1-jae.hyun.yoo@linux.intel.com/ - Removed a bug fix patch which was merged already from this patch series. - Removed buffer reg settings from default device tree and added the settings into bindings document to show the predefined buffer range per each bus. - Updated commit message and comments. - Refined driver code using abstract functions. Jae Hyun Yoo (4): dt-bindings: i2c: aspeed: add buffer and DMA mode transfer support ARM: dts: aspeed: modify I2C node to support buffer mode i2c: aspeed: add buffer mode transfer support i2c: aspeed: add DMA mode transfer support .../devicetree/bindings/i2c/i2c-aspeed.txt | 126 +++- arch/arm/boot/dts/aspeed-g4.dtsi | 19 +- arch/arm/boot/dts/aspeed-g5.dtsi | 19 +- drivers/i2c/busses/i2c-aspeed.c | 553 ++++++++++++++++-- 4 files changed, 667 insertions(+), 50 deletions(-)