On 11/06/2013 03:19 PM, Lubomir Popov wrote:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY) {
printf("unconfigured pads\n");
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing changes
within
the controller after a transaction attempt is made, and it keeps its
initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.
Regards,
Lubo
Thanks for the quick reply.
The reason I stumbled across this is that this check hasn't been working
well on our OMAP3 based devices. Some I2C transactions work fine, but
some of them fail this check in the address phase, especially if the I2C
transactions happen in quick successions. We did not have any I2C issues
with the previous driver, and while this behavior is symptomatic of
timing issues playing around with the delays didn't help.
I was wondering if you might have some insights as to what may cause the
controller to behave this way other than unconfigured pads?
--
Regards,
Nikita.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
