[PATCH] i2c-mpc: generate START condition after STOP caused by read i2c_msg
Joakim Tjernlund
joakim.tjernlund at transmode.se
Sat May 16 00:16:21 EST 2009
Esben Haabendal <esbenhaabendal at gmail.com> wrote on 15/05/2009 14:52:28:
>
> Your new patch also does not work.
>
> Have you tested it?
sure, works fine. I haven't stressed it too much though.
>
> 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 ;-)
:), point taken.
>
> 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".
Ouch, will have to check too, but later.
>
> 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?
Yes, go ahead.
Jocke
More information about the Linuxppc-dev
mailing list