I2C bus issues on MPC8248

[Heiko Schocher]

Hello Laurent,

on Thu, 18 May 2006 14:33:58, Laurent Pinchart wrote:
> I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The
> mailing 
> list archives mention a driver for the MPC8260 
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I 
> modified to reflect the memory map differences between the MPC8260 and the 
> MPC8248, as mentionned in the e-mail.
> 
> The good news is that the driver works. The bad news is that it doesn't work 

OK.

> correctly.

:-(

> The Linux I2C layer probes the I2C bus for peripherals when drivers are 
> loaded. The probing function writes a single byte with the device address and 
> check if the data is acked. I monitored the SCL and SDA lines using an 
[...]
> Using that code, no data is sent on the bus, the BD_SC_READY bit is never 
> cleared and no interrupt is generated. Once again I suspected a CPM bug when 
> writing a single byte on the bus, so I increased cbd_datlen to 2:
> 
> tbdf[0].cbd_bufaddr = __pa(tb);
> tbdf[0].cbd_datlen = 2;
> tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
>                  BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
>                  BD_SC_LAST | BD_SC_WRAP;
> 
> This worked, and two bytes were written on the bus, leading me to believe that 
> the CPM was at fault.

I don t know, if this is a CPM Bug, but it seems so to me ...

> Has anyone noticed the same behaviour ? Is there a workaround available ? I 
> tried searching Freescale's website for CPM microcode updates but haven't 
> found anything related to the I2C controller.

Yes, Holger Speck had the same problem. He solved it by doing the following:

If the cpm_iic_write is called with count = 0. He made a read with count = 1

I think this is safer than writing 2 Bytes to the Slave.
Could you try this?

Best regards
Heiko