Messages in this thread | | | Date | Fri, 2 Nov 2012 13:00:38 +0200 | From | Felipe Balbi <> | Subject | Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2 |
| |
Hi,
On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote: > >> browse through various detect functions, yes, some of them key off an > >> ID, but a lot of them just check various registers to see if certain > >> bits are zero, or certain bits are one. A lot of I²C devices I've > >> dealt with have no good way of probing them, especially GPIO chips > >> (you'll notice none of the I²C GPIO expanders have detect functions) > > > > it doesn't mean it can't be done. > > Really? Please, do tell how you would write a detect function for a > PCA9534. It has 4 registers, an input port registers, an output port > register, a polarity inversion register, and a configuration register.
read them and match to their reset values, perhaps ?
> And don't forget, since we are probing, every detect routine for every > I²C driver will have to run with every I²C address on every bus, > possibly with both address formats.
not *every* I2C address. What you say is wrong, a ->detect() method will only run for those addresses which the device can actually assume.
> >> On top of all this the detect routine does not tell you if the alert > >> pin is connected to some IRQ, or in the case of a GPIO expander, what > >> those GPIOs are connected to, etc, etc. > > > > so what ? All you want to do with detect is figure out if the far end is > > who you think it is, not what it's doing. > > If we already knew who was there, we wouldn't need a detect routine.
of course not :-) But the whole discussion has been about not knowing which capes (and thus which devices) are attached to the bone.
-- balbi [unhandled content-type:application/pgp-signature] | |