Active low GPIOs (was [PATCH v1 1/4] i2c: mux: Add i2c-arbitrator 'mux' driver)

[Linus Walleij]

On Thu, Feb 14, 2013 at 6:05 PM, Doug Anderson <dianders at chromium.org> wrote:
> Linus,

>> But changing it would have very drastic effects.
>> Consider this snippet from
>> arch/arm/boot/dts/snowball.dts:
>>
>> // External Micro SD slot
>> sdi0_per1 at 80126000 {
>>       arm,primecell-periphid = <0x10480180>;
>>       max-frequency = <50000000>;
>>       bus-width = <4>;
>>       mmc-cap-mmc-highspeed;
>>       vmmc-supply = <&ab8500_ldo_aux3_reg>;
>>
>>       cd-gpios  = <&gpio6 26 0x4>; // 218
>>       cd-inverted;
>
> We're actually kinda screwed today.  What happens if you're on a
> Samsung SoC and you have:
>   cd-gpios = <&gpc3 2 2 0x10003 3>;
>   cd-inverted;

Hm I thought this was a local binding for the MMCI controller,
but no. Ohwell, it's to be kept around forever then.

> What _should_ we do?  I'd argue that we ought to be using
> "gpio_is_asserted" and then keeping the existing invert logic.  This
> is much better than today where you need to do one of:
> * ignore the active low on this GPIO
> * ignore the cd-inverted property
> * manually apply _both_ of these properties.

So if the GPIO is active low and cd-inverted is specified, we
will take the signal and double-negate it so we end up with
an uninverted signal.

So there is suddenly two ways to express "passthru".
well, we usally type !! double-invert in code so why not.
I'm more worrying about the maintainability of this
going forward.

> We could deprecate cd-inverted and at probably should at least
> strongly discourage it.

We also have wp-inverted.

These were added a while back, I guess Arnd and Chris will just
love to discuss this :-)

>  One argument for keeping "cd-inverted" too is
> for controllers that don't use a GPIO for card detect.
>  In this case
> you could imagine a MMC controller that has a "card detect" on
> special-purpose pin and accessible via a status register.

This is actually the case with Integrator/CP and Versatile/AB.

>> Another issue would be with things like bit-banged buses,
>> I don't thing an I2C bus with inverted semantics is that
>> very useful, and it makes things hard to debug for the
>> user, it's much more clear if the bitbang is driving the
>> line high or low than if it's asserting or deasserting it.
>
> Yes, bit-banged i2c is a great example where active low doesn't make
> sense.  Assuming we're not going to remove the OF_GPIO_ACTIVE_LOW
> flag, though, we'd at least need an assertion fail if someone did set
> it.  ...otherwise we end up with flags in the device tree that are
> silently ignored (which is the case much of the time today).
>
> In all honesty, though, I've seen some hardware engineers come up with
> some pretty darn wacky things to save a few cents.  Would it be
> completely absurd for someone to run i2c "backward" if they were
> running it through a level translator that had the side effect of
> inverting the signal?  That would certainly be a reason to use the
> bit-bang mode instead of a normal i2c controller...

We'll handle that as it comes around I guess, we cannot
upfront-design our way throughout the entire thinkable
universe :-)

Yours,
Linus Walleij