Heiko,
On 07-Nov-13 10:04, Heiko Schocher wrote:
Hello Lubomir,
Am 07.11.2013 08:57, schrieb Lubomir Popov:
Hi Heiko,
On 07-Nov-13 7:14, Heiko Schocher wrote:
Hello Lubomir,
Am 06.11.2013 14:19, schrieb Lubomir Popov:
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.
Thanks for this explanation! Maybe we can document this somewhere in
the code?
bye,
Heiko
You are right, it would be good to document it. Unfortunately I have not
been on the U-Boot wave for some months now due to very heavy engagement
with other stuff; have even unsubscribed from the list. I think however
that in order to give definite statements and improve the driver, a new
round of experiments has to be made to cover the two major types of
design
flaws (software and/or hardware): incorrect pad configuration, and
missing
pullups (internal or external). I wrote this driver more that 6
months ago
with the goal to have something working properly (the then existing
one was,
mildly put, not good), and this detection is just a bonus side effect.
In summary, the professional approach would require some more effort,
which
I'm not sure when I could afford. Otherwise, if just an explanation
for the
current algo is to be given, no problem - I can just add some comments.
I vote for the professional approach ;-) But if you have no time, and
can just send a comment for the current state (maybe with a short
summary,
what should be done) I am fine with this too!
OK, shall see to the easy way first - just add some comments, sometime
next week.
But, no promises ;-)
Lubo
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
