* [U-Boot] [RFC] Make i2c probe opt-outable?
@ 2012-05-17 18:43 Tom Rini
2012-05-18 2:48 ` Mike Frysinger
0 siblings, 1 reply; 8+ messages in thread
From: Tom Rini @ 2012-05-17 18:43 UTC (permalink / raw)
To: u-boot
Hey all,
I'd like to propose making 'i2c probe' be a command that is
opt-out'able. In the Linux Kernel the notion of probing for devices was
abandoned a while ago due to, in short, devices misbehaving when
randomly poked at. Over in omap24xx_i2c land we changed our probe
method a while ago from an attempted read to an attempted write as some
i2c devices would NAK the read. But now with the am33xx SoM family we
have a new issue which is that attempting to write to an address doesn't
immediately issue a NAK so probe sees all addresses as valid and in turn
leaves the bus upset. I've worked around this for now by making
i2c_probe use the read method instead, only on am33xx (so most devices
would be spotted, but the ones that caused the initial change would not
show up). But a possibly better solution is to just make the i2c probe
command not implemented for am33xx (as you don't have to run i2c probe
to try and use your device).
Thoughts? Thanks!
--
Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-17 18:43 [U-Boot] [RFC] Make i2c probe opt-outable? Tom Rini
@ 2012-05-18 2:48 ` Mike Frysinger
2012-05-18 16:11 ` Tom Rini
0 siblings, 1 reply; 8+ messages in thread
From: Mike Frysinger @ 2012-05-18 2:48 UTC (permalink / raw)
To: u-boot
On Thursday 17 May 2012 14:43:45 Tom Rini wrote:
> I'd like to propose making 'i2c probe' be a command that is
> opt-out'able. In the Linux Kernel the notion of probing for devices was
> abandoned a while ago due to, in short, devices misbehaving when
> randomly poked at. Over in omap24xx_i2c land we changed our probe
> method a while ago from an attempted read to an attempted write as some
> i2c devices would NAK the read. But now with the am33xx SoM family we
> have a new issue which is that attempting to write to an address doesn't
> immediately issue a NAK so probe sees all addresses as valid and in turn
> leaves the bus upset. I've worked around this for now by making
> i2c_probe use the read method instead, only on am33xx (so most devices
> would be spotted, but the ones that caused the initial change would not
> show up). But a possibly better solution is to just make the i2c probe
> command not implemented for am33xx (as you don't have to run i2c probe
> to try and use your device).
i've always seen the "i2c probe" command as a debugging tool, not something
that you need to do to make things work. so along those lines, isn't it
already optional ? if you don't like it, don't run it :).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120517/42da068d/attachment.pgp>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-18 2:48 ` Mike Frysinger
@ 2012-05-18 16:11 ` Tom Rini
2012-05-18 16:18 ` Mike Frysinger
2012-05-18 18:26 ` Wolfgang Denk
0 siblings, 2 replies; 8+ messages in thread
From: Tom Rini @ 2012-05-18 16:11 UTC (permalink / raw)
To: u-boot
On 05/17/2012 07:48 PM, Mike Frysinger wrote:
> On Thursday 17 May 2012 14:43:45 Tom Rini wrote:
>> I'd like to propose making 'i2c probe' be a command that is
>> opt-out'able. In the Linux Kernel the notion of probing for devices was
>> abandoned a while ago due to, in short, devices misbehaving when
>> randomly poked at. Over in omap24xx_i2c land we changed our probe
>> method a while ago from an attempted read to an attempted write as some
>> i2c devices would NAK the read. But now with the am33xx SoM family we
>> have a new issue which is that attempting to write to an address doesn't
>> immediately issue a NAK so probe sees all addresses as valid and in turn
>> leaves the bus upset. I've worked around this for now by making
>> i2c_probe use the read method instead, only on am33xx (so most devices
>> would be spotted, but the ones that caused the initial change would not
>> show up). But a possibly better solution is to just make the i2c probe
>> command not implemented for am33xx (as you don't have to run i2c probe
>> to try and use your device).
>
> i've always seen the "i2c probe" command as a debugging tool, not something
> that you need to do to make things work. so along those lines, isn't it
> already optional ? if you don't like it, don't run it :).
Including a command that doesn't work and saying "ah, just don't use
that" is asking for trouble. I'm going down the "what changed in the IP
block, really" rat-hole now (since I've got the original test working).
But still, the kernel decided i2c probing is dangerous/unreliable,
maybe we should follow, or at least allow boards to follow?
--
Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-18 16:11 ` Tom Rini
@ 2012-05-18 16:18 ` Mike Frysinger
2012-05-18 18:26 ` Wolfgang Denk
1 sibling, 0 replies; 8+ messages in thread
From: Mike Frysinger @ 2012-05-18 16:18 UTC (permalink / raw)
To: u-boot
On Friday 18 May 2012 12:11:57 Tom Rini wrote:
> On 05/17/2012 07:48 PM, Mike Frysinger wrote:
> > On Thursday 17 May 2012 14:43:45 Tom Rini wrote:
> >> I'd like to propose making 'i2c probe' be a command that is
> >> opt-out'able. In the Linux Kernel the notion of probing for devices was
> >> abandoned a while ago due to, in short, devices misbehaving when
> >> randomly poked at. Over in omap24xx_i2c land we changed our probe
> >> method a while ago from an attempted read to an attempted write as some
> >> i2c devices would NAK the read. But now with the am33xx SoM family we
> >> have a new issue which is that attempting to write to an address doesn't
> >> immediately issue a NAK so probe sees all addresses as valid and in turn
> >> leaves the bus upset. I've worked around this for now by making
> >> i2c_probe use the read method instead, only on am33xx (so most devices
> >> would be spotted, but the ones that caused the initial change would not
> >> show up). But a possibly better solution is to just make the i2c probe
> >> command not implemented for am33xx (as you don't have to run i2c probe
> >> to try and use your device).
> >
> > i've always seen the "i2c probe" command as a debugging tool, not
> > something that you need to do to make things work. so along those
> > lines, isn't it already optional ? if you don't like it, don't run it
> > :).
>
> Including a command that doesn't work and saying "ah, just don't use
> that" is asking for trouble. I'm going down the "what changed in the IP
> block, really" rat-hole now (since I've got the original test working).
there's plenty of commands in u-boot which are dangerous and should not be run
lightly. i'm not sure we should special case this.
> But still, the kernel decided i2c probing is dangerous/unreliable,
> maybe we should follow, or at least allow boards to follow?
i don't think "dangerous" is quite right, but certainly it's unreliable
because i2c clients are dirt cheap and they aren't required by the protocol to
be terribly sane. plenty of device drivers do probing once they've been told
to connect to a specific address, but that's been gated somewhat.
also, the counter point is that the kernel still *allows* you to probe the
entire i2c bus regardless of it being dangerous. the i2c-tools package is
awesome for doing this sort of thing: probing an entire bus, attempting to
dump register addresses of slaves en mass, etc...
http://www.lm-sensors.org/wiki/I2CTools
personally, i've used the "i2c probe" command before and found it very useful.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120518/960c7121/attachment.pgp>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-18 16:11 ` Tom Rini
2012-05-18 16:18 ` Mike Frysinger
@ 2012-05-18 18:26 ` Wolfgang Denk
2012-05-18 18:43 ` Tom Rini
1 sibling, 1 reply; 8+ messages in thread
From: Wolfgang Denk @ 2012-05-18 18:26 UTC (permalink / raw)
To: u-boot
Dear Tom Rini,
In message <4FB674CD.8030502@ti.com> you wrote:
>
> But still, the kernel decided i2c probing is dangerous/unreliable,
> maybe we should follow, or at least allow boards to follow?
The kernel is in a very different situation - it is supposed to run on
perfect hardware.
In U-Boot, we have to dead with green hardware that is in a completely
unknown state, or with hardware that _might_ be broken in one way or
another. For us tools doing low-level accesses are invaluable - even
if they include the risk to hang a system.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-18 18:26 ` Wolfgang Denk
@ 2012-05-18 18:43 ` Tom Rini
2012-05-18 21:52 ` Wolfgang Denk
0 siblings, 1 reply; 8+ messages in thread
From: Tom Rini @ 2012-05-18 18:43 UTC (permalink / raw)
To: u-boot
On 05/18/2012 11:26 AM, Wolfgang Denk wrote:
> Dear Tom Rini,
>
> In message<4FB674CD.8030502@ti.com> you wrote:
>>
>> But still, the kernel decided i2c probing is dangerous/unreliable,
>> maybe we should follow, or at least allow boards to follow?
>
> The kernel is in a very different situation - it is supposed to run on
> perfect hardware.
>
> In U-Boot, we have to dead with green hardware that is in a completely
> unknown state, or with hardware that _might_ be broken in one way or
> another. For us tools doing low-level accesses are invaluable - even
> if they include the risk to hang a system.
Right. I'm not suggesting removing i2c probe, I'm just suggesting
making it opt-out'able. For example, on the beaglebone I can make i2c
probe work as expected. It's just requring that we toggle the I2C_CON
enable bit for some reason in probe, but not when we are actually trying
to write to a bad address. I'd like to just #undef CONFIG_CMD_I2C_PROBE
for the board and be done with it. Otherwise it lists (nearly) every
address which is useless.
--
Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-18 18:43 ` Tom Rini
@ 2012-05-18 21:52 ` Wolfgang Denk
2012-05-21 16:48 ` Tom Rini
0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Denk @ 2012-05-18 21:52 UTC (permalink / raw)
To: u-boot
Dear Tom Rini,
In message <4FB69847.2090703@ti.com> you wrote:
>
> Right. I'm not suggesting removing i2c probe, I'm just suggesting
> making it opt-out'able. For example, on the beaglebone I can make i2c
> probe work as expected. It's just requring that we toggle the I2C_CON
> enable bit for some reason in probe, but not when we are actually trying
> to write to a bad address. I'd like to just #undef CONFIG_CMD_I2C_PROBE
> for the board and be done with it. Otherwise it lists (nearly) every
> address which is useless.
Can you use bit-banged I2C on these boards?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"IBM uses what I like to call the 'hole-in-the-ground technique' to
destroy the competition..... IBM digs a big HOLE in the ground and
covers it with leaves. It then puts a big POT OF GOLD nearby. Then it
gives the call, 'Hey, look at all this gold, get over here fast.' As
soon as the competitor approaches the pot, he falls into the pit"
- John C. Dvorak
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [RFC] Make i2c probe opt-outable?
2012-05-18 21:52 ` Wolfgang Denk
@ 2012-05-21 16:48 ` Tom Rini
0 siblings, 0 replies; 8+ messages in thread
From: Tom Rini @ 2012-05-21 16:48 UTC (permalink / raw)
To: u-boot
On Fri, May 18, 2012 at 11:52:06PM +0200, Wolfgang Denk wrote:
> Dear Tom Rini,
>
> In message <4FB69847.2090703@ti.com> you wrote:
> >
> > Right. I'm not suggesting removing i2c probe, I'm just suggesting
> > making it opt-out'able. For example, on the beaglebone I can make i2c
> > probe work as expected. It's just requring that we toggle the I2C_CON
> > enable bit for some reason in probe, but not when we are actually trying
> > to write to a bad address. I'd like to just #undef CONFIG_CMD_I2C_PROBE
> > for the board and be done with it. Otherwise it lists (nearly) every
> > address which is useless.
>
> Can you use bit-banged I2C on these boards?
In this particular case it worked out to being that a previous change to
the probe code violated the TRM, but didn't cause (obvious?) harm on
older versions of the IP block but on newer ones (am33xx, omap4+) it
does. I'll drop the idea of making i2c probe command opt-out.
--
Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-05-21 16:48 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-17 18:43 [U-Boot] [RFC] Make i2c probe opt-outable? Tom Rini
2012-05-18 2:48 ` Mike Frysinger
2012-05-18 16:11 ` Tom Rini
2012-05-18 16:18 ` Mike Frysinger
2012-05-18 18:26 ` Wolfgang Denk
2012-05-18 18:43 ` Tom Rini
2012-05-18 21:52 ` Wolfgang Denk
2012-05-21 16:48 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.