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
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
Hi, Laurent,
> While the problem seems to be similar to CPM98, I don't understand how it
> could happen on the first character of the first I2C transfer.
I agree, that is hard to explain given that i2c-cpm keeps the controller
shut off until the very moment of the first transfer. Can you check
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 fir
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 sound
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. T
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 ver
(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
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 lis
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 v
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
>
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,
Wolf
12 matches
Mail list logo
