Hi Laurent,
The two messages making up the transaction are parsed. The driver fills a TX
buffer descriptor for the first one, and a TX and an RX buffer descriptor for
the second one.
rbase 0x01e0 tbase 0x01c0 rfcr 0x30 tfcr 0x30 mrblr 0x0201
rstate 0x rptr 0x rbptr 0x01e0
Hi Mike,
On Tuesday 02 December 2008 00:28:23 Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor
status hasn't been modified by the CPM. The CPM state dump shows that
processing of
...
This sounds very
On Tue, 2008-12-02 at 11:50 +0100, Laurent Pinchart wrote:
Hi Joakim,
On Tuesday 02 December 2008 09:39:59 Joakim Tjernlund wrote:
On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer
Hi Joakim,
On Tuesday 02 December 2008 09:39:59 Joakim Tjernlund wrote:
On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor
status hasn't been modified by the CPM. The CPM
On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor
status
hasn't been modified by the CPM. The CPM state dump shows that processing
of
...
This sounds very similar to
Jocke,
The I2C_CHIP_ERRATA is mine and refers to mpc8xx, mpc860 in my case. The
driver was adapted by me some years ago in 2.4 and now someone has
ported it to 2.6 it seems.
Thanks for the background info. Any idea which particular errata it
was meant to fix? I took a quick look at MPC860
On Saturday 29 November 2008 06:41:53 Wolfram Sang wrote:
Hello Laurent,
After switching to the powerpc architecture and Jochen Friedrich's
driver, I've experienced erratic transfer timeouts. Quite frequent at
first (2.6.26), the problems disappeared on the road to 2.6.27 and have
now
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor status
hasn't been modified by the CPM. The CPM state dump shows that processing of
...
This sounds very similar to a problem I have seen on MPC8247 and
MPC8248.
It could be a
I wrote:
Our production equipment is using Linux 2.6 with the out-of-tree
i2c-algo-8260.c by Dan Malek and Brad Parker.
Oops, I meant to say Linux 2.4.20 (MontaVista).
-=] Mike [=-
___
Linuxppc-dev mailing list
(replying to myself again)
I wrote:
But the key difference is that we see a persistent failure, while the
erratum only mentions a problem with the next transaction.
I think the timeout recovery code is not adequate for these CPM errors,
and that is why a transient error becomes a persistent
Hi everybody,
I've been struggling with a weird CPM2 I2C behaviour for the past few days
without much success.
Some background first. The platform is an MPC8248 (HiP7 Rev 14, Mask 1.0
1K50M) system with an I2C bus on which two peripherals are connected. Back to
the ppc architecture days,
Hello Laurent,
After switching to the powerpc architecture and Jochen Friedrich's driver,
I've experienced erratic transfer timeouts. Quite frequent at first (2.6.26),
the problems disappeared on the road to 2.6.27 and have now resurfaced.
Now == current linus.git?
Kind regards,
12 matches
Mail list logo
