From patchwork Fri Jun 7 18:39:06 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 2689121 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id E6DC440077 for ; Fri, 7 Jun 2013 18:40:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756105Ab3FGSkM (ORCPT ); Fri, 7 Jun 2013 14:40:12 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:49648 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755813Ab3FGSkL (ORCPT ); Fri, 7 Jun 2013 14:40:11 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id r57IeAmX015915; Fri, 7 Jun 2013 13:40:10 -0500 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id r57IeAPD016589; Fri, 7 Jun 2013 13:40:10 -0500 Received: from dlelxv22.itg.ti.com (172.17.1.197) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.2.342.3; Fri, 7 Jun 2013 13:40:10 -0500 Received: from localhost (h78-16.vpn.ti.com [172.24.78.16]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id r57Ie8wK024969; Fri, 7 Jun 2013 13:40:09 -0500 Date: Fri, 7 Jun 2013 21:39:06 +0300 From: Felipe Balbi To: Tomi Valkeinen CC: linux-omap , Tony Lindgren Subject: Re: i2c issue on Panda with DT boot, v3.10-rc4 Message-ID: <20130607183906.GB15295@arwen.pp.htv.fi> Reply-To: References: <51B1C9D2.6060703@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51B1C9D2.6060703@ti.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org Hi, On Fri, Jun 07, 2013 at 02:53:54PM +0300, Tomi Valkeinen wrote: > Hi, > > I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the > DVI output's EDID reading to work. Testing with i2cget and i2cdump, I > see that I can read individual bytes with i2cget, but using i2cdump > doesn't work, it just shows 'XX'es. does it work with v3.9 ? The funny thing is that nothing has changed on i2c-omap.c for quite some time... > The same issue is there with 3.10-rc4, although with that one I get > timeouts with i2cdump, whereas there were no timeouts with -rc1. > > # i2cget -y 2 0x50 0x10 > 0x0a > # i2cget -y 2 0x50 0x20 > 0x0f > # i2cget -y 2 0x50 0x30 > 0x01 > # i2cget -y 2 0x50 0x40 > 0x36 > # i2cget -y 2 0x50 0x50 > 0x4c > # i2cdump -y 2 0x50 > No size specified (using byte-data access) > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > 00: 00 [ 72.814086] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 73.825134] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 74.835327] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 76.097167] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 77.160736] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 78.174682] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 79.194824] omap_i2c 48060000.i2c: timeout waiting for bus ready > XX [ 80.242980] omap_i2c 48060000.i2c: timeout waiting for bus ready > > i2cdump works fine with non-DT boot (but the i2c bus number is 3). > > Any ideas? sounds like there's something left in FIFO which is not getting read out, then we end up timing out. Can you try the patch below ? It's patch of a bigger patchset which I still need to clean a few things up, but they should be very close to being ready. IIRC, one of the patches creates a problem for N900 (only) which gets fixed later, I just need to combine those two patches into one to avoid the regression. diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index aa3b91e..471b434 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) } } while (stat); - omap_i2c_complete_cmd(dev, err); - out: + omap_i2c_complete_cmd(dev, err); spin_unlock_irqrestore(&dev->lock, flags); return IRQ_HANDLED;