linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@tbox.biz>
To: hs@denx.de
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: I2C bus issues on MPC8248
Date: Mon, 22 May 2006 11:06:13 +0200	[thread overview]
Message-ID: <200605221106.13214.laurent.pinchart@tbox.biz> (raw)
In-Reply-To: <1148056646.5943.20.camel@Zeus.EmbLux>

Hi Heiko,

> > 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 ...

I've contacted Freescale's technical support about that issue. They answered 
that 0-byte buffer descriptors are not legal (even though no documentation 
states so), and that the address byte is output on the I2C bus when the next 
byte is written to the internal TX FIFO, making it impossible to send a 
single byte on the bus. Basically, that's a "feature", and they don't intend 
to fix it.

> > 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?

I've tried that with success. The I2C bus still gets stuck from time to time, 
I'll try to investigate that.

Thanks for your help.

Best regards,

Laurent Pinchart

  reply	other threads:[~2006-05-22  9:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19 16:37 I2C bus issues on MPC8248 Heiko Schocher
2006-05-22  9:06 ` Laurent Pinchart [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-24 16:00 Belaire, Ron
2006-05-18 12:33 Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200605221106.13214.laurent.pinchart@tbox.biz \
    --to=laurent.pinchart@tbox.biz \
    --cc=hs@denx.de \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).