[i2c] [PATCH] s3c24xx: fix writes to certain devices
Jean Delvare
khali at linux-fr.org
Sat Nov 11 18:14:39 CET 2006
Hi Ben,
Sorry for the delay.
On Wed, 27 Sep 2006 07:08:21 +0100, Ben Dooks wrote:
> On Tue, Sep 19, 2006 at 11:01:26PM +0200, Jean Delvare wrote:
> > > + /* sometimes write operations fail if the write is
> > > + * let go too quickly, slow down the proceedings
> > > + * slightly.
> > > + */
> > > +
> >
> > No blank line here please,
> >
> > > + for (i = 0; i < 6; i++)
> > > + tmp += readl(i2c->regs + S3C2410_IICSTAT);
> > > +
> >
> > nor here.
> >
> > > } else if (!is_lastmsg(i2c)) {
> > > /* we need to go to the next i2c message */
> > >
> > >
> >
> > What a ugly hack :( Is there really no cleaner way to fix it? No way to
> > find out when exactly this "sometimes" occurs? Performance will suffer
> > with these unconditional 6 more I/O reads.
>
> No, without it, on some devices, the I2C simply stalls on every
> write. The bus the i2c controller is on is running at 66MHz, so
> is not exactly slow, especially as we've executed several 100
> instructions per-i2c byte moved just going in and out of the ISR.
>
> > Where does this arbitrary 6 come from?
>
> expermimentation
>
> > Why do you add the read value to tmp?
>
> An attempt to stop the compiler trying to optimise
> this out of the code.
Reading from hardware registers could have any kind of side effect the
compiler doesn't know about, so I would be very surprised if the
compiler would attempt to "optimize" such instructions. Please try
without the tmp trick, and see if it works. If it really doesn't, I
would consider it a compiler bug, which should be reported.
Thanks,
--
Jean Delvare
More information about the i2c
mailing list