From patchwork Thu Oct 25 12:25:15 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 1643791 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 339FADF2AB for ; Thu, 25 Oct 2012 12:35:49 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TRMct-0005DQ-Tb; Thu, 25 Oct 2012 12:33:34 +0000 Received: from devils.ext.ti.com ([198.47.26.153]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TRMap-0004O5-GK for linux-arm-kernel@lists.infradead.org; Thu, 25 Oct 2012 12:31:24 +0000 Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q9PCV9mm029601; Thu, 25 Oct 2012 07:31:09 -0500 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q9PCV9Fl003393; Thu, 25 Oct 2012 07:31:09 -0500 Received: from dlelxv22.itg.ti.com (172.17.1.197) by dfle72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.1.323.3; Thu, 25 Oct 2012 07:31:08 -0500 Received: from localhost (h64-7.vpn.ti.com [172.24.64.7]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id q9PCV8Nr021037; Thu, 25 Oct 2012 07:31:08 -0500 From: Felipe Balbi To: Subject: [PATCH v2 7/7] i2c: omap: implement handling for 'transferred' bytes Date: Thu, 25 Oct 2012 15:25:15 +0300 Message-ID: <1351167915-15079-8-git-send-email-balbi@ti.com> X-Mailer: git-send-email 1.8.0 In-Reply-To: <1351167915-15079-1-git-send-email-balbi@ti.com> References: <1350899218-13624-1-git-send-email-balbi@ti.com> <1351167915-15079-1-git-send-email-balbi@ti.com> MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -4.6 (----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-4.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [198.47.26.153 listed in list.dnswl.org] 3.0 KHOP_BIG_TO_CC Sent to 10+ recipients instaed of Bcc or a list -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: michael@amarulasolutions.com, Benoit Cousson , Tony Lindgren , w.sang@pengutronix.de, Felipe Balbi , Santosh Shilimkar , ben-linux@fluff.org, Linux OMAP Mailing List , Shubhrajyoti Datta , Linux ARM Kernel Mailing List X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org this is important in cases where client driver wants to know how many bytes were actually transferred. There is one trick here: if transfer is completed, meaning I2C_CNT reaches zero, then ARDY will be asserted to let SW know that it can program a new transfer. When ARDY is asserted, I2C_CNT is reset to the original value (msg->len), which means that for a successful message, msg->transferred = msg->len and we don't need to spend time with a register read. In case of NACK condition, however, I2C_CNT will remain with the end value which is the amount of data transferred until NACK condition found on the bus inclusive. In this situation, msg->transferred needs to be initialized with: msg->len - read(I2C_CNT) - 1; This patch implements exactly that handling. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 699fa12..d268e92 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -588,6 +588,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, goto out; } + msg->transferred = msg->len; + wmb(); + /* We have an error */ if (dev->cmd_err & (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR | OMAP_I2C_STAT_XUDF)) { @@ -597,6 +600,15 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, } if (dev->cmd_err & OMAP_I2C_STAT_NACK) { + /* In case of a NACK, we need to check how many bytes we + * actually transferred, so we can tell our client driver about + * it. + * + * Let's check it here and overwrite msg->transferred. + */ + w = omap_i2c_read_reg(dev, OMAP_I2C_CNT_REG); + msg->transferred = msg->len - w - 1; + if (msg->flags & I2C_M_IGNORE_NAK) return 0;