From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bw0-f171.google.com (mail-bw0-f171.google.com [209.85.218.171]) by ozlabs.org (Postfix) with ESMTP id 0FD41DE108 for ; Fri, 15 May 2009 22:52:30 +1000 (EST) Received: by bwz19 with SMTP id 19so1902970bwz.9 for ; Fri, 15 May 2009 05:52:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <4A0BD1DB.4090305@doredevelopment.dk> <20090514083453.GB3043@pengutronix.de> <4A0BDAD6.5020005@doredevelopment.dk> Date: Fri, 15 May 2009 14:52:28 +0200 Message-ID: Subject: Re: [PATCH] i2c-mpc: generate START condition after STOP caused by read i2c_msg From: Esben Haabendal To: Joakim Tjernlund Content-Type: text/plain; charset=ISO-8859-1 Cc: linuxppc-dev@ozlabs.org, linux-i2c@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Your new patch also does not work. Have you tested it? I already tried something very much what you sent here, I believe the only difference was that I named the "last" variable "stop". I also tried several other aproaches, and none of them worked. I would appreciate not to have to test all of them seperately again through this mailing list ;-) Anyway, your patch also is in conflict with the MPC8360ERM. The spec specifies that a repeated start must follow an ACK, and not a "NO ACK". When doing a repeated start after a NO ACK, the slave does not ACK the address (I get an RXAK). When doing as specified, ACK'ing the last byte read and then doing a repeated START, i2c_wait() fails due to CSR_MCF bit missing. I thought it would be possible to find somewhere to do a dummy read to get around this, but failed to do so without breaking something else. Could we go forward with my initial patch, and then continue the work on this repeated START approach for future releases? /Esben