Hardware lockup with freescale i2c-mpc driver/2.4?

Hi,

I've witnessed some strange behaviour using i2c-mpc.[ch].
It started when I compiled some i2c client drivers into the kernel.

After booting once, the SDA line gets stuck low.
It's probably held by one of the i2c slaves,
because a power-cycle is required to release SDA.
But even the procedure described in the manual under "Generation of SCL
when SDA Low", (which apparently is also what mpc_i2c_reset() does)
causes no change on SCL/SDA when executed with the BDI2000.

The interesting thing is, that the problem went away when I added
a printk() on top of mpc_i2c_reset (seems to be pretty normal for
this function to get called during the bus scan, btw).

So I figured that if it's about the delay introduced by printk(),
the same effect could be gained by simply putting the delay first
in the loop, and this apparently works pretty well (no lockup since).

Now I'm looking for an explanation why ;)


--
Stefan Nickl
Kontron Modular Computers

Hi

We're migrating out target (proprietary ppc-7447/discovery based
board) from VxWorks to 2.6.7 and NPTL. Building/running multi-threaded
applications is fine but gdb (6.1,6.1.1,cvs) doesn't work. I keep
complaining about cannot find new threads and and the app died with:

        "Program terminated with signal SIGTRAP, Trace/breakpoint trap"

both native and remote debugging had similar problems.

Any suggestion/help would be really appreciated.

--
Linh Dang

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 2004-07-05 at 11:10 -0400, Linh Dang wrote:

We're migrating out target (proprietary ppc-7447/discovery based
board) from VxWorks to 2.6.7 and NPTL. Building/running multi-threaded
applications is fine but gdb (6.1,6.1.1,cvs) doesn't work.

You are saying this in reply to Stefan's mail about a hardware lockup.

Please could you elaborate on why you think they're related.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On 5 Jul 2004, dwmw2@infradead.org wrote:

On Mon, 2004-07-05 at 11:10 -0400, Linh Dang wrote:

quoted

We're migrating out target (proprietary ppc-7447/discovery based
board) from VxWorks to 2.6.7 and NPTL. Building/running
multi-threaded applications is fine but gdb (6.1,6.1.1,cvs) doesn't
work.

You are saying this in reply to Stefan's mail about a hardware
lockup.

Please could you elaborate on why you think they're related.

I must have pressed the wrong key ('f' instead of 'a'). I'd like to
apologize if I offended/annoyed anyone on the list.

I'd like to re-ask my question thought. Anyone managed to get
gdbserver work with NPTL?

Thanx

--
Linh Dang


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Found another strangeness with this driver:

If I get I2C right (I might be severely misguided here),
when watching a master receive data from a slave transmitter,
all the incoming data will be ACKed by the master, except
for the last data byte, where SDA is supposed to be high during
the 9th cycle.
What I'm referring to is this part of the ST M4181 RTC manual (p9):

-------------------------------------------------------
The device that acknowledges has to pull down
the SDA line during the acknowledge clock pulse
in such a way that the SDA line is a stable Low during
the High period of the acknowledge related
clock pulse. Of course, setup and hold times must
be taken into account. A master receiver must signal
an end of data to the slave transmitter by not
generating an acknowledge on the last byte that
has been clocked out of the slave. In this case the
transmitter must leave the data line High to enable
the master to generate the STOP condition.
-------------------------------------------------------

But what I saw was a low SDA during *all* the ACK cycles,
until I did what's in the patch.
It's working, plus what I see on the LA looks much better now.

PS: Is Kumar on holiday or am I just getting on his nerves? ;)

PPS: If anyone's interested in drivers for the Microchip
     EEPROMs with 2 byte addressing and that ST RTC, don't
     hesitate to ask.

--
Stefan Nickl
Kontron Modular Computers