Grant Likely wrote:
For Matt's purposes, I think he wants to describe which GPIO pins are available to be used, but are not yet connected to anything. In such a case I think it does make sense to add a node for available GPIO pins and give it a gpios property with a list of the pins wired to the header.
Yes, the two problems I saw were there is only an implicit definition of which gpios are available for use (GPIOLIB will happily give you an unavailable pin if you ask for it, because there is no definition except for "gpios" property as hooked up to a device). I liked Mitch's idea about the available property and re-using already existing standards and parsing to get it done. (this allows some syntax/lint checking of a device tree too since if you put a pin in a gpios property which you marked as unavailable, you can flag it :) The other problem was defining pins which most definitely ARE connected to something (as GPIO) but could well be in an ill-defined order or for no defined purpose with regards to the peripheral. A lot of GPIO drivers right now (bitbang SPI, I2C) will just allocate one pin as one thing and the other as another - if you say pin 15 and 16 for bitbang-i2c, then it may assumes pin 15 is clock and 16 is data. For SPI, you get another pin, which order is it (the middle one may be correct but the outer ones could be swapped). Is this even defined? Shouldn't it be? And therein lies the question :) Exposing it to userspace is a good idea. While grouping them up would break the existing sysfs ABI there's no reason you can't have all of the GPIOs dumped into sysfs as it is now, and then new directories named after the gpio-group, which symlink back to the sysfs pins in the parent directory? That would really rock as it's bringing the abstraction and description of the device tree back into userspace, where let's be honest, they do not give a crap about device tree bindings, only what pin does what action :D -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
