From patchwork Thu Nov 15 12:13:31 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Naveen Krishna Chatradhi X-Patchwork-Id: 1748751 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 1FDF2DF230 for ; Thu, 15 Nov 2012 11:56:18 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TYy1H-00079S-IU; Thu, 15 Nov 2012 11:54:08 +0000 Received: from mailout4.samsung.com ([203.254.224.34]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TYy1A-00075w-U9 for linux-arm-kernel@lists.infradead.org; Thu, 15 Nov 2012 11:54:02 +0000 Received: from epcpsbgm2.samsung.com (epcpsbgm2 [203.254.230.27]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MDJ00KZF2DTPPP0@mailout4.samsung.com> for linux-arm-kernel@lists.infradead.org; Thu, 15 Nov 2012 20:53:58 +0900 (KST) Received: from epcpsbgm2.samsung.com ( [172.20.52.122]) by epcpsbgm2.samsung.com (EPCPMTA) with SMTP id 01.71.12699.6D7D4A05; Thu, 15 Nov 2012 20:53:58 +0900 (KST) X-AuditID: cbfee61b-b7f616d00000319b-96-50a4d7d64f49 Received: from epmmp1.local.host ( [203.254.227.16]) by epcpsbgm2.samsung.com (EPCPMTA) with SMTP id 70.71.12699.5D7D4A05; Thu, 15 Nov 2012 20:53:57 +0900 (KST) Received: from localhost.localdomain ([107.108.73.106]) by mmp1.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MDJ0033F28S3800@mmp1.samsung.com> for linux-arm-kernel@lists.infradead.org; Thu, 15 Nov 2012 20:53:57 +0900 (KST) From: Naveen Krishna Chatradhi To: linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-i2c@vger.kernel.org Subject: [PATCH 2/4] i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY Date: Thu, 15 Nov 2012 17:43:31 +0530 Message-id: <1352981613-2098-3-git-send-email-ch.naveen@samsung.com> X-Mailer: git-send-email 1.7.0.4 In-reply-to: <1352981613-2098-1-git-send-email-ch.naveen@samsung.com> References: <1352981613-2098-1-git-send-email-ch.naveen@samsung.com> DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsWyRsSkSvfa9SUBBu+/sltsenyN1YHRY/OS +gDGKC6blNSczLLUIn27BK6MLa9+MhXMU6u4fb6LqYFxkVwXIyeHhICJxLPZz9kgbDGJC/fW A9lcHEICSxklGhc3sMIUHbq/mhHEFhJYxChxY2Y8RNEGJokbez4ygSTYBMwkDi5azQ5iiwhk SCx5tIERpIhZoJdRYtu/B2AJYQEPiRNvloGtYxFQlXi05z1YM6+Ai8SbhfMZIbYpSLQuOwRW zyngKrF96VGozS4Suy+uZIXoFZD4NvkQSxcjB1C9rMSmA8wguyQELrNJzNp0jAVijqTEwRU3 WCYwCi9gZFjFKJpakFxQnJSea6RXnJhbXJqXrpecn7uJERiEp/89k97BuKrB4hCjAAejEg+v xcfFAUKsiWXFlbmHGCU4mJVEeA3OLQkQ4k1JrKxKLcqPLyrNSS0+xOgDdMlEZinR5HxghOSV xBsam5ibGptaGhmZmZriEFYS5232SAkQEkhPLEnNTk0tSC2CGcfEwSnVwKhweJPYDB3xiuqj quwXY7Q/hok6vgwqfxTEMHXtyqc3pu9jq67gr9uheWSedHAF42/5Jx43VjG/W31xisEmtZyH vTNXz7NNjxeemKtsJuL4pKA1nilD3dGni2k6P/el2+7l36sblCPyTP6WfnGcYKmS8/fXk7mW 5k8fP1A/XL90ZmWCtPhmJyWW4oxEQy3mouJEAITpoJtvAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42I5/e+xgO7V60sCDG69NLXY9PgaqwOjx+Yl 9QGMUQ2MNhmpiSmpRQqpecn5KZl56bZK3sHxzvGmZgaGuoaWFuZKCnmJuam2Si4+AbpumTlA U5UUyhJzSoFCAYnFxUr6dpgmhIa46VrANEbo+oYEwfUYGaCBhDWMGVte/WQqmKdWcft8F1MD 4yK5LkZODgkBE4lD91czQthiEhfurWcDsYUEFjFK3JgZ38XIBWRvYJK4secjE0iCTcBM4uCi 1ewgtohAhsSSRxsYQYqYBXoZJbb9ewCWEBbwkDjxZhnYJBYBVYlHe96DNfMKuEi8WTgfapuC ROuyQ2D1nAKuEtuXHmWE2OwisfviStYJjLwLGBlWMYqmFiQXFCel5xrpFSfmFpfmpesl5+du YgSH+DPpHYyrGiwOMQpwMCrx8Fp8XBwgxJpYVlyZe4hRgoNZSYTX4NySACHelMTKqtSi/Pii 0pzU4kOMPkBXTWSWEk3OB8ZfXkm8obGJuamxqaWJhYmZJQ5hJXHeZo+UACGB9MSS1OzU1ILU IphxTBycUg2MLT5LN7I0nN/u+Ubm7p7k25d4TnPe7Yr/cuDaWTX/YL9+3c++NqtPZV82eT+9 fonOMo56iQRrPvm31zt+zZRhLuJ4dvOp3rMJDTO+qq95nGR7Sigss30D8xamjoTgBdX3f5zU mPxMmzPgr3/So+zjLxduyw847RIrbyvnZrJC8VSv+fZHTDuuKbEUZyQaajEXFScCAPR5G+Oe AgAA X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20121115_065401_646131_411F8F59 X-CRM114-Status: GOOD ( 17.27 ) X-Spam-Score: -7.6 (-------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-7.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [203.254.224.34 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO 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: kgene.kim@samsung.com, w.sang@pengutronix.de, djkurtz@chromium.org, ben-linux@fluff.org, khali@linux-fr.org, naveenkrishna.ch@gmail.com 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: , MIME-Version: 1.0 Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org From: Daniel Kurtz buses The datasheet says that the STOP sequence should be: 1) I2CSTAT.5 = 0 - Clear BUSY (or 'generate STOP') 2) I2CCON.4 = 0 - Clear IRQPEND 3) Wait until the stop condition takes effect. 4*) I2CSTAT.4 = 0 - Clear TXRXEN Where, step "4*" is only for buses with the "HDMIPHY" quirk. However, after much experimentation, it appears that: a) normal buses automatically clear BUSY and transition from Master->Slave when they complete generating a STOP condition. Therefore, step (3) can be done in doxfer() by polling I2CCON.4 after starting the STOP generation here. b) HDMIPHY bus does neither, so there is no way to do step 3. There is no indication when this bus has finished generating STOP. In fact, we have found that as soon as the IRQPEND bit is cleared in step 2, the HDMIPHY bus generates the STOP condition, and then immediately starts transferring another data byte, even though the bus is supposedly stopped. This is presumably because the bus is still in "Master" mode, and its BUSY bit is still set. To avoid these extra post-STOP transactions on HDMI phy devices, we just disable Serial Output on the bus (I2CSTAT.4 = 0) directly, instead of first generating a proper STOP condition. This should float SDA & SCK terminating the transfer. Subsequent transfers start with a proper START condition, and proceed normally. The HDMIPHY bus is an internal bus that always has exactly two devices, the host as Master and the HDMIPHY device as the slave. Skipping the STOP condition has been tested on this bus and works. Also, since we disable the bus directly from the isr, we can skip the bus idle polling loop at the end of doxfer(). Signed-off-by: Daniel Kurtz Cc: Doug Anderson Cc: Daniel Kurtz Signed-off-by: Naveen Krishna Chatradhi --- drivers/i2c/busses/i2c-s3c2410.c | 47 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index 155cb04..fc4bf35 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -234,8 +234,47 @@ static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret) dev_dbg(i2c->dev, "STOP\n"); - /* stop the transfer */ - iicstat &= ~S3C2410_IICSTAT_START; + /* + * The datasheet says that the STOP sequence should be: + * 1) I2CSTAT.5 = 0 - Clear BUSY (or 'generate STOP') + * 2) I2CCON.4 = 0 - Clear IRQPEND + * 3) Wait until the stop condition takes effect. + * 4*) I2CSTAT.4 = 0 - Clear TXRXEN + * + * Where, step "4*" is only for buses with the "HDMIPHY" quirk. + * + * However, after much experimentation, it appears that: + * a) normal buses automatically clear BUSY and transition from + * Master->Slave when they complete generating a STOP condition. + * Therefore, step (3) can be done in doxfer() by polling I2CCON.4 + * after starting the STOP generation here. + * b) HDMIPHY bus does neither, so there is no way to do step 3. + * There is no indication when this bus has finished generating + * STOP. + * + * In fact, we have found that as soon as the IRQPEND bit is cleared in + * step 2, the HDMIPHY bus generates the STOP condition, and then + * immediately starts transferring another data byte, even though the + * bus is supposedly stopped. This is presumably because the bus is + * still in "Master" mode, and its BUSY bit is still set. + * + * To avoid these extra post-STOP transactions on HDMI phy devices, we + * just disable Serial Output on the bus (I2CSTAT.4 = 0) directly, + * instead of first generating a proper STOP condition. This should + * float SDA & SCK terminating the transfer. Subsequent transfers + * start with a proper START condition, and proceed normally. + * + * The HDMIPHY bus is an internal bus that always has exactly two + * devices, the host as Master and the HDMIPHY device as the slave. + * Skipping the STOP condition has been tested on this bus and works. + */ + if (i2c->quirks & QUIRK_HDMIPHY) { + /* Stop driving the I2C pins */ + iicstat &= ~S3C2410_IICSTAT_TXRXEN; + } else { + /* stop the transfer */ + iicstat &= ~S3C2410_IICSTAT_START; + } writel(iicstat, i2c->regs + S3C2410_IICSTAT); i2c->state = STATE_STOP; @@ -560,6 +599,10 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c, else if (ret != num) dev_dbg(i2c->dev, "incomplete xfer (%d)\n", ret); + /* For QUIRK_HDMIPHY, bus is already disabled */ + if (i2c->quirks & QUIRK_HDMIPHY) + goto out; + /* ensure the stop has been through the bus */ dev_dbg(i2c->dev, "waiting for bus idle\n");