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
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, Heiko
13 matches
Mail list logo
