From: andrew may <acmay@acmay.homeip.net>
To: Kenneth Johansson <kenneth.johansson@inn.ericsson.se>
Cc: andrew may <acmay@acmay.homeip.net>,
Linuxppc embedded <linuxppc-embedded@lists.linuxppc.org>,
Armin Kuster <akuster@mvista.com>
Subject: Re: 405 I2C
Date: Tue, 21 May 2002 11:00:50 -0700 [thread overview]
Message-ID: <20020521110050.B20012@ecam.san.rr.com> (raw)
In-Reply-To: <1021997793.7265.36.camel@swb11>
On Tue, May 21, 2002 at 06:16:33PM +0200, Kenneth Johansson wrote:
> On Tue, 2002-05-21 at 17:59, andrew may wrote:
> > > Also I have a problem when accessing a device that is not present. The
> > > bus ends up in busy state an no other action can be taken. I solved the
> > > problem for me here by simply removing the test in iix_xfer but a proper
> > > solution has to be discussed. I have not tried Andrew's new iic_xfer is
> > > it going to be merged ??
> >
> > Does the scan bus work for you? It should go through and read from all
> > possible locations and report if a device is there. It works with my
> > iic_xfer but I don't rember if I tried the old one. It should have the
> > same effect as "accessing a device that is not present".
>
> No it's not the same the scan work ok. I have not looked into exactly
> why it works but my test program that reads 1 byte from userspace with
> i2c_smbus_read_byte_data() dose not. I hoped I did not have to dig thru
> too much into this as I don't know much about it.
well i2c...read_byte_data is really a write of 1 byte followed by a read
of 1 byte. The scan is just a read of 1 byte.
So you should be going through the combined xfer function.
This is some of the most respulsive cut and paste code I have ever seen.
They first got the function templates from a bit banging driver. They make
no sense for this driver since things like doAddress will never provide
any real status they just load up a register. Then they just copied the
the data transfer code in both read and send, each with 2 copies to handle
4 bytes or less than 4 bytes.
> > Which test in iix_xffer that?
>
> Good question I get a bit unsure of what is going on when I read it
> again but here is the test I removed. Everything works as I want when I
> remove it.
>
> /* When the bus is free, the BCS bits in the EXTSTS register are 0b100
> */
> if (ret != 0x40){
> return IIC_ERR_LOST_ARB;
> }
When I have tried the lm75 driver with this i2c_xfer I get the IIC0_EXTSTS
reg with BCS at 0b111. The manual seems to say that a IIC hardware problem has
occurred. You might try to output what your state is here.
Are things failing on your second read to a bad address? I would think your
first one at least gets past this check and fails somewhere else since at
this point there is really nothing that should have happened on the i2c bus.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-05-21 18:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-21 15:30 405 I2C Kenneth Johansson
2002-05-21 15:59 ` andrew may
2002-05-21 16:16 ` Kenneth Johansson
2002-05-21 18:00 ` andrew may [this message]
2002-05-22 10:36 ` Kenneth Johansson
2002-05-22 19:53 ` andrew may
2002-05-21 16:07 ` Armin Kuster
2002-05-21 17:27 ` andrew may
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=20020521110050.B20012@ecam.san.rr.com \
--to=acmay@acmay.homeip.net \
--cc=akuster@mvista.com \
--cc=kenneth.johansson@inn.ericsson.se \
--cc=linuxppc-embedded@lists.linuxppc.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).