405 I2C

405 I2C

[Kenneth Johansson]

How would you feel about merging the i2c-adap-ibm_ocp.c
andi2c-algo-ibm_ocp.c into one file. This way it's possible to build the
i2c drivers as a module.


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


--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 404 71 83
Borgafjordsgatan 9                Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405 I2C

[andrew may]

On Tue, May 21, 2002 at 05:30:53PM +0200, Kenneth Johansson wrote:
> How would you feel about merging the i2c-adap-ibm_ocp.c
> andi2c-algo-ibm_ocp.c into one file. This way it's possible to build the
> i2c drivers as a module.

I think it would be nice to have them seperate. I think we can latter
have i2-adap-ibm use i2c-algo-bit to controll the I2C bus through the
Direct Control Reg or use the GPIO pins as another I2C bus. I think the
interupt handling should move into "algo" though.

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

Which test in iix_xffer that?

I have been stuck doing a lot of other stuff the past couple of weeks
and the lint'ing of the source files really made the last merge pretty
bad. So my motivation to look into this stuff has been very low.

I was trying to use the lm75 driver and have been running into
problems. The driver does reads of the static registers on the
chip then does a set of reads to "aliased" (1,9,17,...)addresses
of the same registers and does a compare. With my iic_xfer things
start to fail and by forcing the driver to come up it reads a bad
temp(79 I think) and the config is stuck at 0x20. With the old
iic_xfer the bus locks up in an unkown state.

I have been using the GPIO pins to trigger things to look at I2C
clock and data and it seems that the lm75 is doing a NACK for the
chip reg of 0x09. So I am not sure why this appears to different
than the other lm75's out there.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405 I2C

[Armin Kuster]

Kenneth Johansson wrote:
> How would you feel about merging the i2c-adap-ibm_ocp.c
> andi2c-algo-ibm_ocp.c into one file. This way it's possible to build the
> i2c drivers as a module.
>
>
> 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 ??
>
>
>

They should both work as modules as it stands, or at least it did in the
past.  IMHO is does not matter if it is one or two files. Andrew's
iic_xfer was bundled in with many other changes that did not fly, but I
would revisit is if a new patch where submitted with just the iic_xfer.

armin


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405 I2C

[Kenneth Johansson]

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.


>
> 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;
	}


--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 404 71 83
Borgafjordsgatan 9                Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405 I2C

[andrew may]

On Tue, May 21, 2002 at 09:07:07AM -0700, Armin Kuster wrote:
> They should both work as modules as it stands, or at least it did in the
> past.  IMHO is does not matter if it is one or two files. Andrew's
> iic_xfer was bundled in with many other changes that did not fly, but I
> would revisit is if a new patch where submitted with just the iic_xfer.

What changes didn't fly? I only know of the one for the clock divider.
I posted it May 7 and heard nothing in the way of comments. I then got
no warning that the source was going to be linted and completely invalidate
the usefullness of the patch.

http://lists.linuxppc.org/linuxppc-embedded/200205/msg00070.html
http://lists.linuxppc.org/linuxppc-embedded/200205/msg00060.html

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405 I2C

[andrew may]

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/

Re: 405 I2C

[Kenneth Johansson]

On Tue, 2002-05-21 at 20:00, andrew may wrote:

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

Yepp thats the difference.

>
> So you should be going through the combined xfer function.

Yes your right I missed that. It dose look like it's the first write
that never get an ack. This is the debug output from a one byte read
from address 0 from a non existing device.

kernel: iic_xfer: iic_xfer: Clearing status register
kernel: iic_xfer: Waiting for any pending transfers to complete
kernel: iic_xfer: Clearing master data buffer
kernel: iic_xfer: Loading slave address
kernel: iic_xfer: Call combined transaction
kernel: Beginning combined transaction
kernel: This one is a write
kernel: iic_sendbytes: Waiting for interrupt
kernel: iic_ibmocp_handler: in interrupt handler
kernel: iic_ibmocp_handler: status = 26
kernel: i2c-algo-ppc405.o: fail: only wrote -1 bytes.

It dose look like I actually have to learn how this is supposed to work
we seem to have more than one problem with the current code :(





--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 404 71 83
Borgafjordsgatan 9                Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405 I2C

[andrew may]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Wed, May 22, 2002 at 12:36:36PM +0200, Kenneth Johansson wrote:
> On Tue, 2002-05-21 at 20:00, andrew may wrote:
>
> > 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.
>
> Yepp thats the difference.
>
> >
> > So you should be going through the combined xfer function.
>
> Yes your right I missed that. It dose look like it's the first write
> that never get an ack. This is the debug output from a one byte read
> from address 0 from a non existing device.
>
> kernel: iic_xfer: iic_xfer: Clearing status register
> kernel: iic_xfer: Waiting for any pending transfers to complete
> kernel: iic_xfer: Clearing master data buffer
> kernel: iic_xfer: Loading slave address
> kernel: iic_xfer: Call combined transaction
> kernel: Beginning combined transaction
> kernel: This one is a write
> kernel: iic_sendbytes: Waiting for interrupt
> kernel: iic_ibmocp_handler: in interrupt handler
> kernel: iic_ibmocp_handler: status = 26
> kernel: i2c-algo-ppc405.o: fail: only wrote -1 bytes.
>
> It dose look like I actually have to learn how this is supposed to work
> we seem to have more than one problem with the current code :(

Here is a patch to my latest working copy. The comments describe the new
iic_xfer function. The stuff is in the #if 1 section and it is about 280 lines
and it replaces the #else section which is about 470 lines. So if you are going
to work on it I would suggest starting with the new iic_xfer rather than the one
that is there now.

You will need to remove the ibm_gpio_out_timer calls in the IRQ handler I used
to trigger stuff.

There is still plenty of things to do with this, but it is in a works for me state,
and I am not planning on spending time on this stuff right now.

[-- Attachment #2: i2c-522.patch.gz --]
[-- Type: application/octet-stream, Size: 5986 bytes --]